[9fans] 9fans archive engine
Is the software which powers 9fans web archive publicly available? Which one? :-) I prefer the mailman archive available only to list members since it allows the messages to be sorted by subject/author/date/thread and of course, the source for mailman is available. I'm note sure why there are two archives, other than no one may have taught mailman how to generate an additional public version of the archive with added address obfuscation. In any case, the added obfuscation is currently undermined since the Usenet relay seems to be currently active outbound and there may be other public relays as well.
[9fans] GNU/Linux/Plan 9 disto
Not to rain on anyone's summer of code project but I think producing a Linux distro that runs on top of Plan 9 would be more beneficial to the Plan 9's future than a Plan 9 userspace on top of Glendix, though nowhere as interesting. I've no problem with a kernel that could run both Plan 9 and Linux binaries but if your goal is that Plan 9 binaries run unchanged on such a system then you will require some sort of device mapping layer, say a FUSE file system that makes Linux devices look like their Plan 9 counterparts - the chief problem being mapping between Linux ioctls and the Plan 9 ctl file protocols. While you could do that, I have my doubts as to how complete this would be and whether it would be maintained. Moreover, it doesn't do anything to cause Linux and Plan 9 to converge. Since it is difficult to make ioctl work over the network unless source and destination have the same binary architecture Linux needs to be encouraged to change to be closer to the Plan 9 device model, or at least to a portable ioctl model. Providing a mapping layer just entrenches the problem with Linux and moves Linux no closer to a solution. Unfortunately, even though there are clustering solutions available which even address process migration Linux people seems quite happy to address remote device access with ad hoc solutions. I see a GNU/Linux/Plan 9 distro as making Plan 9 more appealing to the greater public and to aid its domination. Screw fixing Linux to be more Plan 9 like, lets assume Plan 9 has won and the rest is a mere implementation detail. Perhaps some of users attracted buy such a disto will be encouraged to add Plan 9 support for their devices or modify Linux libraries to access Plan 9 natively rather than via Linux emulation. Nothing should be removed, where Plan 9 does something in a perfectly acceptable and sensibly complete way it should be the only mechanism provided (in the long term at least) and the Linux code reliant on the missing mechanism ported to work natively with Plan 9 - unless it is much less work to emulate whatever is missing. To take code using ioctl as an example, the code should be refactored so that both a Plan 9 and Linux libraries with a portable interface are produced, and the modified Linux source and libraries submitted to the current maintainers. However, standard C wchar_t based programs probably should be left alone rather the modified to use the Plan 9 string processing model. Now just for the hell of it, let imagine a world where clustering solutions are built on a Plan 9 base. I'd certainly like something where my local processes migrate from my lower powered laptop including the Window manager migrate to a more powerful CPU when it becomes available and back again when my laptop becomes disconnected, Now, if I ever can decide on a Linux distribution and ever get Plan 9 to boot, I will see what I can do...
Re: [9fans] RFS alternatives (Was: Living with Plan 9)
--- On Tue, 28/6/11, erik quanstrom quans...@quanstro.net wrote: Speaking of device numbers, I was surprised that Plan 9 has a similar notion. However, they are only useful with kernel resident device numbers. Does Plan 9 have some other mechanism that allow one to identify the class of device/file server it belongs to? In most cases, a name is good enough, but sometimes its not. no. most stereotypical drivers are written in the miniport style. (please excuse the reference.) where one bag of generic code provides the interface, so one interacts with all ethernet, serial or storage devices in the same way. Ok, then I misunderstand what the stat man page means by Type identifies the server type, and dev says which of a group of servers of the same type is the one responsible for this file Code that relies on testing the server type is bad style anyway, its better if the server can supply a bunch of predicates so a client can test what operations a server supporta, a client should not mistake one type of device for another one. After all, an ethernet doesn't provide the same level of persistence a storage device does! And speaking of opaqueness, while Plan 9 might use portable data representations, some interfaces are perhaps unnecessarily opaque in a different way. Consider the uart ctl file with its encoded string of device attributes. what kind of abstract manipulation of serial devices could you imagine would be useful? I wasn't motivated about manipulating serial devices per se, I was thinking about reflective interfaces and programs that use metadata to learn about the behaviour of interfaces and provide user friendly UIs. Having separate files for each attributes makes that a little easier. A separate hierarchy mirroring that of the ctl directory might return the allowable values/syntax for attributes/operations. Serial devices are not that interesting for abstract manipulation but for the sake of the argument: we can classify the comms devices into virtual circuit based and datagram based. The VC based into permanent and switched VC (PVC and SVC). And we can classify VCs into byte oriented (stream) and record oriented. We probably should have QOS attributes too, A serial line can be considered a byte oriented PVC with indeterminate or perhaps configurable QOS. If we include serial lines as a type of PVC, we better know if PVCs are 8 bit clean - alternatively perhaps only 8 bit clean devices can be PVCs. There's nothing here about manipulation really, PVCs don't have much scope for that, but stay tuned, so far this is more about attributes that allow clients to select the comms medium they're interested in. Speaking of which, some optional attributes that make the implicit local and remote addresses/identifier explicit as well as the implied upper level protocol are useful too. Most of these are read only attributes too, but some will be read-write so they can have their values set by administrators. So what can be manipulated? Flow control is something common to many virtual circuits including serial lines. Uart allow input and output queue lengths to be set which I assume affect flow control/blocking. TCP has windows which provide the same affect, *nixes allows them to be indirectly controlled by setting the send and receive buffer sizes via setsockopt or configured system wide, but Plan 9 doesn't seem to offer this facility. However, if one adds a modem to a serial line or the end of any PVC for that matter we can treat it like a SVC, in much the same way we treat TCP. Apart from QOS the only real difference is that the number of SVCs has a much lower limit than TCP. Oh, and it would be better if the uart device was consistent with the files in net with their separate data and ctl files, if one is going to rely on conventions they should be consistent. Despite the other faults of ioctl there's no doubt where the control interface of a device is. but it does. there's eia0status, eia0ctl and eia0 (the data file). ; ls '#t' '#t/eia0' '#t/eia0ctl' '#t/eia0status' '#t/eia1' '#t/eia1ctl' '#t/eia1status' Sorry, I meant structured like the files in net. So, the uart could instead by structured as: eia/ 0/ ctl data status 1/ ctl data status there could also be clone entry directly under eia if we wished to have an allocation scheme if the various serial lines are equivalent, e.g. attached to modems and of course a stats interface too. Regards, Andrew - erik
Re: [9fans] RFS alternatives (Was: Living with Plan 9)
--- On Wed, 22/6/11, David Lukes davelu...@mac.com wrote: ... I'm no RFS guru, thank deity, but I did RTFC once and F was apposite. It took me a little time to figure out RTFC wasn't a remote file system ;-) ioctl was handled by having the client know exactly what each ioctl looked like, i.e. it only worked for known cases. ... Thanks for pointing out the folly in my thinking. I was hoping for a user/administrators view of RFS but the under the hood perspective is welcome. I'd forgotten that the variable(!) trailing parameters of the ioctl are opaque at the system call level, i.e. their layouts are only known to the application program and device drivers. So the best that can be done in a generic manner is to send ioctls only between systems with identical binary representations (possibly remapping major/minor device numbers). Maybe if RFS had been more successful over NFS, (or Linus knew more about Plan 9) the Unix interface would have been fixed by now. I wonder if there is any level of acceptance amongst *nix kernel developers that this is a problem. I can think of schemes to fix this without having to modify every program that issues an ioctl - though that would be a good idea in the long run - /merely/ having to modify every device driver implementing ioctls to assist in the remote translation. While it might seem unfeasible to modify every device driver in this class to support this behaviour, the kernel interfaces change frequently so perhaps this might indeed be possible. Speaking of device numbers, I was surprised that Plan 9 has a similar notion. However, they are only useful with kernel resident device numbers. Does Plan 9 have some other mechanism that allow one to identify the class of device/file server it belongs to? In most cases, a name is good enough, but sometimes its not. And speaking of opaqueness, while Plan 9 might use portable data representation, some interfaces are perhaps unnecessarily opaque in a different way. Consider the uart ctl file with its encoded string of device attributes. If each attribute used a separate file, with meaningful names, the parameters of the interface, although unfortunately not their range of values, would be available. Given that it is not, some other form of automated description is desirable, ideally accessible from the file system itself rather than requiring use of a library. While we have learned (been forced) to live with files that are bags of bytes, I think it would be better not to repeat this with interfaces too. Oh, and it would be better if the uart device was consistent with the files in net with their separate data and ctl files, if one is going to rely on conventions they should be consistent. Despite the other faults of ioctl there's no doubt where the control interface of a device is. Andrew
Re: [9fans] RFS alternatives (Was: Living with Plan 9)
--- On Tue, 21/6/11, Eric Van Hensbergen eri...@gmail.com wrote: ... Um, does v9fs remote Linux devices? I find it hard to imagine it would remote ioctls but it makes sense *nix to *nix. Depends on how you configure it. There is a nodevmap option to the v9fs mount which will instruct it to just access the remote devices directly instead of just mapping their major/minor numbers to local devices. You are correct in your imagining that we don't go anywhere near ioctls with a 10 foot pole. However, many things just work without ioctls these days. Thanks for the info, but the devices encumbered with ioctls are the tricky ones and even if they can be sorted out I'm sure there are some other traps out there. Too bad there are no RFS gurus lurking here to offer their wisdom on remoting devices. I have a sneaking suspicion few people would have bothered, since the few devices worth remoting back then were easily handled by rsh/rcmd. Did RFS make it beyond SVR4? That just leaves my issues with X. Actually, its a bit worse than that. The physical network devices aren't file system accessible anymore, Actually, I'd blotted out of my mind all knowledges of STREAMs devices and the related horror of TLI programming until you reminded me. so you'd need to remote them as a service (via Inferno or something) or use the tap device and remote that and hope that it doesn't require ioctls (and I think it might). Oh, I'm not worried about remoting network interfaces. I'm fine with packet forwarding and can live with NAT for now. However, it reminds me of another point in Plan 9's favour that the introductory papers should be updated to be more explicit about - NATs are unnecessary in a pure Plan 9 deployment. Unfortunately, neither Plan 9 routers or decent alternatives to NAT such as RSIP widely available. -eric Andrew P.S. There's spammers subscribed to this list. Hi there, friends of Khalifa.
[9fans] RFS alternatives (Was: Living with Plan 9)
--- On Wed, 8/6/11, I wrote in part: I am old enough to remember RFS the Remote File Sharing Protocol on SVR4 that offered access to remote devices, but I don't have that and I'm not aware of whether there are any distributed file protocols freely available for *nix that do that. Um, does v9fs remote Linux devices? I find it hard to imagine it would remote ioctls but it makes sense *nix to *nix. If not, are there any other alternatives? Are there any gotchas remoting *nix devices? If v9fs works in such a configuration it would eliminate most of the issues I have with *nix resource sharing - unless I use a platform without 9fs a 9fs client and servers. That just leaves my issues with X. Cheers, Andrew
[9fans] Living with Plan 9
Is there anybody out there using Plan 9 as their primary operating system for typical user tasks such as web browsing, word processing etc. I'm shopping for a new operating system for my trailing edge hardware, and my heart and my head cannot agree on how much effort I should devote into adopting Plan 9. I'd like to have an easy life but I am somewhat driven to minimise the ugliness that I have to deal with on my systems. I do most of my computing on low spec laptops and occasionally want to remotely run apps or access files on a higher spec PC. Unfortunately, I find that remote X11 is mostly less than satisfactory on my home ethernet let alone on 802.11b. (To think people once claimed X was satisfactory on 128kbps). Perhaps compression or VNC might improve things. Then of course, there is remote access to other peripherals. Or rather the lack of it. I am old enough to remember RFS the Remote File Sharing Protocol on SVR4 that offered access to remote devices, but I don't have that and I'm not aware of whether there are any distributed file protocols freely available for *nix that do that. Of course, there are clients and servers for most peripherals to allow remote access but one needs to go to some effort to set this up and hope that whatever software one uses can be coaxed into using the appropriate client... I know Plan 9 solves these issues and more, but hardware and software support is lacking. I note there is a Linux user binary emulation and X11 available. Is it sufficient to set up a Linux environment on Plan 9 including all the niceties offered by Linux modern distribution? Does this completely defeat the purpose of using Plan9 in the first place ? If it makes sense, I'd appreciate some guidance in this regard. If not, some suggestions on how to best live with *nix ugliness would be welcome. Thanks, Andrew
[9fans] Can't compile kernel
Hello! In parallel to the old Laptops i have installed Plan9 now on an ACP mini motherboard. Did not work out, until i found the Eric Qanstroms 9atom.iso - a Big thank you to Erik. Why would it be that this ISO not mentioned in the installation instructions on the Plan9 wiki...? Next step would have been, to compile a pccpuf kernel. Easy enough: cd /sys/src/9/pc mk 'CONF=pccpuf' But! instead of a kernel i get: ../port/flags: '../port/flags' does not exist ../boot/libboot.a8 doesn't exist: assuming it will be an archive 8c -FTVw i8253.c mk: no recipe to make 'devcec.8' in directory sys/src/9/pc A 'pull' updates some files, but does not change the situation. Any tip to get me working? Regards, Jorge-León
[9fans] Just one piece o' help.
Greets all. If I may please, i'm a plan9 newbie. Don't know a thing about writing code or programming, nor do I know anything about networking other than what dhcp does for me. Thusly, i'm just a user. I enjoy figuring out everything I can on my own when possible, having learnt alot from so many years of Slackware and FreeBSD. Truthfully, I just need help understanding how to do one thing. Installing other softwares. How do I take something (say from the sources index on the plan9 homesite) and install it? I can't find an equivalent to anything like pkg_add or the classic configure/make/make install type of thing. Thank you in advance for your help folks. Truly. I prefer minimalism in my interface and considering (what I see) to be the pure beauty of the plan9 interface and design, I hope I can someday make it my everyday OS. In short; nice to meet ya :) Hope I can become as proficient here as alot of you are. --Q
Re: [9fans] 3c509b troubles
On Fri, Aug 29, 2008 at 12:40:29PM -0500, michael block wrote: from what i can tell by gleaning the 9fans archives, the 3c509b is quite a troublesome card. i found rumors of a dos utility that would convince the card to change its port and irq. i think this leaves me with two questions. first, where do i find this fabled configuration program? googling has proved fruitless. Frail memory triumphs over the almighty Google at last! 3C5X9CFG.EXE can be found in this self-extracting archive: ftp://ftp.3com.com/pub/nic/3c509/3c509x2.exe I think it needs 3C5X9ENG.HLP from the same archive as well.
