Re: [9fans] sad commentary
Mozilla didn't create the web. The web created Mozilla. just change Mozilla to Mosaic and see how P→Q suddenly becomes Q→P
Re: [9fans] sad commentary
hello 256 MB of ram fills quite easily when using a fossil+venti and when trying new incarnations of upas/fs :), i can't even compile some ports of gnu things ☺. Fortunately this will change in august, as 9grid.es will have 1Gb of memory. about the unstability, i should disable swap partition to see if that fix something ☺ greetings, gabi PS: sorry for the off-topic non-sad comentary :P
Re: [9fans] sad commentary
UTF-8in an English-only user paradigm is only extravagance. You are naïve.
Re: [9fans] sad commentary
why are you flaming somebody who's offering reasonable opinions? Think Pascal: it is hardly the language of choice today, but the principles it enshrines have totally altered the programming language landscape. C is the utility version, and C++ and Java its obvious Sure uhhh yeah whatever you say Or was it Algol? this stands out as particularly worth of rebuttal. the labs were against types. but in the end even the labs adopted them. offsprings. Alef has been abandoned and Limbo remains a very specialised language, but they will also leave their mark. So does a dog pissing on a fire hydrant. perhaps you've forgotten that the thread library is a direct result of alef. [...], but in reality it is the philosophy behind Plan 9 that needs spreading: careful design, generalised objects, simplicity rather than bulk, etc. Not Rio or Acme, Fossil or Venti, but the environment in which they can thrive. The environment in which Mozilla is difficult to create so that simpler solutions can be sought. Mozilla didn't create the web. The web created Mozilla. either way, we're back to my point. linux . al. are going a different way, which i don't feel is very fruitful. they are working from a different set of ideas. it's not that i (or unfairly we — i can't and wasn't speaking for the plan 9 community) have an egotisitical desire to see plan 9's ideas take over the world. it's that i see problems that seem pretty straightforward to solve made difficult. with repetition, i feel this process erodes computing in general as there is no avoiding other platforms. these are tetonic forces. there's nothing directly to be done about them. so my point is like a bad poem. there's no and then part. - erik
Re: [9fans] sad commentary
256 MB of ram fills quite easily when using a fossil+venti and when trying new incarnations of upas/fs :), the manual pages for venti and fossil do spell out a number of parameters to control memory usage. but you probablly knew that. running the fs on the same machine as the cpu server can be a problem when used heavily. plan 9 overcommits physical memory. and fossil or venti may be left holding the bag. ndb/dns also has an ever-growing footprint. i can't even compile some ports of gnu things ☺. glad to hear that there is a silver lining. about the unstability, i should disable swap partition to see if that fix something ☺ i find important to comb the kernel panic messages. running out of kernel memory is fatal. however, it could be that you are using very little and can decrease kernelpercent. - erik
Re: [9fans] sad commentary
Also, public 9grids. Though judging by gdiaz's experiences with sirviente, there's a bit of work to be done in that area - I get the impression things are fairly unstable once the machine gets under memory pressure. -sqweek i think this is an artifact of setting up heavily-used systems combining venti, fossil, auth and cpu server. i think you may be blaming plan 9 when in fact there's just not enough hardware to go around. sure crashing is antisocial. the alternative is to add very large amounts of code to the kernel. but even linux doesn't solve this problem. my 256mb linux machine with only me on it, locks solid due to oom conditions more often than the entire coraid plan 9 system with 20 users. - erik
Re: [9fans] 118 acme fault 0 no segment -- seeing a lot of simliar things this morning.
Is this another out of memory? This happened on a mk clean on kernel source It would not surprise me if the new pager (post-0.12) caused the problem, but in order for that to happen the kernel would have had to print uh oh. someone woke the pager first. Did that happen? I've done a lot without running out of memory (including building gs) so it wouldn't be my first guess, unless that print happened, preferably very close to when acme died. Russ
[9fans] kind of interesting
our power grid in the US is, well, interesting: http://www.ncsa.uiuc.edu/People/hkhurana/IFIP_CIP_08.pdf yowie. ron
Re: [9fans] 118 acme fault 0 no segment -- seeing a lot of simliar things this morning.
On Wed, Jul 2, 2008 at 6:16 AM, Russ Cox [EMAIL PROTECTED] wrote: Is this another out of memory? This happened on a mk clean on kernel source It would not surprise me if the new pager (post-0.12) caused the problem, but in order for that to happen the kernel would have had to print uh oh. someone woke the pager That I did not see. Just the no segment error. Here's a bigger question, now that I've read the paper and briefly scanned the code. Do you have some thoughts on the long term ability of vx32 to get close to unity performance on a system (like Plan 9) with a high rate of context switches between file server processes (you allude ot this cost in the paper). It's an ideal terminal right now. I don't see a need to use drawterm any more. But running fossil and venti, it's got a ways to go in terms of performance (i.e. mk clean in /sys/src/9/pc takes ~60 seconds). At this point, the fastest virtualization system for kernel mk on my x60 is still xen, at 12 seconds. I had expected lguest to beat that, but it never has. There are claims that kvm is running at close to unity, but that's probably for linux -- I have not tested kvm lately with plan 9. At the same time, in terms of effort, vx32 is far easier to run than the alternatives, and hence is superior in the long term as a way to get plan 9 into people's hands. Also, opteron. lguest on opteron should be ready soonish. But vx32 is still a highly desirable alternative. Do you have thoughts on how to sandbox on opteron, where you don't have the segment registers? Could you use mctl to sandbox and then filter mmap system calls from the sandboxed code to make sure the sandbox can not be escaped? enough rambling. I'm in a west coast brain on the east coast, still not awake at this point. Thanks ron
Re: [9fans] 118 acme fault 0 no segment -- seeing a lot of simliar
Here's a bigger question, now that I've read the paper and briefly scanned the code. Do you have some thoughts on the long term ability of vx32 to get close to unity performance on a system (like Plan 9) with a high rate of context switches between file server processes (you allude ot this cost in the paper). It's an ideal terminal right now. I don't see a need to use drawterm any more. But running fossil and venti, it's got a ways to go in terms of performance (i.e. mk clean in /sys/src/9/pc takes ~60 seconds). import(1)'ed files, host files and ramfs files are similarly slow. this is no benchmark, and it's a bit questionable because it's right on the limit of time's measurement, but it does reflect a lag i see that i don't see in drawterm: drawterm (the file is 4368 bytes), /dev/null time cat usps.jpg 0.00u 0.00s 0.00rcat usps.jpg 9vx /dev/null time cat usps.jpg 0.00u 0.00s 0.01r cat usps.jpg - erik
Re: [9fans] 118 acme fault 0 no segment -- seeing a lot of simliar
On Wed, Jul 2, 2008 at 6:40 AM, erik quanstrom [EMAIL PROTECTED] wrote: Here's a bigger question, now that I've read the paper and briefly scanned the code. Do you have some thoughts on the long term ability of vx32 to get close to unity performance on a system (like Plan 9) with a high rate of context switches between file server processes (you allude ot this cost in the paper). It's an ideal terminal right now. I don't see a need to use drawterm any more. But running fossil and venti, it's got a ways to go in terms of performance (i.e. mk clean in /sys/src/9/pc takes ~60 seconds). import(1)'ed files, host files and ramfs files are similarly slow. I don't want to turn this into a let's pile onto vx discussion, just more a discussion of how far we can go with the approach performance-wise. Some of the issues are well brought out in the paper, I'm just rolling the questions around in my sleep-deprived mental state. I'm currently just trying to figure out how to (re)package THX to make it easier for people to use, and which virtualization system to use ... ron
Re: [9fans] 118 acme fault 0 no segment -- seeing a lot of simliar things this morning.
It would not surprise me if the new pager (post-0.12) caused the problem, but in order for that to happen the kernel would have had to print uh oh. someone woke the pager That I did not see. Just the no segment error. You can run acid inside 9vx to get a stack trace of the broken processes. Maybe a pattern will emerge. Russ
[9fans] vx32 and 9vx performance, and on x86-64
There's not likely anything in the guts of vx32 that hasn't been done before. What's new is the fact that we managed to package it up in a way that runs on a variety of out-of-the-box OS'es with neither kernel modifications nor special privileges on any x86. That portability is key to being able to deploy interesting apps, like 9vx. Here's a bigger question, now that I've read the paper and briefly scanned the code. Do you have some thoughts on the long term ability of vx32 to get close to unity performance on a system (like Plan 9) with a high rate of context switches between file server processes (you allude ot this cost in the paper). It's an ideal terminal right now. I don't see a need to use drawterm any more. But running fossil and venti, it's got a ways to go in terms of performance (i.e. mk clean in /sys/src/9/pc takes ~60 seconds). I have spent approximately no time at all measuring 9vx performance other than the numbers in the paper, and even those were just what it was the first time I measured, not something I tuned for. I've been much more focused on correctness and functionality than speed. That should be encouraging, because there's probably a lot of room for improvement. Creating new processes and context switching is definitely slow. One of the slowest parts of the kernel build for me is the line rc ../port/mksystab ../port/systab.h which invokes a sam script that does ,x/SYS[A-Z0-9_]+,/ | tr A-Z a-z which forks and execs tr many times. There are three potential sources of slowdown that I can think of right now: * context switches, which involve a lot of mmap/munmap and trigger potentially many page faults * floating point: apps that use floating point are probably flushing the vx32 translation cache more than they could be. * the kprocdev framework. all i/o into devip, devfs, and devdraw is marshalled and handed off to a kproc running in a different pthread, so that blocking i/o won't block the cpu0 pthread, which is the only one that can run vx32. this means that all i/o gets copied one extra time inside the kernel. All of these could be improved, but you'd have to profile 9vx to figure out where the time is going first. You can reduce the effect of context switches by maintaining more than one user address space and by keeping track of which processes have address spaces that differ only in their stack segment. You can rework the way vx32 signals no floating point exceptions so that they wouldn't require flushing the translation cache. If one is doing i/o into a kernel buffer, like in demand paging, that doesn't need to be copied during the kprocdev switch, but it is. If the i/o doesn't span a page boundary and an appropriate fault-free physical mapping is known, kprocdev could use the kernel's physical mapping of that page instead of doing a copy. But again, you'd have to profile to figure out which of these is worth doing, if any. I don't have any sense of where the time is going. User-level profilers are going to be difficult to use, because 9vx wants to handle SIGVTALRM itself. You should be able to do pretty well with oprofile on Linux, or maybe dtrace on OS X. That would also have the benefit of telling you how much kernel effort 9vx is inducing. I hope that people will do this. I have very little time to put into this for the rest of the summer, but I'm always happy to explain things and process patches. At this point, the fastest virtualization system for kernel mk on my x60 is still xen, at 12 seconds. I had expected lguest to beat that, but it never has. There are claims that kvm is running at close to unity, but that's probably for linux -- I have not tested kvm lately with plan 9. Notice that vx32 itself is not on my list above. I think that there are plenty of things 9vx is doing inefficiently that dwarf the potential 1.8x performance hit in raw x86 execution speed. Also, inner loops tend to run close to 1.0 already. Once everyone's x86 processors have hardware support for virtualization and the operating systems allow arbitrary user code to get at it, maybe it would make sense to let vx32 take advantage of that instead, but right now it's not a priority for me. Also, opteron. lguest on opteron should be ready soonish. But vx32 is still a highly desirable alternative. Do you have thoughts on how to sandbox on opteron, where you don't have the segment registers? Could you use mctl to sandbox and then filter mmap system calls from the sandboxed code to make sure the sandbox can not be escaped? Vx32 already runs on x86-64 hosts, but it can only run x86-32 code. I don't see any reasonable way around that limitation right now, but it also doesn't bother me. Maybe in a few years kvm would be an answer. Right now, you can build 9vx with -m32 and get a binary that will work on x86-64, assuming you already have a 32-bit
Re: [9fans] sad commentary
Mozilla didn't create the web. The web created Mozilla. And the Internet created the web? And the PC gave rise to Lotus 1-2-3? Not necessarily. Nothing gave the Internet (here in South Africa) as much a boost as Win'95. The Web wouldn't have been the same success without Netscape. So there you are, which is the cart and which the horse? ++L
[9fans] naive 9vx/fossil question
Hello, I have a plan9/linux dual boot on my machine. Is there any way I can access (i.e: read and/or write) the fossil partition of my plan9 install from 9vx on linux? Actually, is there any way at all I can access that partition from linux? I'm just looking for an easy way to transfer some of the conf files I have on the native plan9 to the 9vx on linux. Of course I can boot plan9 and mount one of my linux ext partitions and use it as a transfer partition but that's not very convenient. With 9vx I can now easily try some plan9-ish stuff without losing the ability to ... listen to music on my computer. ☺ Yes, as silly as it sounds, it's actually a big win for me and I'm really glad 9vx exists just for that. So, thanks a lot Russ. Cheers, Mathieu.
Re: [9fans] naive 9vx/fossil question
have a plan9/linux dual boot on my machine. Is there any way I can access (i.e: read and/or write) the fossil partition of my plan9 install from 9vx on linux? Actually, is there any way at all I can access that partition from linux? You should be able to start fossil from inside 9vx, though you will have to copy in some disk-related binaries from a Plan 9 install CD, since I threw out a lot of stuff to make the 9vx tree small (see next mail). Then you should be able to do echo loop rw '#Z/dev/sda' /dev/sdctl disk/fdisk -p /dev/sd00/data /dev/sd00/ctl disk/prep -p /dev/sd00/plan9 /dev/sd00/ctl ls -l /dev/sd00/ctl You should see your fossil partition there. Then you can start fossil manually: fossil/fossil -f /dev/sd00/fossil -c 'srv -A fossil' -c 'srv -p fscons' mount /srv/fossil /n/fossil I haven't tried this, but it, or something like it, should work. Also you might need to replace /dev/sda with whatever Linux calls the appropriate hard disk. One could also build a 9vx binary that included the things a typical pcf kernel does and set up #S with the local disks automatically, so that you could run 9vx -b and tell it you wanted to boot from local!#S/sd00/fossil. There are lots of possibilities, and I hope some people will explore in those dirctions and tell us what they find! Russ
[9fans] Documentation on special files
In an inappropriate thread I appended a question about where to read about what special files are and how they work. I'm still wondering about this. I have questions like: - How are they created? - Can I get a list of all of them? - Do they behave differently than normal files? Are they described in one of the papers, or a man page? -- Tom Lieber http://AllTom.com/
Re: [9fans] sad commentary
andrey mirtchovski wrote: Mozilla didn't create the web. The web created Mozilla. just change Mozilla to Mosaic and see how P→Q suddenly becomes Q→P Why not redirect all this energy to answering the question, What comes after the Web? Wes Kussmaul
[9fans] acme scrollbar
Hi, The scrollbar handle will always change it's length when moving through the files. Why isn't the length based on the total lines of the file? -- hiro
Re: [9fans] acme scrollbar
Hi, The scrollbar handle will always change it's length when moving through the files. Why isn't the length based on the total lines of the file? because that would require reading the whole file. - erik
Re: [9fans] p9p vac merge problem
I recently updated my p9p from the CVS respository, and vac fails when I try to use the -m option for merging. I am not sure whether the cause of the problem is in venti or in vac. I did not test that well enough. It should be fixed now. Russ
Re: [9fans] pull in 9vx
On 7/2/08, Russ Cox [EMAIL PROTECTED] wrote: If you give 9vx a full Plan 9 distribution, you can use pull to update it just like any other distribution. Early copies of 9vx had a /dist/replica/client/plan9.db but it didn't match all the files I'd deleted to cut the size of the archive down. In 0.12 I deleted the plan9.db too, so that pull wouldn't try to run. If you want to run pull, you should start with a full tree. I have posted one at http://pdos.csail.mit.edu/~rsc/plan9.tar.bz2 You should be able to run pull successfully if you use that tree as your root. You can also start with a stock Plan 9 CD, if you know how to extract it into your local file system, but you will need to populate /dist/replica/client appropriately and also copy /dist/replica/network from a 9vx tree, since I haven't gotten those changes back into the distribution yet. Russ I got crazy permissions here?! $ tar jxf plan9.tar.bz2 tar: plan9/mnt/exportfs/16: Cannot mkdir: Permission denied tar: plan9/mnt/exportfs/1: Cannot mkdir: Permission denied tar: plan9/mnt/exportfs/10: Cannot mkdir: Permission denied ... tar: plan9/mnt/exportfs/9: Cannot mkdir: Permission denied tar: plan9/mnt/cons/cons: Cannot mkdir: Permission denied tar: plan9/mnt/cons/consctl: Cannot mkdir: Permission denied tar: Ignoring unknown extended header keyword `SCHILY.dev' tar: Ignoring unknown extended header keyword `SCHILY.ino' tar: Ignoring unknown extended header keyword `SCHILY.nlink' tar: Ignoring unknown extended header keyword `SCHILY.dev' ... tar: Ignoring unknown extended header keyword `SCHILY.nlink' tar: Error exit delayed from previous errors
[9fans] sftpfs
Hello, I wrote a file server for the SSH File Transfer Protocol (SFTP). You can find it here: http://www.tip9ug.jp/who/fhs/sftpfs.tgz It implements version 3 of the protocol because that's the version most widely use. At least OpenSSH uses version 3. Also, it requires that you have the OpenSSH port install (see README). Anyway, enjoy! fhs PS. This is my first 9p fs, so I'm not responsible for data loss ☺
Re: [9fans] pull in 9vx
Yeah, so will there be no fix?
Re: [9fans] sftpfs
Cool, good work! Please could you put it in sources/contrib rather than in an external host? Thanks again uriel On Wed, Jul 2, 2008 at 11:10 PM, Fazlul Shahriar [EMAIL PROTECTED] wrote: Hello, I wrote a file server for the SSH File Transfer Protocol (SFTP). You can find it here: http://www.tip9ug.jp/who/fhs/sftpfs.tgz It implements version 3 of the protocol because that's the version most widely use. At least OpenSSH uses version 3. Also, it requires that you have the OpenSSH port install (see README). Anyway, enjoy! fhs PS. This is my first 9p fs, so I'm not responsible for data loss ☺
Re: [9fans] sad commentary
Why not redirect all this energy to answering the question, What comes after the Web? Wes Kussmaul intravenous television. - erik maybe that's why it is called you*tube* :) corporate users probably use computers in the performance of their jobs, but the fact is that the majority of the pc's -- and indeed all game machines, music devices, etc. -- are used for entertainment.
Re: [9fans] sftpfs
Please could you put it in sources/contrib rather than in an external host? I will once I get my contrib directory. fhs
Re: [9fans] kind of interesting
On 7/2/2008 09:34, ron minnich wrote: our power grid in the US is, well, interesting: http://www.ncsa.uiuc.edu/People/hkhurana/IFIP_CIP_08.pdf Additional interest might be found in CIP-001-1 thru CIP-009-1 found at http://www.nerc.com/~filez/standards/Reliability_Standards_Regulatory_Approved.html It would be great if Plan 9 was running on some of these embedded devices or in the control room in a monitoring and control role but it seems like VxWorks/Windows/Linux is too popular. I will tell you this: There is money to be made in this SCADA sector and since it's all still semi-proprietary, people are used to forklift upgrades and don't care as much about preserving the platform. Utility related GIS systems are another fertile ground. I wince when I see the invoices. ~JasonG --
Re: [9fans] acme scrollbar
That makes perfect sense, thanks. I love the way how the text at the clicked point will just move to the top. Perhaps I am being stupid, but why doesn't left-clicking cause that point to move down to the bottom? I never know where in the text I will end up when I'm scrolling upwards... -- hiro
Re: [9fans] acme scrollbar
The left click is basically doing the opposite of the right click - it moves the top line to the position of the click. That way a left click after a right click restores the previous view of the file. (There may be some small distortion due to lines longer than the width of the window but that doesn't really matter much.) * hiro ([EMAIL PROTECTED]) wrote: That makes perfect sense, thanks. I love the way how the text at the clicked point will just move to the top. Perhaps I am being stupid, but why doesn't left-clicking cause that point to move down to the bottom? I never know where in the text I will end up when I'm scrolling upwards... -- hiro
Re: [9fans] acme scrollbar
On 7/3/08, Martin Neubauer [EMAIL PROTECTED] wrote: The left click is basically doing the opposite of the right click - it moves the top line to the position of the click. That way a left click after a right click restores the previous view of the file. (There may be some small distortion due to lines longer than the width of the window but that doesn't really matter much.) Oh, i ruled this possibility out, because I didn't see any opposite behaviour. The long lines *do* matter much. This feature is useless when it's unreliable. What do you think about my idea of moving the line to the bottom instead?
Re: [9fans] naive 9vx/fossil question
On Wed, Jul 02, 2008 at 02:03:40PM -0400, Russ Cox wrote: have a plan9/linux dual boot on my machine. Is there any way I can access (i.e: read and/or write) the fossil partition of my plan9 install from 9vx on linux? Actually, is there any way at all I can access that partition from linux? You should be able to start fossil from inside 9vx, though you will have to copy in some disk-related binaries from a Plan 9 install CD, since I threw out a lot of stuff to make the 9vx tree small (see next mail). Then you should be able to do echo loop rw '#Z/dev/sda' /dev/sdctl disk/fdisk -p /dev/sd00/data /dev/sd00/ctl disk/prep -p /dev/sd00/plan9 /dev/sd00/ctl ls -l /dev/sd00/ctl All of those worked fine as far as I can tell: term% ls -l /dev/sd00 --rw-r- S 0 glenda glenda 104857600 Jul 1 11:42 /dev/sd00/9fat --rw-r- S 0 glenda glenda 0 Jul 1 11:42 /dev/sd00/ctl --rw-r- S 0 glenda glenda 69379563520 Jul 1 11:42 /dev/sd00/fossil ... You should see your fossil partition there. Then you can start fossil manually: fossil/fossil -f /dev/sd00/fossil -c 'srv -A fossil' -c 'srv -p fscons' but that one failed: term% fossil/fossil -f /dev/sd00/fossil -c 'srv -A fossil' -c 'srv -p fscons' fossil/fossil: bad config magic in /dev/sd00/fossil then I wanted to check for something suspicious in my config: term% fossil/conf /dev/sd00/fossil config has bad header Is that bad? Gonna reboot to the native plan9 in the meanwhile to check if everything's ok... Mathieu.
Re: [9fans] acme scrollbar
What do you think about my idea of moving the line to the bottom instead? bad idea. to be honest i don't think the precise semantics of the scroll distance are very important, but it is important that left and right buttons are near inverses of each other, which means that when scrolling down, you can easily get back to the last view you saw without moving the mouse at all. the only change i think i'd make is that perhaps a right click should move the text just *below* the mouse position to the top. that way there wouldn't be a line's worth of zero-movement vertical space at the top of the window - which is particularly noticeable when the window is only a couple of lines long - in which case half the scrollbar doesn't react at all to left or right buttons currently. i'd implement this, but UI changes are controversial.
Re: [9fans] acme scrollbar
I dislike this idea. I think for most people, most of the time, the lines acme's working with will fit well within the width of a window. Yeah, I bet most of us have run into longer lines at times, but the interface is optimized for the common case. I wouldn't like to see that go. Having the undo (paralleling the undo of a 1-2, 1-3 chord) is very nice. The feature is certainly *not* useless for not being 100% reliable; what's it' off by, a line? Even that's a good enough job for your eye to find the line quick enough. Anthony ---BeginMessage--- On 7/3/08, Martin Neubauer [EMAIL PROTECTED] wrote: The left click is basically doing the opposite of the right click - it moves the top line to the position of the click. That way a left click after a right click restores the previous view of the file. (There may be some small distortion due to lines longer than the width of the window but that doesn't really matter much.) Oh, i ruled this possibility out, because I didn't see any opposite behaviour. The long lines *do* matter much. This feature is useless when it's unreliable. What do you think about my idea of moving the line to the bottom instead?---End Message---
Re: [9fans] naive 9vx/fossil question
On Thu, Jul 03, 2008 at 12:35:19AM +0200, [EMAIL PROTECTED] wrote: On Wed, Jul 02, 2008 at 02:03:40PM -0400, Russ Cox wrote: have a plan9/linux dual boot on my machine. Is there any way I can access (i.e: read and/or write) the fossil partition of my plan9 install from 9vx on linux? Actually, is there any way at all I can access that partition from linux? You should be able to start fossil from inside 9vx, though you will have to copy in some disk-related binaries from a Plan 9 install CD, since I threw out a lot of stuff to make the 9vx tree small (see next mail). Then you should be able to do echo loop rw '#Z/dev/sda' /dev/sdctl disk/fdisk -p /dev/sd00/data /dev/sd00/ctl disk/prep -p /dev/sd00/plan9 /dev/sd00/ctl ls -l /dev/sd00/ctl All of those worked fine as far as I can tell: term% ls -l /dev/sd00 --rw-r- S 0 glenda glenda 104857600 Jul 1 11:42 /dev/sd00/9fat --rw-r- S 0 glenda glenda 0 Jul 1 11:42 /dev/sd00/ctl --rw-r- S 0 glenda glenda 69379563520 Jul 1 11:42 /dev/sd00/fossil ... You should see your fossil partition there. Then you can start fossil manually: fossil/fossil -f /dev/sd00/fossil -c 'srv -A fossil' -c 'srv -p fscons' but that one failed: term% fossil/fossil -f /dev/sd00/fossil -c 'srv -A fossil' -c 'srv -p fscons' fossil/fossil: bad config magic in /dev/sd00/fossil then I wanted to check for something suspicious in my config: term% fossil/conf /dev/sd00/fossil config has bad header Is that bad? Gonna reboot to the native plan9 in the meanwhile to check if everything's ok... Native plan9 still booting fine, and here's the configuration for /dev/sdE0/fossil if it's of any relevance: fsys main config /dev/sdE0/fossil fsys main open -V -c 3000 Also, so far only /dev/sda was rw for disk group so I've set /dev/sda1 (which is the whole plan9 partition) to rw as well for disk group, to no avail. Mathieu.
Re: [9fans] naive 9vx/fossil question
Native plan9 still booting fine, and here's the configuration for /dev/sdE0/fossil if it's of any relevance: fsys main config /dev/sdE0/fossil fsys main open -V -c 3000 Also, so far only /dev/sda was rw for disk group so I've set /dev/sda1 (which is the whole plan9 partition) to rw as well for disk group, to no avail. almost sounds like an offset problem. do the partition definitions (cat /dev/sd??/ctl) differ between plan 9 native and 9vx? - erik
Re: [9fans] acme scrollbar
On 7/3/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I dislike this idea. I think for most people, most of the time, the lines acme's working with will fit well within the width of a window. Yeah, I bet most of us have run into longer lines at times, but the interface is optimized for the common case. I wouldn't like to see that go. Having the undo (paralleling the undo of a 1-2, 1-3 chord) is very nice. The feature is certainly *not* useless for not being 100% reliable; what's it' off by, a line? Even that's a good enough job for your eye to find the line quick enough. Anthony Then probably my eyes are just too slow:( It really doesn't work with me. But probably I'm getting old?!
Re: [9fans] acme scrollbar
bad idea. to be honest i don't think the precise semantics of the scroll distance are very important, but it is important that left and right buttons are near inverses of each other, which means that when scrolling down, you can easily get back to the last view you saw without moving the mouse at all. Ok, a matter of taste. I always had the feeling that knowing exactly how far the window will move even before clicking is a really awesome feature.
Re: [9fans] kind of interesting
Some time ago I was a pen-tester for a govt contractor. After a few months into my then new career I found myself constantly terrified of the state of affairs of our infrastructure. That was 13 years ago, I honestly hope that things have improved. I tell myself that they have just to not hole myself up in a bunker with an AR15, iodine tablets, and Hunter S. Thompson's (ex) personal stash of dinty moore beef stew. I read the abstract for this paper in the very recent past and I was not at all surprised, it seems to be indicative of everything that is wrong with the information systems that run our critical infrastructure. It terrifies me that what protects us is not good security, but the lack of skill, imagination, and impetus of our adversaries. I have been doing some single sign on related work at a big financial institution in the middle east, as a result I have been finding all kinds of really silly bugs in pretty important software (again, not naming names), and I am not that smart of a guy. There's simply no way to get away from the feeling that despite all of the hard work applied to security, the core software systems that actually handle critical data are still either totally insecure or far too easy to misconfigure in an insecure manner. Marcus Ranum was right, there is simply no patch for stupidity. jcw On Wed, Jul 2, 2008 at 6:49 PM, Jason Gurtz [EMAIL PROTECTED] wrote: On 7/2/2008 09:34, ron minnich wrote: our power grid in the US is, well, interesting: http://www.ncsa.uiuc.edu/People/hkhurana/IFIP_CIP_08.pdf Additional interest might be found in CIP-001-1 thru CIP-009-1 found at http://www.nerc.com/~filez/standards/Reliability_Standards_Regulatory_Approved.html It would be great if Plan 9 was running on some of these embedded devices or in the control room in a monitoring and control role but it seems like VxWorks/Windows/Linux is too popular. I will tell you this: There is money to be made in this SCADA sector and since it's all still semi-proprietary, people are used to forklift upgrades and don't care as much about preserving the platform. Utility related GIS systems are another fertile ground. I wince when I see the invoices. ~JasonG --
Re: [9fans] sad commentary
erik quanstrom wrote: snip these are tetonic forces. there's nothing directly As a geologist, I can't let this one slip (pun intended.) It's tectonic.
Re: [9fans] sad commentary
andrey mirtchovski wrote: Mozilla didn't create the web. The web created Mozilla. just change Mozilla to Mosaic and see how P→Q suddenly becomes Q→P Good point
Re: [9fans] pull in 9vx
Try extracting with star (Schilling Tar) On 7/2/08, hiro [EMAIL PROTECTED] wrote: Yeah, so will there be no fix?
[9fans] 9vx 0.12 OSX covers dock when maximized
Greetings, In OS-X 9vx covers the dock when maximized. The fix is simple; don't create a special window group for the application: diff -r ca5b26cbe43a src/9vx/osx/screen.c --- a/src/9vx/osx/screen.c Tue Jul 01 17:27:41 2008 -0400 +++ b/src/9vx/osx/screen.c Thu Jul 03 09:59:35 2008 +0900 @@ -126,8 +126,6 @@ or.bottom = Dy(osx.fullscreenr) - 200; or.right = Dx(osx.fullscreenr); CreateNewWindow(kDocumentWindowClass, WindowAttrs, or, osx.window); - CreateWindowGroup(0, osx.wingroup); - SetWindowGroup(osx.window, osx.wingroup); SetWindowTitleWithCFString(osx.window, CFSTR(Plan 9 VX)); seticon(); --underspecified
Re: [9fans] pull in 9vx
Yeah, i know i can extract it if I try hard enaugh. Others won't even try. I hope this gets fixed.
Re: [9fans] pull in 9vx
Yeah, i know i can extract it if I try hard enaugh. Others won't even try. I hope this gets fixed. This just isn't high priority for me. Once 9vx is ready for prime time and there's a real distribution to make, I'll worry about it then. Also, you're really not trying very hard. If the GNU tar is broken (and it appears to be), you can always use the bsd tar (apt-get install bsdtar) or the Plan 9 tar (9 tar). Russ
Re: [9fans] Bits of Plan 9 I wish were more popular...
On Wed, Jul 2, 2008 at 7:13 PM, Steve Simon [EMAIL PROTECTED] wrote: So you have the source for the quadrature encoder, and a DAC cannot be thar complex can it? why not email Comedi and ask them for card programming info. Comedi is an Open Sores project to unify the worlds data acquisition devices under one driver model. It's about as good a model as fits the Linux Way™ of these things, and there's enough sample code included to make it feasible to bring up a new card fairly quickly. Rather have Comedi drivers than some random vendor's conceptions of how to program the device, but it's nothing like a simple write(2) to /dev/analogout0/channel1. The only issue is that I can't justify the time needed to write Plan 9 drivers when a usable system already exists. Still you could use 9vx to run plan9 on top of this system, that way you could maybe migrate the system gradually. Unless vx32 can run real-time tasks (pretty sure it cannot) that's not much use. Almost every bit of my code (all except a very thin command interface) is living in a loadable kernel module Don't you want Kalman filters in *your* OS kernel? Russ has a version of libthread for windows on his web page. Do you mean libtask? That could be helpful too, but the system uses interrupts so cannot entirely be run as cooperative multithreading. The discipline of thinking in terms of channels. even if the implementation has gone a-gley, is proving useful too. --Joel
[9fans] p9p vac
the vac -m bug is fixed. (it was fixed earlier tonight, i just forgot to push the fix to cvs.) if you use vac -m to manage a dump-like tree of backups, you will likely be interested in the new -a flag, which automates the process. also, -e takes glob patterns now, and -x will read patterns from a file. these changes are not yet in the plan 9 vac. thanks to michael kaminsky for suggesting them. russ
