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 s...@nipl.net 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 pau...@gmail.com wrote: On Mon, Nov 15, 2010 at 6:16 AM, Sam Watkins s...@nipl.net 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 pau...@gmail.com 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 s...@nipl.net 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 g...@vaughan.pe 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 of
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 j...@corpus-callosum.comwrote: 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 m...@acm.jhu.edu 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 rminn...@gmail.com 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 weig...@metux.de wrote: * Gary V. Vaughan g...@gnu.org 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 leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 8:01 AM, ron minnich rminn...@gmail.com 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] 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 leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 8:12 AM, erik quanstrom quans...@quanstro.netwrote: 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?
having very strange behavior of /tmp after a failed contrib/install. sounds like magic. what is the behavior? - 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 stanley.lie...@gmail.comwrote: 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 quans...@quanstro.netwrote: 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 fors...@vitanuova.com: % 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 leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 8:24 AM, erik quanstrom quans...@quanstro.netwrote: 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 leim...@gmail.com 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 leim...@gmail.com 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 quans...@quanstro.net 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 e.gorodin...@gmail.com 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 rminn...@gmail.com wrote: On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen eri...@gmail.com 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] 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 leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 8:46 AM, ron minnich rminn...@gmail.com wrote: On Mon, Nov 15, 2010 at 8:36 AM, David Leimbach leim...@gmail.com 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] 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 quans...@labs.coraid.com 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 yari...@gmail.com 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 benave...@gmail.com wrote: the easiest way to reinstall is % contrib/install -f usr/pkg On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav yari...@gmail.com 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 benave...@gmail.comwrote: 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 benave...@gmail.com wrote: the easiest way to reinstall is % contrib/install -f usr/pkg On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav yari...@gmail.com 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 leim...@gmail.com 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 benave...@gmail.com wrote: the easiest way to reinstall is % contrib/install -f usr/pkg On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav yari...@gmail.com 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 leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav yari...@gmail.com 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 leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 3:42 PM, David Leimbach leim...@gmail.com 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 benave...@gmail.com wrote: the easiest way to reinstall is % contrib/install -f usr/pkg On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav yari...@gmail.com 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 leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 3:45 PM, David Leimbach leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 3:42 PM, David Leimbach leim...@gmail.com 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 benave...@gmail.com wrote: the easiest way to reinstall is % contrib/install -f usr/pkg On Mon, Nov 15, 2010 at 6:52 PM, David Leimbach leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 1:50 PM, Yaroslav yari...@gmail.com 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 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. 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] 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 benave...@gmail.com 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 leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 4:59 PM, ron minnich rminn...@gmail.com 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. 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 benave...@gmail.comwrote: 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 leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 4:59 PM, ron minnich rminn...@gmail.com 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. 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 ---BeginMessage--- 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 ---BeginMessage--- On Mon, Nov 15, 2010 at 8:57 PM, Federico G. Benavento benave...@gmail.comwrote: 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 leim...@gmail.com wrote: On Mon, Nov 15, 2010 at 4:59 PM, ron minnich rminn...@gmail.com 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. 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 ---BeginMessage--- 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
