Re: [9fans] Re: venti/mirrorarenas usage
> Thank you for your suggestions. Reviewed the man pages again. > Let's see if this is an improvement. Kept the writing concise. > Mistakes are my own. Sharing here for transparency. I believe that part of the "social contract" of this mailing list is that people who are submitting code have run the code first. Have you run your most-recent submission? If so, on which version of which flavor of Plan 9? On which hardware? Dave Eckhardt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tca0eb0fbb2404e31-M67e2d63c18619d74d9ff2426 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: venti/mirrorarenas usage
> Peer review involves presenting a claim, research, or work to others > who are experts in the same field. These peers critically evaluate > the work, test its assertions, and provide feedback. The expected input domain of peer review is honest scholarly work by a peer, i.e., an expert in the field. Submitting the output of a stochastic parrot to peer review would be an abuse of the process, because a random-number generator is not a peer. Dave Eckhardt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tca0eb0fbb2404e31-M55117592d949470fc5cfdb65 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] mk results in rc: suicide:
> I did run MemTest86, which passed; no errors. Not to be a pain, but did you run it for at least 12 hours? Sadly, it can take that long or longer to uncover a marginal module. A really-horribly-bad module will fail in the first run, but you may not be that "lucky". Dave Eckhardt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T68f44cf88ca61ff3-M9b47d06348b1f258e2d48066 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] mk results in rc: suicide:
If it were my machine I would probably run a RAM tester overnight. Dave Eckhardt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T68f44cf88ca61ff3-M02fac44b503b2dfc5c1be904 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Throwing in the Towel
> For the napkin calculation: On disk, the IEntry is 38Bytes. Alas, > writes occur always in (the ssd internal) blocksize. So, essentially > (assuming 4096 byte blocksize, which is quite optimistic), we have > a write efficiency of less than 1 percent. While I see how such a model can predict disaster, I don't think that model matches how FTLs work, because it can't. Many file systems (FAT, ext2/3/4) write the same logical block over and over and over and over and over. I think the default interval for ext4 to synch the superblock and the journal is five seconds, which if true is more than 15,000 times every *day* for a busy file system (and I think lots of Linux systems are busy in that sense). > A good firmware in the ssd could avoid needing a new block for the > write, if all bits are changed in teh same direction by the new > data. Again, I believe this model predicts that no regular Linux file system can be used on any SSD, thus I believe this model is not accurate. To quote Wikipedia: https://en.wikipedia.org/wiki/Flash_memory_controller > The mapping units of an FTL can differ so that LBAs are mapped > block-, page- or even sub-page-based. Depending on the usage > pattern, a finer mapping granularity can significantly reduce > the flash wear out and maximize the endurance of a flash based > storage media. Also, I feel as if this point is several assumption layers deep. I think one user reported an unknown number of failures in two sets of SSDs of unknown brand and model. I don't think we know that it was venti SSDs that went bad as opposed to fossil SSDs, let alone knowing it was index SSDs for venti. > It seems, venti in its current form is a ssd killer, if they > are used for the isects. I don't think this claim is yet supported well. Dave Eckhardt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2ca67486c7a13a77-Mfafe3b0a74f75cd266eb0a73 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Throwing in the Towel
> Can it be the case that the venti index file exhibits a desastrous > write pattern for SSDs? Maybe... but it would need to be worse than the load provided by other file systems, including FAT and ext2/3/4. Some of those file systems rewrite some blocks like mad (e.g., superblock, journal blocks). Just because a flash translation layer might need to erase an entire megabyte, or multiple megabytes, does not mean that it needs to put the new value of a logical block in the same area of the flash that the old value of that logical block used to be in (they do the opposite). It would be interesting to get a dump of the SMART data for the drive(s) that went bad, and also drive(s) that didn't go bad. Dave Eckhardt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2ca67486c7a13a77-Mda9b0251a0482ce40f14c606 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> I confirmed the model was trained on 9front resources, including > git history. I looked quickly at the document but didn't see a statement that it was machine-generated text or what the inputs were. Though "LLM ethics" are far from settled, I think at this stage it would be good to state clearly and prominently, up front, that this is machine-generated text, and to somewhere include information about which LLM was used, trained on what, and with what sort of prompt. As a separate matter, though I am not presently a 9front user, as I quickly skimmed the document it didn't seem clearly accurate. Is accuracy a goal? If so, how will it be determined whether or not that goal has been achieved? Dave Eckhardt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Me5cc575537394d7a0803f2c0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] VCS on Plan9
> One thing i did was sometimes to create a skeletron directory > tree and bind *before* each single directory in /sys/src/9. > > when i needed to modify a file, you copy it in your "overlay" > tree. https://9p.io/wiki/plan9/divergefs/ Dave Eckhardt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M5cbb25fdbe82250774918e3c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] mounting a 9660 file system - writeable
9660srv's job is to serve the files stored on a CD-ROM. CD-ROMs are more or less read-only, so 9660srv serves the files as read-only as well. In most setups, the /tmp file system is "stored" in RAM. It's faster than sending the data to some storage device, and when you turn the machine off the files vanish, which matches the mental model people sometimes use when putting things in /tmp. If you want to write files that persist across reboots, you'll need to use some other kind of file system (and give it a storage partition). Assuming you're using 9front, you might start looking somewhere around here: https://fqa.9front.org/fqa7.html#7.1.2 You might give your VM two storage devices, one blank and one holding the ISO image; running the installer on the ISO image would guide you through installing a regular read/write file system on the other storage device. If you wanted to layer your changes on top of an underlying CD-ROM image, that could be done with an overlay file system. One of my students wrote one many years ago: http://9p.io/wiki/plan9/divergefs/ Later other students used it to build kernels without write access to /sys/src -- their overlay contained their source changes and also their object files. The overlay file system will still need somewhere to store files, though. Dave Eckhardt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T49170188f63f430d-M225108264fd4c3ddf4a231f0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] GSoC 2021 project ideas
> Anyone know if this project went anywhere? > > https://www.cs.cmu.edu/~412/lectures/L05_Purge_Proposal.pdf Sadly, not. One issue is that modern Android releases don't support 32-bit executables, and at the time that project was attempted Inferno was somewhat 32-bit (I haven't looked since). But I think I saw some recent-ish Inferno-on-Android activity here: https://github.com/bhgv/Inferno-OS-bhgv If wide availability, meaning being able to have a phone UI running on random cheap Android phones, is a goal, you'd presumably want to target one or more vendor releases of Android. But if a low-cruft solution were desired, it might be desirable to target AOSP or GrapheneOS. Both of those boot *dramatically* faster than vendor ROMs, and it's because there is just less code. Between the two of them, GrapheneOS might be better: it doesn't run on a lot of phones, but some of them are cheap enough, and switching from the vendor ROM to GrapheneOS is easy enough. Compared to AOSP, GrapheneOS has some genuine usability features, e.g., a usable backup/restore solution. Hopefully some of this is useful. Sorry I can't provide more! Dave Eckhardt -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T39aec8f3f9d8503d-Mb39cc944a90b85f939dd26dc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] subtracting pointers on amd64 6c
> for instance, although the range of subtraction is theoretically > -2^64+1 to 2^64-1, amd64 can only address 48 bits of memory > (currently) despite using 64 bits to represent addresses. as long > as virtual addresses in the system aren't exabytes apart, this > shouldn't result in undefined behavior in practice. Unfortunately AMD64 VM is a hack. The 2^48 addressable bytes aren't contiguous! 2^47 of them go up from 0 and the other 2^47 of them go down from (64-bit) -1. See: https://en.wikipedia.org/wiki/X86-64#Canonical_form_addresses Dave Eckhardt
Re: [9fans] bug or feature ? --- ip/ping -6
> I would display the IP address once only, rather on every line; as it > is a common factor. It's common only until it isn't. If an intermediate router doesn't like your packet it might choose to respond, in which case your intended target doesn't get to. At least that's why the Unix version of ping reports the identity of the machine who issued the ICMP response. Dave Eckhardt
Re: [9fans] Alternative Plan 9 Logo
Will t-shirts be available? Hopefully not just white? Dave Eckhardt
Re: [9fans] Vanilla Plan 9 or one of the flavors?
I mentioned this. I don't want to buy a new piece of hardware when I could fix the issue by using a different software stack, but if necessary, that's what I'll end up doing (buying the hardware). Very frequently the problem is nothing more than missing case arms in a couple of switch() statements. The most recent one I submitted was: http://plan9.bell-labs.com/sources/patch/applied/ether8169-macv34/ If you have a detailed PCI-device listing (obtainable via a BSD or Linux live CD), it is pretty easy to figure out which driver should be supporting your card and whether the reason it isn't is missing case arms. If you've been around the block a few times it takes an hour or two to diagnose, patch, test, and submit the patch to Bell Labs. However, if you're just getting started it can take you a week or two of fussing, which may compare unfavorably with picking up a known-good Ethernet card for $5 from eBay/NewEgg/etc. Having a working Ethernet makes it easier for you to get started, and once you're started you can go back and figure out what's wrong with the built-in Ethernet. Dave Eckhardt
[9fans] On a clear disk, you can seek forever
Do I have my stupid hat on today, or can somebody reproduce this? It seems as if the fossil partition on the official USB installer image is full of zeroes? Also the fscfg partition, though that bothers me a little less. term% hget http://plan9.bell-labs.com/plan9/download/usbdisk.bz2 usbdisk.bz2 ... term% ps | grep hget term% ls -s usbdisk.bz2 1777 usbdisk.bz2 term% bunzip2 usbdisk.bz2 usbdisk term% disk/partfs -d sdYY /tmp/usbdisk term% cd /dev/sdYY term% disk/fdisk -p data ctl term% disk/prep -p plan9 ctl term% lc 9fatctl datafossil fscfg nvram plan9 term% cmp fossil /dev/zero EOF on fossil after 1794302464 bytes term% cmp 9fat /dev/zero 9fat /dev/zero differ: char 1 term% cmp fscfg /dev/zero EOF on fscfg after 8192 bytes Dave Eckhardt
Re: [9fans] p9p factotum available for plan 9
The problem with strings is that they are human oriented and human dependent, on mood and/or trend. Numbers are agnostic. Isn't a solution a la IP network numbers possible? I mean, a user, whatever string is locally associated to it (and this may change), is uniquely identified by a number that could encode a domain (with some numbers being absolutely local) [...] I think the Inferno guys have relevant art. Principals are identified by public keys (which are indeed numbers). But I am not an expert on how this plays out in practice, and I also have a sense that the current Inferno implementation is an approximation of the design goals. Dave Eckhardt
Re: [9fans] permissions
Oh, is this a telnet capable mains switch? Is tehre a UK version, I have wanted such a thing for ages. Bay Technical Associates (baytech.net) has a huge variety of these, many take 220V, many are available on eBay, maybe the sets don't intersect but I think they do. You need to be a bit careful since a lot of what's on eBay is telnet-only (i.e., you probably don't want to deploy it on the Internet). Some of the older SSH-capable units have slow enough CPU's that you don't want to use an RSA key of more than 768 bits (and even that's noticeably slower than 512); if you use real SSL certs your CA may refuse to sign a key that small these days. Dave Eckhardt
Re: [9fans] pineview atom
Actually, even adding it in memory isn't that easy. In the old days, a simple Hamming code was good enough because each bit in a word lived on a different chip. Now memory chips are wider and so the code has to account for multi-bit errors (flipping of bits is not independent). Indeed... http://en.wikipedia.org/wiki/Chipkill Dave Eckhardt
[9fans] How 'bout a 9 USER site?
This is pretty darn useful: http://www.quanstro.net/newbie-guide.pdf and could be extended in some of the ways you mentioned (faces, how to find useful images such as bootable-USB, VMware, etc.). Also, for a while the Tokyo Inferno/Plan 9 User Group (tip9ug.jp) ran a service where pretty much anybody could get an account on a Plan 9 machine. They seem down now... if it's not temporary, something like that could be a real service. Dave Eckhardt
Re: [9fans] pineview atom
Back in the old days, a lot of VAX-11/750's running BSD Unix crashed because of parity errors in their TLB's. 750's running VMS didn't have this problem, because VMS would silently work around it; BSD grew that code--see, for example, 2...@astrovax.uucp. Then bits could flip all the time with nobody noticing! nobody noticed, or the os reloaded the tlb? This was back in the days when TLB's loaded themselves. I think the work-around code as to flush the entry. I mentioned the example because: * Bits were flipping pretty often. I think we got 10-ish events per day. * If there hadn't been parity protection, the result would have been occasional unrepeatable weird crashes and data corruption. That would have been really painful. This isn't the same as the general RAM case, because there aren't quiet backwaters of a TLB which can go bad with no effect. * Because VMS silently worked around the error and BSD didn't, for a while the issue was a perplexing Unix problem: BSD ran pretty well on older 750's and much less well on newer ones; VMS ran fine on both. In actuality the problem was quality control inside DEC, but the combination of parity and restarting the operation enabled successful computation on somewhat sketchy hardware. Dave Eckhardt
Re: [9fans] pineview atom
You'd need to look at fraction of total that is data vs. code, then at fraction of total code that is going to cause hurt if flipped. This stuff can have numbers attached. Here's an example from my world. 1 MB of code, 32 MB of kernel, and 2GB minus that of data. This is a lower end ratio as the nodes don't have much memory. If the data is flipped, you're not going to know of errors unless you are looking for numerical instability. Also subtract out all of the kernel code which is boot-only: it needs to be uncorrupted for just the twinkling of an eye. Almost all of every format string (used or not) can be corrupted without anything dramatic happening. While you're in the kernel, the exception-handling label stack could be totally trashed as long as nobody invokes error() during this system call. Or maybe a bit flip rewrites an instruction to use %ebx instead of %eax, but at a point when they both contain the same value. There's lots of stuff which doesn't have to be totally right to work, and even the stuff that must be 100% right may be fine if it's wrong at the the right time. Back in the old days, a lot of VAX-11/750's running BSD Unix crashed because of parity errors in their TLB's. 750's running VMS didn't have this problem, because VMS would silently work around it; BSD grew that code--see, for example, 2...@astrovax.uucp. Then bits could flip all the time with nobody noticing! Dave Eckhardt
Re: [9fans] pineview atom
i have been running a amd64 machine as a cpu server for 2 years. it uses standard ddr2 memory. i have not seen any unexplained crashes or reboots during this time. at work, i have been running 5 un-ecc'd machines for 3 years. also no unexplained crahses or reboots. how could this be if i would expect 240 + 1825 bit errors? There is no mechanism which directly translates bit flips to crashes! The bad case is actually a corruption which does *not* cause a crash, but is written to disk. How often do you check your venti's SHA-1 hashes? Also, according to the data cited, machines do differ. Dave Eckhardt
Re: [9fans] Plan 9 on L4
actually, code that uses gcc seems to require massive rewrite just to accommodate different versions of gcc. I think the most fun I had was when the meaning of some inline asm() changed. Not a massive rewrite, since it was only one line, but it was none the less painful. Dave Eckhardt
Re: [9fans] JVC Netbook works fine, except PCMCIA
pcmcia0=type=rtl8139 port=0x400 irq=10 Nope. pcmcia0 tells the kernel what kind of PCMCIA bridge you have; since you have CardBus (which is better), you shouldn't have one of those lines unless you need to disable the CardBus driver and use the old PCMCIA code instead. One reason to do that, by the way, is that the PCMCIA bridge driver accepts an IRQ override (for the bridge itself) and the CardBus driver doesn't. I have one Sony Vaio whose BIOS sets *all* IRQ's to 9, which results in sadness, so I use the PCMCIA driver instead of the CardBus driver. ether0=rtl8139 This is also wrong. You want ether0=type=rtl8319. Can you send us the output of aux/pcmcia? Also of cat /dev/ioalloc? Dave Eckhardt
Re: [9fans] Two suggestions for ape (was: egrep for Plan9)
Wasn't there an OS kit or something like that with drivers derived from Linux one's at some moment? University of Utah, Flux OSkit. Old OSkit is mostly BSD licensed (if you count the CMU Mach license as a BSD license), but at some point somebody sprayed the GPL over everything (somewhat reducing the utility of some CMU-derived code for a project here at CMU, but I digress). If you are looking for an approximation of the last non-GPL'd OSkit, I think this is probably it: http://os.inf.tu-dresden.de/fiasco/download/fiasco-1.1-oskit.tar.bz2 Dave Eckhardt
Re: [9fans] /sys/include/ip.h 5c(1)
i thought several universities did modify the microcode in various ways, to test some research ideas, or just to improve things. As I understand it, on the 750 floating-point errors were accidentally traps instead of faults, or the other way around. DEC said oops, well, we guess it's model-dependent whether floating-point errors are traps or faults. The BSD guys patched the microcode. For something nobody would want to do, there sure are a lot of hits for pcs750.bin. Dave Eckhardt
Re: [9fans] plan9 on vmware esx
1000/0030 LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller Run in fear. Despite having a number which is just a wee bit higher than the things supported by the existing Plan 9 NCR/LSI SCSI driver, this is an utterly different beast, based on LSI's Fusion architecture, which in theory simplifies things vastly for the host over the old sequencer/script architecture, but all of the simplification is balanced out by vast complexity additions in other areas (addressing devices in terms of target and LUN is obsolete, so there are two or three other ways that devices can identify themselves, and a host is supposed to set up a mapping from long identifiers to short ones for, and for some reason I didn't get on first reading the host is supposed to use the same mapping across reboots). Also, I think that in addition to talking to disks over this SCSI adaptor, you can also send network packets. Dave Eckhardt
Re: [9fans] new 9atom.iso
pbs32 (9null's pbs) now works with 9fat without caring about it. it loops reading a block and checking for the a.out(8) signature. if the 9pcload is on 9fat, not a problem anymore. Twt! 5-yard penalty for making something work better instead of complaining! Dave Eckhardt
Re: [9fans] vmware snarf problem
unfortunately the source for vmwarefs doesn't seem to be available, so i can't investigate further. http://9fans.net/archive/2008/12/180 Dave Eckhardt
Re: [9fans] GSoC 2009: Plan 9 is in!
Congratulations! I'm glad to have been so totally wrong about our prospects. Dave Eckhardt
Re: [9fans] Google Summer of code 2009
As to how many groups and students, they didn't say anything about that other than to show that each year the numbers had increased. Our prospects were evaluated with some care. In particular, Google has stated, publicly, in writing, that they expect to fund ~10% fewer students and thus fewer organizations this year. http://code.google.com/opensource/gsoc/2009/faqs.html 4. How many mentoring organizations does Google expect to take part in the program? We worked with 40 organizations in 2005, over 100 in 2006, over 130 in 2007 and 175 in 2008. We expect slightly fewer organizations to take part in 2009, as we've capped the number of student participants at 1,000. 5. How many students does Google expect to take part in the program? We funded approximately 400 student projects in 2005, 600 in 2006, 900 in 2007 and 1125 in 2008. We'll be funding approximately 1,000 student projects in 2009. Dave Eckhardt
Re: [9fans] Google Summer of code 2009
I heard that there will be a GSoC this year, are there any plans to get plan 9 as a mentoring organization? There has been some discussion about this among the people who put together last year's application. For whatever mixture of factors, we ended up below the line last year. This year more groups are expected to apply, and Google has indicated they plan to support fewer groups and fewer students this year as compared to last year. Each of those trends seems likely to push us further below the line if we submit a similar application again this year. For that reason, the thinking is that this summer we should pursue alternative courses of action. Examples might include organizing some bug-fixing weekends or install fests, improving performance and usability of Plan 9 in various VM's (since this is probably the safest way to ensure that a new user's install works the *first* time)... Next year maybe we'll be different, and maybe GSoC will be different. Dave Eckhardt
Re: [9fans] Some arithmetic [was: Re: Sources Gone?]
Assuming SHA-1 is indeed cryptographically secure (which is the assumption made by the venti paper) Well, I read it like it was just sufficiently secure against unintended collisions. It's not intended to encrypt, but to efficiently store data. While SHA-1 is indeed not intended to encrypt, it *is* intended to be a secure hash (hence the name). In order for it to do that job, it must be computationally difficult for somebody to find colliding material. If it's easy to guess venti scores for file-system roots, that suggests that SHA-1 systematically doesn't cover certain parts of the output space. If that is true, that would be a big help for people trying to find collisions (and, hence, forge signatures). It could be that way, but a lot of people are still acting in ways which will be painful if it is. Said another way: SHA-1 is designed to be a different kind of checksum than CRC-32. CRC's are designed to defend against accidental corruption, but SHA-1 really is designed to make deliberate collisions hard. Dave Eckhardt
Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released)
Secondly, Cinap and I agree that based on the Linux emulation it becomes useful to implement MMAP on Plan 9. If you do pay costs on that scale, it might be nice to get something better than just mmap() when you're done. http://9fans.net/archive/2008/07/729 http://9fans.net/archive/2008/07/535 http://9fans.net/archive/2008/07/773 Dave Eckhardt
Re: [9fans] pull doesn't work due to unavailable sources; travelmate 291LCi specials
There are two ac97 drivers written independently, I believe there are links on the wiki to them. The one written by CMU students has been tested on a bunch of Intel hardware and knows how to work around busted motherboards which don't clock samples at the right rate (apparently this was popular at some point). The other one has better code quality, and will try to run on more chips, but it's not clear how many of them it has been tested on. If somebody has time to do a merge, that would be great. I still have handy one of the machines with busted clocking. Dave Eckhardt
[9fans] acme dump/reload vs. Wiki
I'd like to start up an acme with a bunch of wiki windows open according to a saved configuration, but there appear to be structural obstacles. 1. Dump appears not to record wiki windows. 2. While Dump *will* record a window in which win Wiki has been invoked, something is odd about pathnames--Wiki will start up a window labelled /mnt/wiki/1, but no matter what pathname under /mnt/wiki (e.g, /mnt/wiki/2) I give to a B command, what I get is not a wiki window but instead a regular window displaying the contents of /mnt/wiki/2 (which is a directory). 3. If there were a way to pass a wiki virtual pathname to the Wiki command to get it to open up a window, Dump would record the existence of such windows... but Wiki takes only a wiki mountpoint and/or an author e-mail address as parameters, not a virtual pathname. Am I right in suspecting that I'd need to fix /acme/wiki/src/^(win.c main.c) to address #1 and #3 in a mutually supportive way to get this to work? Is there some other way I'm overlooking? Is this a bad thing to want? Dave Eckhardt
Re: [9fans] venti
A check could be put in by having venti put some sort of lock somewhere on the disk. But that would lead to problems if venti doesn't shut down properly: venti would be gone but the lock would still be there. Post an (ignored) mode 000 fd in /srv? Since nobody could open it, it would always have one reference, and would go away when the venti did? Dave Eckhardt
Re: [9fans] venti
Post an (ignored) mode 000 fd in /srv? Since nobody could open it, it would always have one reference, and would go away when the venti did? dns tries a similar trick. I think /srv/dns serves an actual file system, so there are potentially many references to it (not just one). it also assumes direct-attach storage. Not exactly, but you are right that ventis running on two kernels could mount the same storage. I seem to recall being surprised at some point to observe /dev/sdXX/data silently imposing a one-open-at-a-time policy (I think subsequent opens stalled). Maybe a script run at system boot time could turn on DMEXCL for appropriate things in /dev/sd*/*? Dave Eckhardt
[9fans] RFNOMNT and/or least privilege
RFNOMNT, like everything in Plan 9, was put in because someone needed to use it, not as a purely academic exercise in adding features. Here is something which either I've misunderstood or is harder than I'd like. I have a machine which runs two private (password-protected) web servers on different ports. It is not the case that everybody who can log in to the machine should be able to read the content offered by those two servers. The web server infrastructure seems pretty focused on running as user none, which makes sense as far as it goes, but I don't want none to be able to read the files served by the web servers because anybody who can log in to the machine can become none. What I've worked out so far is this. At boot time, the host owner (who is a member of a group which can access the bits) builds an approprate namespace for each of the web servers. In each case the hostowner starts up a wikifs which can read and modify the privileged information but which posts a world-mountable service descriptor in /srv. Once each web server is launched in a namespace which has mounted the descriptor, the descriptor is deleted from /srv. If all this happens before listen is run, I think the result is two environments which are both running as none but have access to the bits they need, without leaking that access to everybody else who runs as none. What does this have to do with RFNOMNT? For one thing, while I thought about using RFNOMNT to limit the ability of the a hijacked web server or its children to get at the rest of the system, lots of people demand the ability to rearrange their namespaces, e.g., wikipost bails out if it can't mount onto /mnt/wiki. But overall I wish I had more ability to set up least privilege execution domains, meaning process trees with exactly the privileges they need but no more. Or am I doing it all wrong? Dave Eckhardt
[9fans] (no subject)
Fair enough. But what's the adoption overall? Among organizations who want 10,000+ users sharing a single (apparent) file system? I know there are organizations which would dramatically benefit from that kind of infrastructure, who don't have it, because they are using NFS (e.g., a university CS department where the grad students use one NFS infrastructure and the undergrads use another, and there is no way to set up a group for all members of a class!). I think each of those organizations is an argument for AFS, not for NFS. More globally, if the high adoption rate of NFS is an argument in favor of its architecture, and the low adoption rate of AFS is an argument against its architecture, why are you reading a Plan 9 mailing list...? To some extent, the popularity of NFS (is there any NAS box that talks AFS?) and Linux is one big testament to the power of good enough or worse is better. Designing enterprise grade things is very hard work. Implementing them is even harder. The good news is that it pays well. The bad news is that you have to be really brave to withstand the fear of being obsolete by changing requirements. I don't get this. I don't follow the NFS protocol development carefully, but honestly it seems to me that (a) it's getting a lot bigger over time, and (b) this is substantially by adding features (leases, non-silly authentication, user-defined groups) which were in AFS in the 80's. That is, I think the requirements are *not* changing, but rather that NFS is slowly realizing that those things *are* requirements. Now there is a fine economic/practical argument for gradually evolving a system toward a desired set of goals, so that you spread upgrade, training, and incompatibility costs out over time, so that evolving NFS into AFS over 35 years makes more sense than forcing AFS painfully on people all at once. Personally I think it's been worthwhile to a lot of people at a lot of organizations to get 25 years of early access to certain features. None of this is to say that AFS doesn't have unnecessary cruft, or, again, that it isn't possible to meet the same goals with less complexity now that we know more. Dave Eckhardt
Re: [9fans] How to implement a moral equivalent of automounter
At some distant point in the past (last century, actually) I was drawn to AFS because of the features, but left in horror because of the complexity. The goal was adding an enterprise-scale distributed file system to an existing operating system (Unix), where enterprise-scale meant 5,000 users (the first prototype supported 400 users on 120 workstations in 1984; this evening CMU's AFS cell hosts 30,821 user volumes, roughly half a gigabyte each; there are cells with more users and cells with more bits. It may be the case that 25 years later NFSv4 solves all the same problems with greater elegance--which would be good, because civilization should advance, and it really is useful for a community of 30k people to seamlessly share files. I guess it doesn't really matter if your environment is being managed by a good IT -- you just reap the benefits. But as a tinkerer, I wouldn't call AFS malleable. A 747 isn't as malleable as an ultralight. If you can figure out how to carry several hundred people across an ocean in something as easy to build and maintain as an ultralight, people will most definitely take notice. And such a thing could be the case for distributed file systems. Dave Eckhardt P.S. Here's some rationale behind the horrific complexity: http://www.cs.cmu.edu/~satya/docdir/p35-satyanarayanan.pdf
Re: [9fans] How to implement a moral equivalent of automounter
P.S. I've seen this disbelief in the fact that automoter + NFS actually can be really convenient mostly come from Linux people. Perspective depends on experience. AFS has its warts, but, trust me, if you've used it for a while, you will not find yourself excitedly perusing the volume location database to see where your bits are coming from. In fact, you generally will not notice when your volume moves from one server to another, even if you are reading from and writing to it at the time. Dave Eckhardt
Re: [9fans] Do we have a catalog of 9P servers?
Every sensible NAT solution must be implemented with that in mind--not that existing ones have been. Even imagining persistent connections from an entire Class A network makes one shudder. Needless to say, the wreak of havoc occurs _long_ before over 16 million hosts need persistent connections. Especially since you get only 64k TCP connections between any pair of IP addresses, e.g., between a NAT box and www.cnn.com. Are there any NAT solutions which handle millions of hosts? Are we having a discussion about unicorns? Dave Eckhardt
Re: [9fans] Do we have a catalog of 9P servers?
I believe your are a little late with your remark. The issue has been resolved. Oops! Hopefully as list moderator you will accept my apologies for having drawn out a discussion beyond its useful time!! Dave Eckhardt
Re: [9fans] Are there any blind users of Plan 9?
The bad news is that the existing interface is very mouse-oriented and there is no text-to-speech support. The good news is that the system, and each part of it, is small, so if you don't like something it can be replaced. Unlike Windows or Unix, where you can't do much about the windowing system, in Plan 9 you really can replace it and it's not that much code. The bad news is that support for whizzy AJAX browsers, etc., is unlikely soon. Is there a university near you which has a CHI/HCI (Computer-Human/Human-Computer Interaction) degree? It might be possible to find a student or two looking for a way-out thesis project and help them design something interesting. Where are you located? Dave Eckhardt
Re: [9fans] starting 9vx in FreeBSD :Shared object libthr.so.3 not found
Looks like the binary is for FreeBSD ?7.0. And you can't build it for FreeBSD 6 because the architecture of the thread library is different. Time to upgrade anyway, at least for me. Dave Eckhardt
Re: [9fans] dns failure in smtp
I think mx record is required in official dns server, although I feel the condition is too strict. Keep in mind that a DNS *failure* is not the same thing as a particular DNS record not existing. If you ask whether there is an MX record for foo, and get a timeout, you can't assume there is not an MX record for foo and fall back on the A query. Misconfigured DNS servers with some frequency will return SERVFAIL (I am misconfigured or broken) to an MX query while happily answering A queries. The right thing is to request the administrator of that domain to return an MX record to the MX query or to return zero records. Dave Eckhardt
Re: [9fans] lisp
cmucl is directly executable but it has only enough intelligence to load a big lisp.core, which contains all the smarts. If these core files aren't generated all *that* often, one could write a tool which would turn a core file into a byte array, link a new lisp executable, and exec() that. I realize that's not an answer to the question as posed, but... Dave Eckhardt
Re: [9fans] WYSE Winterm 9150SE graphical problem
I tried dozens of modes, from 640x480 to 1280x1024, using 8-bit to 32-bit of colors, and no one seems to work. Can you say more about what you are doing to try a given configuration? At first glance it doesn't seem like there is a native Plan 9 driver for your graphics chip, so if the VESA driver doesn't work you might pursue getting a data sheet and seeing if it looks enough like some other chip. Dave Eckhardt
Re: [9fans] WYSE Winterm 9150SE graphical problem
Can you say more about what you are doing to try a given configuration? I tried xga, vesa, multisync and other modes. Can you say exactly what you mean by tried xga and tried vesa? Dave Eckhardt
Re: [9fans] 9vx
libvx32/freebsd.c:20:2: warning: #warning libvx32 and FreeBSD 5 and 6's libpthread are not compatible. I guess the priority of my upgrade laptop's FreeBSD thread has just increased. Dave Eckhardt
Re: [9fans] evoluent mouse review
have you considered translating the evoluent usb interface into one the kvm switch can understand with an atmel avr board? I'm impressed by your creativity. You are right that with sufficient thrust, wings are not necessary and even a brick can fly. :-) Even without solving the problem, it *would* be interesting to know exactly what is going wrong. First I should probably walk around trying other KVM switches. Dave Eckhardt
Re: [9fans] evoluent mouse review
I bought one of these (Evoluent VerticalMouse 3 Rev 2, aka VM3R2). It doesn't work with my KVM (IOGear GCS1734, neither top of the line nor junk), not with Linux or Plan 9: horizontal tracking is fine, but vertical tracking goes only up. It works ok plugged directly into a Linux box. After some mail back and forth with Evoluent, the bottom line is they don't care. They began with a defensible position (not all mice work with all KVM switches), but, when asked to name *one* switch the VM3R2 works with, they quit answering mail. Note that their web site warns against KVM switches when using the Windows driver (as if!), but does not make a general warning. It's an interesting device, but when using some (maybe all?) KVM switches you're better off with an $8 Logitech throwaway. Too bad. Dave Eckhardt
[9fans] It looks like our GSoC application was rejected
Since we didn't hear back, and our name is not on the list of accepted projects, it appears that Google rejected our application. Of course we'll try to figure out why and how we can do better next year. Dave Eckhardt
