Re: [9fans] another type of static linking: send all the shared libraries with the program!
and it will be an unaswered question. o fortuna, velut luna, statu variabilis. infinita variabiles?
Re: [9fans] 9p vs http
On Mon, Nov 15, 2010 at 6:16 AM, Sam Watkins wrote: > On Sun, Nov 14, 2010 at 11:20:00PM -0500, John Floren wrote: >> Please see lsub's Op and my Streaming talk at the most recent IWP9. > > Ok, thanks. I did not know that 9p has latency problems even when reading a > single file. I was talking about pipelining, where you can ask the server to > send a dozen files or chunks all of metadata all in a single packet. As I > said, I think this might be useful even within a site. > > Do you think http has any disadvantages compared to 9p? Permissions, namespaces... -- - curiosity sKilled the cat
Re: [9fans] 9p vs http
On Mon, Nov 15, 2010 at 3:09 PM, Gorka Guardiola wrote: > On Mon, Nov 15, 2010 at 6:16 AM, Sam Watkins wrote: >> On Sun, Nov 14, 2010 at 11:20:00PM -0500, John Floren wrote: >>> Please see lsub's Op and my Streaming talk at the most recent IWP9. >> >> Ok, thanks. I did not know that 9p has latency problems even when reading a >> single file. I was talking about pipelining, where you can ask the server to >> send a dozen files or chunks all of metadata all in a single packet. As I >> said, I think this might be useful even within a site. >> >> Do you think http has any disadvantages compared to 9p? > > Permissions, namespaces... By namespaces I mean qid's , the notion that a file is the same if the name isn't. -- - curiosity sKilled the cat
Re: [9fans] 9p vs http
On 15 November 2010 14:15, Gorka Guardiola wrote: > By namespaces I mean qid's , the notion that a file is the same if the > name isn't. mind you, that's problematic in 9p. the qid can be the same even if the file is different: % ls -lqd /n/dump/2006/0707/usr/rog (0003d540 1122 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 7 2005 /n/dump/2005/0707/usr/rog % ls -lqd /n/dump/2006/0707/usr/rog (0003d540 1157 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 12 2006 /n/dump/2006/0707/usr/rog they have the same qid but they're different directories with different contents. it's difficult to do a good job when embedding file systems, as the qid space is fixed. you can cheat, by rewriting the qid when the file is actually opened to paper over the most obvious problems, but it's still not great. perhaps things would be easier if qids were sufficiently large (e.g. sha1 hash sized) that an embedding file server could make up new qids (or create them by xoring in other info) without fear of clashes. re: 9p pipelining - i've been working on a little experiment related to this. i'll be sharing the results in a little while.
[9fans] contrib/install fgb/X11?
Anyone else having trouble getting equis installed via contrib/install? I tried to do this this morning, as I was interested in giving cinap_lenrek's dillo rc bundle a spin, and figured I needed X11 for that, but it might already be there (it's failing). X11 didn't succeed in installing, and it seems my /tmp has been affected somehow. Now for every retry i'm having to use "ramfs" to create a new /tmp before starting. I had to manually cleanup the /dist/replica/X11 file as well so it didn't think it was already installed. I've been thinking there might be a way for me to contribute to contrib here with failure cleanup, once I get a good handle on how it all works. Dave
Re: [9fans] 9p vs http
On Sun, Nov 14, 2010 at 7:25 PM, Sam Watkins wrote: > hi, > > I am wondering what you think about the capabilities of 9p compared to > http/1.1. Perhaps this seems like an odd comparison, but I think 9p and > http > are broadly similar in purpose and functionality. While writing a simple > webserver, I got to thinking that http is really a very capable protocol. > > http is text-based, it supports pipelining and arbitraty metadata. As far > as I > know, 9p does not support pipelining nor arbitraty metadata. It seems to > me > that these are big advantages for http. 9p supports walking; are there > other > things 9p can do which http cannot, which give 9p a significant advantage? > > Am I correct, that 9p does not support pipelining? I suppose this would be > a > big problem. For example, with http pipelining one may ask a server to > HEAD > (like stat) 10,000 files together, without having to wait for the > responses. > Over a high latency link (e.g. Australia -> USA), this might save perhaps > an > hour of waiting. > Under certain situations, 9p can do some forms of pipelining. The tagged requests don't have to be waited on in order, for the next outgoing request to be sent, unless there's a dependency of one completing before the other, or the evaluation of completion of a previous one on another. > > Such an asyncronous interface might be useful even when accessing local > disks - > if the filesystem receives 100 open/read/stat requests bundled together, it > might optimise disk access to minimise seeking, as is commonly done for > writes. > > By the way, I read the other day on this list that there is no need to > improve > cat(1). Well for me, I still feel that the command `cat` without args > should > concatenate 0 files (producing no output), not copy stdin to stdout! > That's an interesting point of view. I think the concept of "standard input" is that if no input is given, it was going to be the fallback. Same goes for standard output. With that said, I think cat is behaving just fine to take no arguments and then default to the standard input and output :-). > > > Sam > > >
Re: [9fans] Plan9 development
On Sun, Nov 14, 2010 at 11:29 PM, Gary V. Vaughan wrote: > You can either try to remember what all of those are, or use something > like autoconf to probe for known bugs, and gnulib to plug them, or > you can link against a shim library like GNU libposix which will > do all of that automatically when it is built and installed, allowing > you to write to the POSIX APIs with impunity. I've read this discussion with interest. Something that strikes me is that there are certain underlying beliefs and assumptions in the Plan 9 community that are taken for granted and rarely articulated, but that frame many of the comments from 9fans. Further, those are, in many ways, contrary to the assumptions and requirements Gary is constrained by when working on libtool. I believe that one of the most powerful decisions that the original plan 9 developers made was consciously resisting backwards compatibility with Unix. That's not to say that they completely ignored it, or that it was actively worked against, but that it was not a primary consideration and did not (overly) constrain either design or implementation. This freed them to revisit assumptions, rethink many of the decisions in the base system, and clean up a lot of rough edges. For instance, and relevant to this discussion, take a look at how cross-compilation and platform independence on Plan 9 "just works" in a simple, consistent way across multiple architectures. I was surprised how an earlier message in this discussion when Gary said, > If you have never tried to build and link shared libraries from the same > code-base on 30 (or even 3) separate incompatible architectures, then > you are probably missing the point, and needn't read any further. Granted, I think the key thing here is that Gary's talking about shared libraries (which, as Russ said, the Plan 9 developers simply punted on), instead of just building, but I can't help but feel that this overlooks part of the plan 9 way of doing things. The plan 9 developers made a decision to break with the convention of naming object files with a ".o" extension, assigned a letter to each archicture, established the convention that object files and libraries would use that letter in their filenames, and renamed the compiler, assembler and linker accordingly. Then they modified the filesystem hierarchy to have archiecture specific directory trees for architecture specific things (which is easy to do with you've got mutable namespaces). Mk was smart enough that these conventions could be used in the build system pretty easily. None of these are name changes are particularly deep; in many ways, they are simply cosmetic. However, they led to a simplification that makes building for different architectures out of the same tree nearly trivial. Just by setting an environment variable, I can build the entire system for a different architecture, in the same tree, with a single command, with no conflicts. Since the compiler for each architecture is just another program, cross-compilation isn't special or complicated. Compare this to setting up gcc for cross compilation. And that's sort of the point. 9fans tend not to ask, "how can I make this work across multiple systems that are immutable as far as I'm concerned as a developer" but rather they ask, "how can the system support me doing this in a simpler, orthogonal, more consistent way?" If that means shedding some convention and replacing it with something else that makes life easier, there's less hesitation to do that. To that end, libtool, autoconf and automake, etc, all seem to answer the wrong question. From the 9fans perspective (and take this with a grain of salt; I can't claim to speak for all of us), libtool seems "crazy" because it puts a bandaid on a wart instead of trying to solve the underlying problem of complex, inconsistent interfaces across systems. In this way, it is reactionary. Autoconf et al are analogous to a bunch of nested #ifdef's, and most 9fans would chose to program to some sort of shim library that provided a consistent interface as a matter of course. Better yet, they'd go fix the underlying systems so that they correctly implemented the relevant standard or interface. I'm not sure that's possible with Unix, as Gary rightly points out, because of the weight of the installed base, fragmentation between variants and the requirements of backwards compability. Though unrealistic, it's certainly idealistic. One of the enduring benefits of Plan 9 is that it is (still) a good example of how well-reasoned engineering tradeoffs and a modicum of good taste can produce a powerful and elegant system with a simple implementation. Rob Pike is (in?)famously quoted as saying, "not only is Unix dead, it's starting to smell really bad" (note to Rob: is this apocryphal? I've never found an original source). I think that's often taken out of context; Unix may be dead as an exciting venue for the exploration of fundamentally new ways o
Re: [9fans] another type of static linking: send all the shared libraries with the program!
On Sun, Nov 14, 2010 at 6:31 PM, Jeff Sickel wrote: > > On Nov 13, 2010, at 5:14 PM, David Leimbach wrote: > > > Isn't this what Apple does recommend you do with application bundles? > Ship > > the whole directory (.app) with all requisite frameworks and libs? > > That's the recommended approach for certain types of distributions. The > alternative approach is to not do shared/dynamic libraries in the code you > ship. That way the only dynamically linked code is that used in the system > frameworks. Many folks also find that their applications launch faster when > not traversing all sorts of dyldhell. > 2-level namespaces help with that too. You can bind paths to particular shared library instances that you're interested in. > > There's still the open-ended question of bundles of loadable modules, if > you need them. > There's also this vague memory I have of being deeply concerned about a direction I swear I read somewhere on an Apple developer mailing list about static libraries not being supported going forward with Mac OS X. > > -jas > > >
Re: [9fans] 9p vs http
> Under certain situations, 9p can do some forms of pipelining. The tagged > requests don't have to be waited on in order, for the next outgoing request > to be sent, unless there's a dependency of one completing before the other, > or the evaluation of completion of a previous one on another. Only if the file & file server involved are decent. -- vs
Re: [9fans] 9p vs http
On Mon, Nov 15, 2010 at 7:55 AM, Venkatesh Srinivas wrote: > > Under certain situations, 9p can do some forms of pipelining. The tagged > > requests don't have to be waited on in order, for the next outgoing > request > > to be sent, unless there's a dependency of one completing before the > other, > > or the evaluation of completion of a previous one on another. > > Only if the file & file server involved are decent. > > -- vs > > Yes. I think that's the definition of "decent", but I'm not really up to date on that enough to converse about decency...
Re: [9fans] contrib/install fgb/X11?
the contrib tools are based on replica and in my experience that makes them slow and fragile. You might want to give the 9pm stuff I did a try. It works,it's far faster, and they're trivial shell scripts that are easy to understand. Simple example, installing openssh is about 50 times faster -- minutes vs. hours -- using 9pm. Ah blast 9grid.net went away, I will get the guys to go kick it. ron
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:01 AM, ron minnich wrote: > the contrib tools are based on replica and in my experience that makes > them slow and fragile. You might want to give the 9pm stuff I did a > try. It works,it's far faster, and they're trivial shell scripts that > are easy to understand. Simple example, installing openssh is about 50 > times faster -- minutes vs. hours -- using 9pm. > > Ah blast 9grid.net went away, I will get the guys to go kick it. > I was going to ask for a link to 9pm. Is it on 9grid? I guess I'll search the archives to find out what 9pm is :-). Dave > > ron > >
Re: [9fans] Plan9 development
On 15 Nov 2010, at 08:02, Enrico Weigelt wrote: > * Gary V. Vaughan wrote: >> People like to beat on GNU Libtool, and in some cases that criticism is >> not undeserved... but in my experience, many critics of the tool come >> from a perspective of building on a single architecture. > > Actually, I'm building for lots of different archs almost all the day. > Crosscompiling w/ sysroot, of course. And that's exactly the point > where libtool and other autotools stuff was quite unusable until just > a few years ago (eg. passed *wrong* library pathes to the toolchain). I have been compiling cross-platform Free Software for a living for about 8 years now, and I have been maintaining GNU Libtool for close to twice that long. I have never used sysroot in all that time, and no else offered patches until quite recently. Libtool has been immeasurably useful to me entirely without that particular feature. At the risk of getting off topic, that's kind of the point of free software - if it doesn't work quite the way you would like, fix it! If your fixes make any kind of sense, they'll likely be adopted upstream for everyone else to enjoy too. >> That said, your comment strikes me as entirely unsubstantiated. Why do >> you think the concepts themselves are insane? > > The whole idea of libtool essentially being a command line filter > instead of defining an own coherent abstraction interface What is incoherent or unabstract about offering a static-library like interface to building shared libraries, or an ELF like library versioning scheme? > and one > implementation/configuration instance per target instead of an > autofooled instance per individual package build. How does that scale in the face of a dozen or more OSes, each with at least a handful of supported library releases and compiler revisions each with a handful of vendor maintenance patches, each with several hundred API entry-points of which several dozen of each have non-conformances or outright bugs. Worse, many of my clients mix and match gcc with vendor ldd and runtime in various combinations or install and support 3 or more compilers per architecture. Libtool figures out what to do in all of those thousands of combinations, by probing the environment at build time... I'd *much* rather wait 90 seconds for each build that try to maintain a giant tabulation with thousands of entries, which go out of date every time a new patch or revision of libc or the compiler or the os or the linker comes along. >> Setting aside the admitted implementation shortcomings for the sake >> of argument; if you were >> designing GNU Libtool from scratch, how would you do it differently? > > See git://pubgit.metux.de/projects/unitool.git Java? For a bootstrapping tool? Does Java even get worthwhile support outside of Windows and Solaris these days? If it works for you, that's great, but I would have an extremely hard sell on my hands if I told my clients they would need to have a working Java runtime on Tru64 Unix before I could provide a zlib build recipe for them :-o > >> 1. Unix variants (including POSIX layers of non-Unix architectures) >> build shared libraries in vastly different ways, GNU Libtool >> needs to handle all of them; > > That's an issue of individual platform backends, which should be > completely transparent to the calling package. Agreed, that's what libtool provides, but to do that it needs to be intimately familiar with how each combination works. It certainly shouldn't be trying to do that without calling the vendor compiler and linker. >> 3. There's no use in fighting against GNU Autoconf and GNU Automake, > > Ah, resistance is futile ? ;-o Without user acceptance, that 2 man years of effort I could sink into a new all singing all dancing build system would be a waste of my time. I'd much rather spend that time on tools people will get mileage from. >> 1. Once installed, it is useable outside the GNU eco-system by any >> build-system that is prepared to call libtool rather than the >> C-compiler for building and linking against shared compilation >> units; > > Anyone seriously doing that ? I only see a wide tendency to move away > from libtool in GNU world ... Yep. If I'm porting a cmake package (for example) to the 30 architectures we support, and shared libraries are required - calling the installed libtool from the cmake rules is an order of magnitude less work than trying to encode all the different link flags, install and post install rules or other system specific peculiarities into the compile and link rules in every build file... And also a lot easier than trying to shoehorn a libtool instance into the porting source tree. There's a perfectly good working /usr/local/bin/libtool so why not use that? > Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [9fans] contrib/install fgb/X11?
> I've been thinking there might be a way for me to contribute to contrib here > with failure cleanup, once I get a good handle on how it all works. contrib/remove didn't work? - erik
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:04 AM, David Leimbach wrote: > > > On Mon, Nov 15, 2010 at 8:01 AM, ron minnich wrote: > >> the contrib tools are based on replica and in my experience that makes >> them slow and fragile. You might want to give the 9pm stuff I did a >> try. It works,it's far faster, and they're trivial shell scripts that >> are easy to understand. Simple example, installing openssh is about 50 >> times faster -- minutes vs. hours -- using 9pm. >> >> Ah blast 9grid.net went away, I will get the guys to go kick it. >> > > I was going to ask for a link to 9pm. Is it on 9grid? > > I guess I'll search the archives to find out what 9pm is :-). > > Dave > Ah I've located your bitbucket... https://bitbucket.org/rminnich/plan9tools/src/tip/9pm/announcement Now I remember what this is. 9pm was the name of a predecessor to plan9port too IIRC. Dave > > >> >> ron >> >> >
Re: [9fans] contrib/install fgb/X11?
> the contrib tools are based on replica and in my experience that makes > them slow and fragile. My experience is I have never seen contrib be fragile, it just works, and slow - well some of the huge packages (e.g. x11) do take a while to install, but I have done that once per file server (i.e. twice) so it doesn't worry me. -Steve
Re: [9fans] p9p factotum available for plan 9
> > How do you map it to a local identity? > > There's less need to, since most rights checks would be done using the key > directly, but eve's factotum also probably has a SPKI key, and your identity > can be stringified into a path of names if necessary. in that case, what do you do with the username? do you have to change username if you rekey? - erik
Re: [9fans] Plan9 development
> *much* rather wait 90 seconds for each build that try to maintain a giant > tabulation with thousands of entries, which go out of date every time a new > patch or revision of libc or the compiler or the os or the linker comes along. there seems to be an affliction in the unix world, that started out as (a) you are required to use the esoteric features of a library within milliseconds of the release of a new version, and (b) libraries must have the maximum amount of api churn possible recently this has morphed into libraries removing "old" working functions on dot releases because of the the first condition. "modern" languages like perl and python even subscribe to this model. it's okay to break the language between releases. - erik
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:17 AM, David Leimbach wrote: > > > On Mon, Nov 15, 2010 at 8:12 AM, erik quanstrom wrote: > >> > I've been thinking there might be a way for me to contribute to contrib >> here >> > with failure cleanup, once I get a good handle on how it all works. >> >> contrib/remove didn't work? >> > > I did not try it. > Does it work on half-installed stuff? I didn't want to try it as I was > having very strange behavior of /tmp after a failed contrib/install. > I just tried contrib/remove, lots of files were rm -f'd, and in the end, contrib/install says it's still installed. > > > >> >> - erik >> >> >
Re: [9fans] contrib/install fgb/X11?
For what it's worth, I installed equis via contrib/install about a week ago and it worked. Slow, but everything installed and I was able to use it. -sl
Re: [9fans] contrib/install fgb/X11?
> having very strange behavior of /tmp after a failed contrib/install. sounds like magic. what is the behavior? - erik
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:12 AM, erik quanstrom wrote: > > I've been thinking there might be a way for me to contribute to contrib > here > > with failure cleanup, once I get a good handle on how it all works. > > contrib/remove didn't work? > I did not try it. Does it work on half-installed stuff? I didn't want to try it as I was having very strange behavior of /tmp after a failed contrib/install. > > - erik > >
Re: [9fans] 9p vs http
>% ls -lqd /n/dump/2006/0707/usr/rog >(0003d540 1122 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 7 2005 >/n/dump/2005/0707/usr/rog >% ls -lqd /n/dump/2006/0707/usr/rog >(0003d540 1157 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 12 2006 >/n/dump/2006/0707/usr/rog >they have the same qid but they're different directories >with different contents. the qid values are actually different
Re: [9fans] Plan9 development
Dan makes a good point and I agree entirely with his sentiments. But I do have a qualm: the Plan 9 designers managed to simplify cross-compilation to a single underlying (OS) platform, but failed (in a suprisingly ugly way) to cater for different target object formats, even though there were efforts to do so. In my opinion - and this is all I hold against Plan 9 - by shoehorning various target object formats in the linker/loader as options, they spoiled the consistency of the system. I have no doubt at all that this was an afterthought or at any rate an attempt to make the most of a situation they could not have control over, but I think that the problem ought to have been given more attention and a better solution sought. Of course, I can plead ignorance and stupidity and admit that I have no idea how I would address the same problem, but I'd like to raise it, because I think in a forum like this it may well stimulate the type of productive discussion that leads to a better mouse trap. To put the problem into perspective, think of Go: the developers have added more shoehorning to target ELF and possibly other object models; I'm sure that, had they had space to do it, they would have found it more fruitful to distil that portion of the development system into a separate or at least better structure. Having investigated this and painted myself into a corner, I'm curious to hear what others think of the issue. Specially those, like Russ, who were involved in the initial decisions regarding Go. Looking at the outcome, I can't help but think that the Plan 9 toolchain is infinitely superior to its current competitors. And I'd also like to point out that any shortcomings it may have regarding implementation of C99 can almost certainly be addressed within the ability of a single, no doubt gifted, but not infinitely so, individual. ++L
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:15 AM, Stanley Lieber wrote: > For what it's worth, I installed equis via contrib/install about a > week ago and it worked. Slow, but everything installed and I was able > to use it. > Thanks for that feedback. I'm having some issues with it not completing, and now /tmp says "clone failed" when I try to ls from a cwd of /tmp. > > -sl > >
Re: [9fans] contrib/install fgb/X11?
> Thanks for that feedback. I'm having some issues with it not completing, > and now /tmp says "clone failed" when I try to ls from a cwd of /tmp. okay, either a process is in the Broken state, or the file server serving /tmp has exited. you should be able to get a lot of information with ps and ns|grep /tmp - erik
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:24 AM, erik quanstrom wrote: > > having very strange behavior of /tmp after a failed contrib/install. > > sounds like magic. what is the behavior? > > getting "clone failed" when doing "ls" from a cwd of /tmp. I ended up just firing up another ramfs to move on. It looks like X11 is now installing via contrib after some manual cleanup in /dist/replica of X11 and the client subdir's X11 files. I don't honestly know what happened during the very first attempt. Could have been a network interruption I suppose, but it's difficult to tell. Dave > - erik > >
Re: [9fans] 9p vs http
2010/11/15 C H Forsyth : >>% ls -lqd /n/dump/2006/0707/usr/rog >>(0003d540 1122 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 7 2005 >>/n/dump/2005/0707/usr/rog >>% ls -lqd /n/dump/2006/0707/usr/rog >>(0003d540 1157 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 12 2006 >>/n/dump/2006/0707/usr/rog >>they have the same qid but they're different directories >>with different contents. > > the qid values are actually different true, but qid.version doesn't help much.
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:27 AM, David Leimbach wrote: > > > On Mon, Nov 15, 2010 at 8:24 AM, erik quanstrom wrote: > >> > having very strange behavior of /tmp after a failed contrib/install. >> >> sounds like magic. what is the behavior? >> >> > getting "clone failed" when doing "ls" from a cwd of /tmp. I ended up just > firing up another ramfs to move on. It looks like X11 is now installing via > contrib after some manual cleanup in /dist/replica of X11 and the client > subdir's X11 files. > > I don't honestly know what happened during the very first attempt. Could > have been a network interruption I suppose, but it's difficult to tell. > > Dave > Ah now we're failing again: error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist > > >> - erik >> >> >
Re: [9fans] 9p vs http
> > the qid values are actually different > > true, but qid.version doesn't help much. what!? i'd hate to see a file server that didn't much care which qid.version it had. those directories you listed are different. - erik
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:20 AM, David Leimbach wrote: > I just tried contrib/remove, lots of files were rm -f'd, and in the end, > contrib/install says it's still installed. Yep, that's not an unusual experience. ron
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:36 AM, David Leimbach wrote: > Ah now we're failing again: > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist been there, done that too. I realize that this all works for some people, just not for me (and a few others). And, really, it should not take hours to install a package. It should not take longer to install openssh than it takes to install ubuntu. But it does. ron
Re: [9fans] 9p vs http
On 15 November 2010 16:48, erik quanstrom wrote: >> > the qid values are actually different >> >> true, but qid.version doesn't help much. > > what!? i'd hate to see a file server that didn't > much care which qid.version it had. those directories > you listed are different. if you mount onto one, you'll see the mounted files on the other. gorka was talking about identifying files from their qid. the version number doesn't help in identifying the file - someone could have modified the file 35 times between stats. anyway, even if the version number is the same, the contents may be different.
Re: [9fans] Errors trying to install plan9
I've managed to install plan9. Finally. It appears I misunderstood the error message (messages actually - plural). The problem was that the hard-drive image I created wasn't big enough. 1GB seems to be enough though. However my troubles aren't over it seems, since as soon as I log in as glenda the screen goes blank or white with a bit of garbage (blank when the mode is 640x480x8, white when the mode is 800x600x16 or 800x600x24) 2010/11/14 Eugene Gorodinsky > Hi list! > I've been trying to install plan9 today, on a qemu vm. When trying to > install from local the installer seems unable to find quite a few files in > plan9's src directory. It seems there's some problem with the cdimage. I > tried booting from the floppy image, but got stuck at the point where one > needs to enter boot media (it seems I need something of the form fd0!file, > but I have no idea what file needs to be specified) > > Also, when trying to install in qemu from net, the installer cannot > autoconfigure network from dhcp, and doesn't work on manual configuration > either (I tried 10.0.2.1 for gateway, 10.0.2.15 for ip and 255.255.255.0 for > netmask, which should be the correct qemu settings). The boot prompt > indicates that the virtual network card has been found, though. Has anyone > tried to do a netinstall of plan9 in qemu? >
Re: [9fans] Plan9 development
> to a single underlying (OS) platform, but failed (in a > suprisingly ugly > way) to cater for different target object formats, even > though there were > efforts to do so. In my opinion - and this is all I > hold against Plan > 9 - by shoehorning various target object formats in the > linker/loader > as options, they spoiled the consistency of the system. I always had the impression that the object formats used by the various ?l are more for kernels and the various formats expected by loaders than for userland apps. For userland, I would think the intent is for there to be a single consistent object format (at least for a given architecture). BLS
Re: [9fans] p9p factotum available for plan 9
On Mon, Nov 15, 2010 at 11:22:52AM -0500, erik quanstrom wrote: > > > How do you map it to a local identity? > > > > There's less need to, since most rights checks would be done using the key > > directly, but eve's factotum also probably has a SPKI key, and your identity > > can be stringified into a path of names if necessary. > > in that case, what do you do with the username? do you have > to change username if you rekey? Hm; I wasn't thinking about rekeying. You're free to use the path from eve's factotum, which may go via a local naming authority, if you like. Then the authority simply changes its view of names in response to your rekeying and everything stays the same. --nwf; pgp6nepiyc3U2.pgp Description: PGP signature
Re: [9fans] p9p factotum available for plan 9
On Fri, Nov 12, 2010 at 3:41 PM, ron minnich wrote: > On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen > wrote: > >> Not really, the intent was that servers could implement a subset of >> the .L features, and return Rerror for any that they don't. > > Wonderful! Floren is already fixing plan 9 servers to work this way anyway :-) > Actually, I just have my streaming clients/servers give their versions as 9P2000.s; unrecognized T-messages still get silently dropped. I decided this was a better option for my current work, since it allows me to connect to any unmodified 9P file system, rather than go through and modify every single 9P server out there. That said, I definitely agree that unrecognized T-messages should get an Rerror back; I was kind of grossed out when I discovered that they were being dropped, I had figured that was part of the purpose of Rerror. If 9P ever has to change again (adding new T-messages), you'll find it a lot easier to interoperate old and new code if we get Rerrors on bogus T-messages. John
Re: [9fans] Plan9 development
> Even then, many vendor compilers and linkers have many > non-conformances, and outright bugs. Take a look at the > number of workarounds that make their way into gnulib to > cover breakage in the POSIX APIs alone. > > You can either try to remember what all of those are, or > use something like autoconf to probe for known bugs, and > gnulib to plug them, or you can link against a shim library > like GNU libposix which will do all of that automatically > when it is built and installed, allowing you to write to the > POSIX APIs with impunity. The autoconf ecosystem represents a hypothesis. I think we have gathered enough data to seriously evaluate the truth of the hypothesis, and I don't think it's worked out very well. Before auto*, the "old way" was for each package to separate out platform-specific code into a module per platform, e.g., sunos.c. That meant that each package had to have an expert for each platform, somebody who was familiar with that package and that platform and who knew C. Each time a platform revved there would be a delay while the platform expert for each package figured out what to do (generally throw in an ifdef and write a couple lines of code). In the Brave New World of GNU auto*, in theory all packages can share all of the platform-specific tweaks, and in theory the tweaks aren't specific to platforms anyway, but to features. In practice, however, when a platform revs, all of the tweak-detection code breaks, which means that a 5,000 line shell script goes "configure.sh: 4232: syntax error", and the situation can be fixed only by somebody who is an expert on: * that platform * the package * C * M4 * bash * autoconf * autoheader * libtool * gawk (the gawk scripts say #!/usr/bin/awk at the top, but woe betide anybody who attempts to run them without "awk" being gawk) So there is a delay until one of the very few people on the planet conversant with all of those things figures out what to do. The feature tests are brittle (actual example: we decide whether we have MIT Kerberos or Heimdal Kerberos by seeing whether libkrb5 contains some oddly-named extension function; a year later, the other group implements that function and kablooie, no package knows whether to -lkrbsupplemental or -lkrbadditional). In both the "old way" or the "new way", every time a platform revs most complex packages fail to build. In the first scheme, it is frequently the case that anybody competent to build a package from source can lash together a fix which works for their situation until an official fix comes out--and there's a good chance that the simple fix is actually the right fix for all users of that package on that platform. The second scheme is based on the hypothesis that one many-skilled person on one platform can tweak an immensely complex ecosystem so that it will run on many platforms that person has no access to. I think that hypothesis has turned out to be false. Packages are still buildable on exactly those platforms where an expert has done work specific to that package and that platform, only now it is much harder to diagnose and fix build problems. Essentially, the underlying assumption was that an N*M problem could be collapsed down to an N+M problem; sadly, the complexity of the result is more like 2**(N+M). Dave Eckhardt P.S. I also think we have enough data to reject the hypothesis that 5,000-line shell scripts are a good idea. Both hypotheses had their attractiveness at inception, but the point of running experiments is (hopefully) to learn from them. P.P.S. I am leaving out conundrums like "the feature tests that auto* version x.y uses are not compatible with the feature tests used by auto* version y.x, so you can't switch a package from auto* x.y to y.x, but auto* x.y predates the existence of the platform I'm trying to build on, so it does *everything* wrong on that platform".
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:46 AM, ron minnich wrote: > On Mon, Nov 15, 2010 at 8:36 AM, David Leimbach wrote: > > > Ah now we're failing again: > > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist > > been there, done that too. I realize that this all works for some > people, just not for me (and a few others). > > And, really, it should not take hours to install a package. It should > not take longer to install openssh than it takes to install ubuntu. > But it does. > > ron > > Well I just think I found out what happened to ramfs. I think I just plain ran out of RAM. :-( Dave
Re: [9fans] 9p vs http
You're way off about the merits of pipelining. As far as parallel requests are concerned, the 9P protocol beats HTTP hands down (as does basically any other request response protocol), because it has explicit unique IDs on the requests and responses. That allows a server to respond to two requests in an order different than their arrival order. If you send an expensive HTTP request followed by a cheap one, the server can't tell you the cheap answer until it has told you the expensive answer. The word "pipelining" means "we forgot to put request and response IDs into the protocol so we kludged it in by requiring responses to happen in the same order as requests." If a protocol says it has pipelining, that's always a bad sign. Russ
Re: [9fans] contrib/install fgb/X11?
>> I just tried contrib/remove, lots of files were rm -f'd, and in the end, >> contrib/install says it's still installed. > >Yep, that's not an unusual experience. educated guess at the answer... contrib/remove prints the commands to remove the package, it does not actually do the removal, thats up to you to select the text abd submit it, in a similar way to slay(1). It also preprnds a hash to the rm command for any files which do not match those installed - so if you have changed one of the packages files it is not removed by default. does this clear things up? -Steve
Re: [9fans] contrib/install fgb/X11?
> error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist This looks like the fault of the person who generated the package (though I may be wrong). -Steve
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 10:34 AM, David Leimbach wrote: > > > On Mon, Nov 15, 2010 at 8:46 AM, ron minnich wrote: > >> On Mon, Nov 15, 2010 at 8:36 AM, David Leimbach >> wrote: >> >> > Ah now we're failing again: >> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist >> > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist >> > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist >> > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist >> > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist >> >> been there, done that too. I realize that this all works for some >> people, just not for me (and a few others). >> >> And, really, it should not take hours to install a package. It should >> not take longer to install openssh than it takes to install ubuntu. >> But it does. >> >> ron >> >> Well I just think I found out what happened to ramfs. I think I just > plain ran out of RAM. :-( > > Dave > Nope, I upped my RAM, cleaned up, and tried again, and I'm still getting those errors :-( 9grid appears to still be down so I can't give Ron's 9pm a shot. Dave
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 10:47 AM, Steve Simon wrote: > > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist > > This looks like the fault of the person who generated the package (though > I may be wrong). > > -Steve > > The package doesn't appear to have been touched since 2009, and some folks were claiming they just installed it over the last few weeks. It could be operator error, but the other dependencies installed fine the way I was doing it :-). Dave
Re: [9fans] 9p vs http
That brings up a question of interest to me. How do you effectively read ahead with the 9p protocol? Even if you issued many read requests in parallel, the server is allowed to return less data than was asked for. You'll end up with holes in your buffer that require at least another roundtrip to fill. -Dan
Re: [9fans] 9p vs http
> if you mount onto one, you'll see the mounted files > on the other. > > gorka was talking about identifying files from their qid. > the version number doesn't help in identifying the file - > someone could have modified the file 35 times between > stats. what definition of "file" are you using? you've rejected the definition that "file" is identified uniquely by path. you've also rejected the definition that file is identified uniquely by qid. > anyway, even if the version number is the same, the contents > may be different. i claim that a fs with this behavior would be broken. intro(5) seems to agree with this claim, unless i'm misreading. - erik
Re: [9fans] Plan9 development
My personal disappointment with autoconf, is that there was no simple file which the package author writes (or even autgenerates) describing what features their package depends on. There is a file, but its anything but simple and as it (ab)uses m4 and shell script macros that it "knows" exist. It is not reasonable to analyse this file on a foreign OS (e.g. plan9) and work out what might be required to build the package. -Steve
Re: [9fans] 9p vs http
On 15 November 2010 19:29, erik quanstrom wrote:
>> if you mount onto one, you'll see the mounted files
>> on the other.
>>
>> gorka was talking about identifying files from their qid.
>> the version number doesn't help in identifying the file -
>> someone could have modified the file 35 times between
>> stats.
>
> what definition of "file" are you using? you've rejected the
> definition that "file" is identified uniquely by path.
i've only rejected that definition based on observation - intro(5)
does state that the qid path should be unique amongst all files
in the hierarchy, but that's a difficult ideal to live up to
when you're multiplexing filesystems.
>> anyway, even if the version number is the same, the contents
>> may be different.
>
> i claim that a fs with this behavior would be broken. intro(5)
> seems to agree with this claim, unless i'm misreading.
you're right - fossil is broken in this respect, as is exportfs
{cd /mnt/term/dev; ls -lq | sort} for a quick demo.
the only correct way that i can see for a multiplexing fs to avoid this breakage
is the keep track of every qid that it sees, allocating a new qid of its
own for each one. no-one does this because it can use unbounded
memory. instead they map qids on open, because relatively
few files are opened.
that's why i was suggesting a "big enough" qid space as another
possibility. an alternative might be to remove qids from the
Dir structure entirely, returning them only on walk and open.
Re: [9fans] contrib/install fgb/X11?
> error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist Do you run stats(1) while doing the pull? Does it shows any anomalities, especially memory consuption? - Yaroslav
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav wrote: > > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist > > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist > > Do you run stats(1) while doing the pull? Does it shows any > anomalities, especially memory consuption? > > - Yaroslav > > I've not looked at memory consumption, but load and such look pretty normal. I'm running with 512MB RAM at the moment in the VM. Dave
Re: [9fans] 9p vs http
> That brings up a question of interest to me. How do you effectively > read ahead with the 9p protocol? Even if you issued many read > requests in parallel, the server is allowed to return less data than > was asked for. You'll end up with holes in your buffer that require > at least another roundtrip to fill. The option is to make servers obey R order for Ts with same tag - just as Russ (right?) proposed elsewhere on the list.
Re: [9fans] 9p vs http
> The option is to make servers obey R order for Ts with same tag - just > as Russ (right?) proposed elsewhere on the list. no. tags have no order and clients are specificly disallowed from having multiple messages with the same tag outstanding. again, see intro(5). the option is to issue many Tread/Twrite messages concurrently, say from the mount driver. not all file servers will be able to deal with this, so it'd need to be a mount flag. - erik
Re: [9fans] contrib/install fgb/X11?
also it shouldn't take that long... if you have the latest contrib tools what happens it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from there. of course that iso.bz2 is 22 MB, but that's not contrib's fault On Mon, Nov 15, 2010 at 8:33 PM, Federico G. Benavento wrote: > the easiest way to reinstall is > > % contrib/install -f usr/pkg > > On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach wrote: >> >> >> On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav wrote: >>> >>> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist >>> > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist >>> > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist >>> > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist >>> > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist >>> >>> Do you run stats(1) while doing the pull? Does it shows any >>> anomalities, especially memory consuption? >>> >>> - Yaroslav >>> >> I've not looked at memory consumption, but load and such look pretty normal. >> I'm running with 512MB RAM at the moment in the VM. >> Dave > > > > -- > Federico G. Benavento > -- Federico G. Benavento
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento wrote: > also it shouldn't take that long... if you have the latest contrib > tools what happens > it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from > there. > > of course that iso.bz2 is 22 MB, but that's not contrib's fault > I installed the contrib tools today, so those are pretty new. I wonder if my tmp is big enough... I've got 512MB of ram but I don't know the size of my tmp off the top of my head. I'll have to look at it later. Dave > > On Mon, Nov 15, 2010 at 8:33 PM, Federico G. Benavento > wrote: > > the easiest way to reinstall is > > > > % contrib/install -f usr/pkg > > > > On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach > wrote: > >> > >> > >> On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav wrote: > >>> > >>> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist > >>> > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist > >>> > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist > >>> > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist > >>> > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist > >>> > >>> Do you run stats(1) while doing the pull? Does it shows any > >>> anomalities, especially memory consuption? > >>> > >>> - Yaroslav > >>> > >> I've not looked at memory consumption, but load and such look pretty > normal. > >> I'm running with 512MB RAM at the moment in the VM. > >> Dave > > > > > > > > -- > > Federico G. Benavento > > > > > > -- > Federico G. Benavento > >
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 3:42 PM, David Leimbach wrote: > > > On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento < > benave...@gmail.com> wrote: > >> also it shouldn't take that long... if you have the latest contrib >> tools what happens >> it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from >> there. >> >> of course that iso.bz2 is 22 MB, but that's not contrib's fault >> > > I installed the contrib tools today, so those are pretty new. > > I wonder if my tmp is big enough... I've got 512MB of ram but I don't know > the size of my tmp off the top of my head. I'll have to look at it later. > > Dave > I should just try again with ramfs -u I suppose (unlimited... pheer!) Dave > > >> >> On Mon, Nov 15, 2010 at 8:33 PM, Federico G. Benavento >> wrote: >> > the easiest way to reinstall is >> > >> > % contrib/install -f usr/pkg >> > >> > On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach >> wrote: >> >> >> >> >> >> On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav wrote: >> >>> >> >>> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist >> >>> > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist >> >>> > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist >> >>> > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist >> >>> > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist >> >>> >> >>> Do you run stats(1) while doing the pull? Does it shows any >> >>> anomalities, especially memory consuption? >> >>> >> >>> - Yaroslav >> >>> >> >> I've not looked at memory consumption, but load and such look pretty >> normal. >> >> I'm running with 512MB RAM at the moment in the VM. >> >> Dave >> > >> > >> > >> > -- >> > Federico G. Benavento >> > >> >> >> >> -- >> Federico G. Benavento >> >> >
Re: [9fans] contrib/install fgb/X11?
the easiest way to reinstall is % contrib/install -f usr/pkg On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach wrote: > > > On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav wrote: >> >> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist >> > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist >> > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not exist >> > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist >> > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist >> >> Do you run stats(1) while doing the pull? Does it shows any >> anomalities, especially memory consuption? >> >> - Yaroslav >> > I've not looked at memory consumption, but load and such look pretty normal. > I'm running with 512MB RAM at the moment in the VM. > Dave -- Federico G. Benavento
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 3:45 PM, David Leimbach wrote: > > > On Mon, Nov 15, 2010 at 3:42 PM, David Leimbach wrote: > >> >> >> On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento < >> benave...@gmail.com> wrote: >> >>> also it shouldn't take that long... if you have the latest contrib >>> tools what happens >>> it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from >>> there. >>> >>> of course that iso.bz2 is 22 MB, but that's not contrib's fault >>> >> >> I installed the contrib tools today, so those are pretty new. >> >> I wonder if my tmp is big enough... I've got 512MB of ram but I don't >> know the size of my tmp off the top of my head. I'll have to look at it >> later. >> >> Dave >> > > I should just try again with ramfs -u I suppose (unlimited... pheer!) > That did not help at all. Could the ISO be messed up? error: copying /sys/src/ape/X11/lib/dmx/man/DMXChangeScreensAttributes.: '/n/dist/sys/src/ape/X11/lib/dmx/man/DMXChangeScreensAttributes.' does not exist Dave > > Dave > > >> >> >>> >>> On Mon, Nov 15, 2010 at 8:33 PM, Federico G. Benavento >>> wrote: >>> > the easiest way to reinstall is >>> > >>> > % contrib/install -f usr/pkg >>> > >>> > On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach >>> wrote: >>> >> >>> >> >>> >> On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav wrote: >>> >>> >>> >>> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not exist >>> >>> > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist >>> >>> > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not >>> exist >>> >>> > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist >>> >>> > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist >>> >>> >>> >>> Do you run stats(1) while doing the pull? Does it shows any >>> >>> anomalities, especially memory consuption? >>> >>> >>> >>> - Yaroslav >>> >>> >>> >> I've not looked at memory consumption, but load and such look pretty >>> normal. >>> >> I'm running with 512MB RAM at the moment in the VM. >>> >> Dave >>> > >>> > >>> > >>> > -- >>> > Federico G. Benavento >>> > >>> >>> >>> >>> -- >>> Federico G. Benavento >>> >>> >> >
Re: [9fans] contrib/install fgb/X11?
nope, the log is the problem, but anyways, ignore those errors, the installation worked just fine. I'll try to remove them, so it doesn't confuse anyone On Mon, Nov 15, 2010 at 8:56 PM, David Leimbach wrote: > > > On Mon, Nov 15, 2010 at 3:45 PM, David Leimbach wrote: >> >> >> On Mon, Nov 15, 2010 at 3:42 PM, David Leimbach wrote: >>> >>> >>> On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento >>> wrote: also it shouldn't take that long... if you have the latest contrib tools what happens it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from there. of course that iso.bz2 is 22 MB, but that's not contrib's fault >>> >>> I installed the contrib tools today, so those are pretty new. >>> I wonder if my tmp is big enough... I've got 512MB of ram but I don't >>> know the size of my tmp off the top of my head. I'll have to look at it >>> later. >>> Dave >> >> I should just try again with ramfs -u I suppose (unlimited... pheer!) > > That did not help at all. Could the ISO be messed up? > error: copying /sys/src/ape/X11/lib/dmx/man/DMXChangeScreensAttributes.: > '/n/dist/sys/src/ape/X11/lib/dmx/man/DMXChangeScreensAttributes.' does not > exist > Dave > >> >> Dave >> >>> >>> On Mon, Nov 15, 2010 at 8:33 PM, Federico G. Benavento wrote: > the easiest way to reinstall is > > % contrib/install -f usr/pkg > > On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach > wrote: >> >> >> On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav wrote: >>> >>> > error: copying /386/bin/X11/equis: '/n/dist/386/bin' does not >>> > exist >>> > error: copying /386/bin/X11/twm: '/n/dist/386/bin' does not exist >>> > error: copying /386/bin/X11/xclock: '/n/dist/386/bin' does not >>> > exist >>> > error: copying /386/bin/X11/xev: '/n/dist/386/bin' does not exist >>> > error: copying /386/bin/X11/xset: '/n/dist/386/bin' does not exist >>> >>> Do you run stats(1) while doing the pull? Does it shows any >>> anomalities, especially memory consuption? >>> >>> - Yaroslav >>> >> I've not looked at memory consumption, but load and such look pretty >> normal. >> I'm running with 512MB RAM at the moment in the VM. >> Dave > > > > -- > Federico G. Benavento > -- Federico G. Benavento >>> >> > > -- Federico G. Benavento
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento wrote: > also it shouldn't take that long... if you have the latest contrib > tools what happens > it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from there. > neat. That's a good step. 9pm won't use replica but at the same time this looks like a great idea. ron
Re: [9fans] 9p vs http
> > i claim that a fs with this behavior would be broken. intro(5)
> > seems to agree with this claim, unless i'm misreading.
>
> you're right - fossil is broken in this respect, as is exportfs
> {cd /mnt/term/dev; ls -lq | sort} for a quick demo.
so what's fossil's excuse?
- erik
Re: [9fans] Plan9 development
> I always had the impression that the object formats > used by the various ?l are more for kernels and the > various formats expected by loaders than for userland > apps. For userland, I would think the intent is for > there to be a single consistent object format (at least > for a given architecture). Well, we had alef for Irix and other similar user level/application level tricks that no longer seem important today, but without the option trickery Go would have had to wait for Ian Lance Taylor to produce a GCC version :-( Myself, I'm still trying to combine the Go toolchain with the Plan 9 toolchain so that we can have a consistent framework for real cross-platform development, but the task doesn't quite fit within my resources and skills. I don't have a problem with the trickery, it's just a shame (IMO) that it wasn't designed the same way as the target architecture stuff. I understand the complexity involved and I'm still looking for ideas on reducing that complexity. Typically, the Go toolchain still has (had?) code in it to produce Plan 9 object code, but one could easily imagine that stuff bit-rotting. If it hasn't been removed yet, it sure runs the risk of being removed before long. Of course, the ideal situation would be for Go and p9p to converge and the whole lot to be back ported to Plan 9. I think it's possible, but somebody of my skill level trying to do this will often need to be rescued after painting himself in a corner. But I have made a start and, again, I must rescue and document my efforts, lest somebody have to go through those pains again unnecessarily. ++L PS: I think 9vx has brought me closer to this objective, but it's still orders of magnitude bigger than I am competent. But less so than the auto* stuff.
[9fans] That deadlock, again
Regarding the "deadlock" report that I occasionally see on my CPU server console, I won't bore anyone with PC addresses or anything like that, but I will recommend something I believe to be a possible trigger: the failure always seems to occur within "exportfs", which in this case is used exclusively to run stats(1) remotely from my workstation. So the recommendation is that somebody like Erik, who is infinitely more clued up than I am in the kernel arcana should run one or more stats sessions into a cpu server (I happen to be running fossil, so maybe Erik won't see this) and see if he can also trigger this behaviour. I'm hoping that it is not platform specific. Right now, I'm short of skills as well as a serial console :-( ++L PS: here is a kmesg from the server: Plan 9 E820: 0009fc00 memory E820: 0009fc00 000a reserved E820: 000e 0010 reserved E820: 0010 4774 memory E820: 4774 4775 acpi reclaim E820: 4775 4780 acpi nvs 126 holes free 00018000 0009f000 552960 00468000 0642b000 100413440 100966400 bytes free cpu0: 2599MHz GenuineIntel PentiumIV/Xeon (cpuid: AX 0x0F29 DX 0xBFEBFBFF) ELCR: 0E28 #l0: i82557: 100Mbps port 0xDC00 irq 11: 0004e0b6 1143M memory: 100M kernel data, 1043M user, 1668M swap root is from (tcp, local)[local!#S/sdC0/fossil]: time... venti...2010/1115 17:36:16 venti: conf.../boot/venti: mem 31,972,556 bcmem 63,945,112 icmem 95,917,670...httpd tcp!127.1!8000...init...icache 95,917,670 bytes = 1,498,714 entries; 16 scache sync...announce tcp!127.1!17034...serving. fossil(#S/sdC0/fossil)...fsys: dialing venti at tcp!127.1!17034 version...time... init: starting /bin/rc which also supplies: lock 0xf09d8980 loop key 0xdeaddead pc 0xf01e736a held by pc 0xf01e736a proc 2052 17: #I0tcpack pc f01ff12a dbgpc0 Running (Running) ut 530 st 0 bss 0 qpc f014583c nl 0 nd 0 lpc f01e2cc8 pri 13 2052: exportfs pc f01efc9f dbgpc 94adPwrite (Ready) ut 43 st 209 bss 4 qpc f0145b62 nl 1 nd 0 lpc f01e2c60 pri 10 and, a bit later: lock 0xf0057d74 loop key 0xdeaddead pc 0xf01e736a held by pc 0xf01e736a proc 2052 61:etherread4 pc f01ef8a0 dbgpc0 Running (Running) ut 2923 st 0 bss 0 qpc f0148c8a nl 0 nd 0 lpc f0100f6e pri 13 2052: exportfs pc f01e7377 dbgpc 94adPwrite (Ready) ut 55 st 270 bss 4 qpc f0145b62 nl 1 nd 0 lpc f01e2c60 pri 10 to my surprise.
Re: [9fans] That deadlock, again
On Mon Nov 15 23:23:12 EST 2010, lu...@proxima.alt.za wrote: > Regarding the "deadlock" report that I occasionally see on my CPU > server console, I won't bore anyone with PC addresses or anything like > that, but I will recommend something I believe to be a possible > trigger: the failure always seems to occur within "exportfs", which in > this case is used exclusively to run stats(1) remotely from my > workstation. So the recommendation is that somebody like Erik, who is > infinitely more clued up than I am in the kernel arcana should run one > or more stats sessions into a cpu server (I happen to be running > fossil, so maybe Erik won't see this) and see if he can also trigger this > behaviour. I'm hoping that it is not platform specific. > > Right now, I'm short of skills as well as a serial console :-( i run stats all the time. i've never seen a lock loop caused by stats. exportfs gets blamed all the time for the sins of others. possible culprits are the tcp/ip stack and the kernel devices that stats accesses and of course, the channel code itself. it would be a good idea for you to track down all the pcs involved and send them along. i can't think of another way of narrowing down the list of potential suspects. not all of our usual suspects has an alibi. i assume you've fixed this? (not yet fixed on sources.) /n/sources/plan9//sys/src/9/port/chan.c:1012,1018 - chan.c:1012,1020 /* * mh->mount->to == c, so start at mh->mount->next */ + f = nil; rlock(&mh->lock); + if(mh->mount) for(f = mh->mount->next; f; f = f->next) if((wq = ewalk(f->to, nil, names+nhave, ntry)) != nil) break; - erik
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 4:59 PM, ron minnich wrote: > On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento > wrote: > > also it shouldn't take that long... if you have the latest contrib > > tools what happens > > it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from > there. > > > > > neat. That's a good step. 9pm won't use replica but at the same time > this looks like a great idea. > > ron > > Ah ok, well it does in fact appear to be working. Took me a minute to realize I needed to set my DISPLAY to :0. I have an old shell bundle of linuxemu dillo, but that does *not* work. Xclock does. cpu% ./dillo [624803] syscall 191/ugetrlimit not implemented [624803] syscall 149/sysctl not implemented Gdk-WARNING **: locale not supported by Xlib, locale set to C Gdk-WARNING **: can not set locale modifiers [624803] syscall 209/newgetresuid not implemented _X11TransSocketOpen: socket() failed for local _X11TransSocketOpenCOTSClient: Unable to open socket for local _X11TransOpen: transport open failed for local/virtualbunny:0 Gtk-WARNING **: cannot open display: :0 cpu% Dave
Re: [9fans] Plan9 development
> Of course, the ideal situation would be for Go and p9p to converge and > the whole lot to be back ported to Plan 9. if you just want go on plan 9, i think object formats are a non-sequitor. calling out the guys who wrote plan 9 for not supporting object formats that plan 9 never used, seems a bit rude to me. - erik
Re: [9fans] contrib/install fgb/X11?
ok, dillo is a linux binary, right? and it looks like is looking for a unix socket, but equis has APE sockets! so for dillo try tcp DISPLAY=127.0.0.1:0 On Tue, Nov 16, 2010 at 1:47 AM, David Leimbach wrote: > > > On Mon, Nov 15, 2010 at 4:59 PM, ron minnich wrote: >> >> On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento >> wrote: >> > also it shouldn't take that long... if you have the latest contrib >> > tools what happens >> > it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from >> > there. >> > >> >> >> neat. That's a good step. 9pm won't use replica but at the same time >> this looks like a great idea. >> >> ron >> > Ah ok, well it does in fact appear to be working. Took me a minute to > realize I needed to set my DISPLAY to :0. > I have an old shell bundle of linuxemu dillo, but that does *not* work. > Xclock does. > cpu% ./dillo > [624803] syscall 191/ugetrlimit not implemented > [624803] syscall 149/sysctl not implemented > Gdk-WARNING **: locale not supported by Xlib, locale set to C > Gdk-WARNING **: can not set locale modifiers > [624803] syscall 209/newgetresuid not implemented > _X11TransSocketOpen: socket() failed for local > _X11TransSocketOpenCOTSClient: Unable to open socket for local > _X11TransOpen: transport open failed for local/virtualbunny:0 > Gtk-WARNING **: cannot open display: :0 > cpu% > Dave -- Federico G. Benavento
Re: [9fans] contrib/install fgb/X11?
btw, there are no lbuns for firefox and such, but it works, opera does too On Tue, Nov 16, 2010 at 1:57 AM, Federico G. Benavento wrote: > ok, dillo is a linux binary, right? and it looks like is looking for > a unix socket, > but equis has APE sockets! > so for dillo try tcp DISPLAY=127.0.0.1:0 > > > On Tue, Nov 16, 2010 at 1:47 AM, David Leimbach wrote: >> >> >> On Mon, Nov 15, 2010 at 4:59 PM, ron minnich wrote: >>> >>> On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento >>> wrote: >>> > also it shouldn't take that long... if you have the latest contrib >>> > tools what happens >>> > it's this: it first fcp's an iso.bz2 to your /tmp and runs replica from >>> > there. >>> > >>> >>> >>> neat. That's a good step. 9pm won't use replica but at the same time >>> this looks like a great idea. >>> >>> ron >>> >> Ah ok, well it does in fact appear to be working. Took me a minute to >> realize I needed to set my DISPLAY to :0. >> I have an old shell bundle of linuxemu dillo, but that does *not* work. >> Xclock does. >> cpu% ./dillo >> [624803] syscall 191/ugetrlimit not implemented >> [624803] syscall 149/sysctl not implemented >> Gdk-WARNING **: locale not supported by Xlib, locale set to C >> Gdk-WARNING **: can not set locale modifiers >> [624803] syscall 209/newgetresuid not implemented >> _X11TransSocketOpen: socket() failed for local >> _X11TransSocketOpenCOTSClient: Unable to open socket for local >> _X11TransOpen: transport open failed for local/virtualbunny:0 >> Gtk-WARNING **: cannot open display: :0 >> cpu% >> Dave > > > > -- > Federico G. Benavento > -- Federico G. Benavento
Re: [9fans] That deadlock, again
> i assume you've fixed this? (not yet fixed on sources.) Yes, before I did that the errors occurred much more frequently; there's definitely something in that, but as Russ points out, the fix prevents panics and I have yet to see a panic. I have a suspicion that we're looking at the wrong problem, but I don't know how to approach it. I tried acid, but I'm just not familiar enough with it to make it work. I tried rumble% acid 2052 /bin/exportfs /bin/exportfs:386 plan 9 executable /sys/lib/acid/port /sys/lib/acid/386 acid: src(0xf01e7377) no source for ?file? and that's where I have to leave it for the time being. But suggestions are welcome, I'll be back here at the end of the day (it's 07:00 now, I expect to be back after 19:00). ++L
Re: [9fans] contrib/install fgb/X11?
On Mon, Nov 15, 2010 at 8:57 PM, Federico G. Benavento wrote: > ok, dillo is a linux binary, right? and it looks like is looking for > a unix socket, > but equis has APE sockets! > so for dillo try tcp DISPLAY=127.0.0.1:0 I did try that, thinking that could have been the problem. It didn't work, but I got a different error. cpu% ./dillo [625584] syscall 191/ugetrlimit not implemented [625584] syscall 149/sysctl not implemented Gdk-WARNING **: locale not supported by Xlib, locale set to C Gdk-WARNING **: can not set locale modifiers [625584] syscall 209/newgetresuid not implemented segbrk failed in munmap: device or object already in usecpu% > > > > On Tue, Nov 16, 2010 at 1:47 AM, David Leimbach wrote: > > > > > > On Mon, Nov 15, 2010 at 4:59 PM, ron minnich wrote: > >> > >> On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento > >> wrote: > >> > also it shouldn't take that long... if you have the latest contrib > >> > tools what happens > >> > it's this: it first fcp's an iso.bz2 to your /tmp and runs replica > from > >> > there. > >> > > >> > >> > >> neat. That's a good step. 9pm won't use replica but at the same time > >> this looks like a great idea. > >> > >> ron > >> > > Ah ok, well it does in fact appear to be working. Took me a minute to > > realize I needed to set my DISPLAY to :0. > > I have an old shell bundle of linuxemu dillo, but that does *not* work. > > Xclock does. > > cpu% ./dillo > > [624803] syscall 191/ugetrlimit not implemented > > [624803] syscall 149/sysctl not implemented > > Gdk-WARNING **: locale not supported by Xlib, locale set to C > > Gdk-WARNING **: can not set locale modifiers > > [624803] syscall 209/newgetresuid not implemented > > _X11TransSocketOpen: socket() failed for local > > _X11TransSocketOpenCOTSClient: Unable to open socket for local > > _X11TransOpen: transport open failed for local/virtualbunny:0 > > Gtk-WARNING **: cannot open display: :0 > > cpu% > > Dave > > > > -- > Federico G. Benavento > >
Re: [9fans] Plan9 development
> if you just want go on plan 9, i think object formats > are a non-sequitor. > But that's not it, really, I want both Go and the ELF capabilities :-) > calling out the guys who wrote plan 9 for not supporting > object formats that plan 9 never used, seems a bit rude > to me. I am willing to apologise if that is how it's perceived, but the intent is not to insult anyone, but rather to extend the Plan 9 toolchain beyond the Plan 9 scope, something the Go developers did to a great extent and something I would dearly like to retrofit to Plan 9. Getting Go in the bargain is an exciting side effect. ++L
Re: [9fans] That deadlock, again
the pc's printed by the lock loop message are kernel code. you have to load a debug kernel into acid. -- cinap --- Begin Message --- > i assume you've fixed this? (not yet fixed on sources.) Yes, before I did that the errors occurred much more frequently; there's definitely something in that, but as Russ points out, the fix prevents panics and I have yet to see a panic. I have a suspicion that we're looking at the wrong problem, but I don't know how to approach it. I tried acid, but I'm just not familiar enough with it to make it work. I tried rumble% acid 2052 /bin/exportfs /bin/exportfs:386 plan 9 executable /sys/lib/acid/port /sys/lib/acid/386 acid: src(0xf01e7377) no source for ?file? and that's where I have to leave it for the time being. But suggestions are welcome, I'll be back here at the end of the day (it's 07:00 now, I expect to be back after 19:00). ++L --- End Message ---
Re: [9fans] That deadlock, again
> the pc's printed by the lock loop message are kernel code. you > have to load a debug kernel into acid. Thanks, I'll do some digging in the Acid document(s), try to familiarise myself with the details... ++L
Re: [9fans] contrib/install fgb/X11?
there is a very old version of linuxemu in that lbun... the current one supports ape unix domain sockets (even server side). it might be possible to repack the lbun with a current version, but i can't remember the details. -- cinap --- Begin Message --- On Mon, Nov 15, 2010 at 8:57 PM, Federico G. Benavento wrote: > ok, dillo is a linux binary, right? and it looks like is looking for > a unix socket, > but equis has APE sockets! > so for dillo try tcp DISPLAY=127.0.0.1:0 I did try that, thinking that could have been the problem. It didn't work, but I got a different error. cpu% ./dillo [625584] syscall 191/ugetrlimit not implemented [625584] syscall 149/sysctl not implemented Gdk-WARNING **: locale not supported by Xlib, locale set to C Gdk-WARNING **: can not set locale modifiers [625584] syscall 209/newgetresuid not implemented segbrk failed in munmap: device or object already in usecpu% > > > > On Tue, Nov 16, 2010 at 1:47 AM, David Leimbach wrote: > > > > > > On Mon, Nov 15, 2010 at 4:59 PM, ron minnich wrote: > >> > >> On Mon, Nov 15, 2010 at 3:37 PM, Federico G. Benavento > >> wrote: > >> > also it shouldn't take that long... if you have the latest contrib > >> > tools what happens > >> > it's this: it first fcp's an iso.bz2 to your /tmp and runs replica > from > >> > there. > >> > > >> > >> > >> neat. That's a good step. 9pm won't use replica but at the same time > >> this looks like a great idea. > >> > >> ron > >> > > Ah ok, well it does in fact appear to be working. Took me a minute to > > realize I needed to set my DISPLAY to :0. > > I have an old shell bundle of linuxemu dillo, but that does *not* work. > > Xclock does. > > cpu% ./dillo > > [624803] syscall 191/ugetrlimit not implemented > > [624803] syscall 149/sysctl not implemented > > Gdk-WARNING **: locale not supported by Xlib, locale set to C > > Gdk-WARNING **: can not set locale modifiers > > [624803] syscall 209/newgetresuid not implemented > > _X11TransSocketOpen: socket() failed for local > > _X11TransSocketOpenCOTSClient: Unable to open socket for local > > _X11TransOpen: transport open failed for local/virtualbunny:0 > > Gtk-WARNING **: cannot open display: :0 > > cpu% > > Dave > > > > -- > Federico G. Benavento > > --- End Message ---
Re: [9fans] That deadlock, again
you almost had it with your acid approach :) if your kernel image is uncompressed and is unstriped, you can just load it with acid: acid /386/9pc if you build it yourself, then there should be such a kernel in /sys/src/9/pc -- cinap --- Begin Message --- > the pc's printed by the lock loop message are kernel code. you > have to load a debug kernel into acid. Thanks, I'll do some digging in the Acid document(s), try to familiarise myself with the details... ++L --- End Message ---
Re: [9fans] That deadlock, again
On Tue, Nov 16, 2010 at 06:28:07AM +0100, cinap_len...@gmx.de wrote: > > if your kernel image is uncompressed and is unstriped, you can > just load it with acid: > > acid /386/9pc > > if you build it yourself, then there should be such a kernel in /sys/src/9/pc > OK, will try this evening, I specifically left the machines on to do so, I'm very keen to help put this issue to rest. And to get to know the kernel more initmately. Pity Nemo isn't updating his commentary. ++L
