Re: [9fans] package system for Plan 9: alpha!
On Sat, May 15, 2010 at 7:56 PM, Federico G. Benavento wrote: > hmm... this looks good, you are still using the .iso's > from the existing packages. not quite. I actually recreate all the .iso's from the proto files in replica//proto. The reason is that in some cases, the root/ directories for some contributors contain multiple packages, and I wanted to have one .iso per package. > using hget makes it faster of course, you could > hget from http://plan9.bell-labs.com/sources/contrib > but that would mean the user/package thing... > centralization sometimes makes things easier. This is kind of a test idea, I decided not to clutter up plan9 site with it. It may make sense to just leave it at sources however. It's easy to. In fact it's there now: contrib/rminnich/package has it all. 9grid.net is on esnet, which is an OC192, which means it has lots of bandwidth for users ... but all the .iso.bz2 in the packages directory originates from sources. thanks ron
Re: [9fans] nupas update
On Sat, May 15, 2010 at 9:57 PM, Akshat Kumar wrote: > http://9grid.net/rminnich/src/package-tools/install no, it's not there, as I am not yet satisified with the right way to do this. > > - instead, there is a straight dircp. yes. > So, is this a thing you're developing personally? no, what you see is what I've got right now. It actually works quite well, and probably I should just create a /installed directory, but that was actually an afterthought. What do you recommend? > In consideration of your bind idea, remember: unimplemented because I could not quite get it to work. Example: I mount python.iso and do an Aki rbind -ra of /n/python/root / Well ... it just didn't want to work, somehow, although I forget why. I punted at that point and did the dircp, I just ran out of time. >I think you > can go a little further: the /installed/$i file on > disk can contain info for binding the installed > package onto /. Then, the /installed/$i file > resulting from the binds can contain removal > procedures. > > I'm not sure what would be the most comfortable > from a use perspective, but it's an idea I think it's worth trying out. I just don't have the time right now. So, if we just go with the dircp approach, and copy the files in, what I hear is missing so far: - I don't put the installed info into /installed; should I just go ahead and fix that? What else? ron
Re: [9fans] nupas improper error output
> term% /n/sources/plan9/386/bin/upas/fs -f /imaps/imap.gmail.com > /n/sources/plan9/386/bin/upas/fs: opening /imaps/imap.gmail.com: > imap.gmail.com/imaps:server certificate XXX not > > term% upas/fs -f /imaps/imap.gmail.com > upas/fs: opening /imaps/imap.gmail.com: imap.gmail.com/imaps:fd out of > range or not open > > (cert replaced with "XXX") > So there's some part of the error reporting > in nupas that hides the real problem, which > is with the certificate having changed. error message fixed. add: x509 sha1=d5120bf1c88f4b105d18ae0c909a4c2d88c7d002 cn=*.gmail.com to /sys/lib/tls/mail - erik
Re: [9fans] standalone terminal w/ kfs no fossil
On Saturday 15 May 2010 9:23:51 erik quanstrom wrote: > there's currently no kfs/cwfs install option. it's only my list of things > to do. > Good to know, looking forward to when that's ready! > remember that kfs != ken's fs > Cool thanks: I was indeed under the impression that they were the same thing. kfs is definitely what I'm after. On Saturday 15 May 2010 9:19:30 Akshat Kumar wrote: > I use kfs on a standalone Plan 9 box. > The computer has a 100 MHz CPU with > some 48 MB RAM. fossil hogs all > processing power. kfs on the other hand > is wonderfully stable and low maintenance. > Perfect. > The install procedure from CD involved > manually going through the install > commands. > Just make your partition and use the > install scripts as a guide for copying > stuff over from the CD onto kfs disk. > Ok, cool - I'll try that; though I imagine my first attempt will likely be a disaster...
Re: [9fans] nupas update
On 5/16/10, ron minnich wrote: > On Sat, May 15, 2010 at 9:28 PM, Akshat Kumar > wrote: > >> I notice you don't keep a list of >> installed file paths in /installed/$i > > I do, but the intent is that you bind -a package /, and the > 'installed' in there has the > files. > > I have this allergy to dropping stuff into / :-) However, I don't see such binds going on in your install script at http://9grid.net/rminnich/src/package-tools/install - instead, there is a straight dircp. So, is this a thing you're developing personally? >> Perhaps the file itself can contain >> the binds and mounts specific >> to its going about its own removal. In consideration of your bind idea, I think you can go a little further: the /installed/$i file on disk can contain info for binding the installed package onto /. Then, the /installed/$i file resulting from the binds can contain removal procedures. I'm not sure what would be the most comfortable from a use perspective, but it's an idea Best, ak
Re: [9fans] nupas update
On Sat, May 15, 2010 at 9:39 PM, erik quanstrom wrote: >> I do, but the intent is that you bind -a package /, and the >> 'installed' in there has the >> files. > > that won't work unless the differences are at the same > level as the bind, in this case /. I already do that today :-) term% bind -a package / term% ls /installed /installed/bz2 /installed/hg /installed/openssl /installed/python /installed/tex /installed/z term% thanks ron
Re: [9fans] custom-built plan9 iso?
On Sun, May 16, 2010 at 1:47 AM, Iruata Souza wrote: > On Sat, May 15, 2010 at 8:41 PM, Corey wrote: >> On Saturday 15 May 2010 2:57:12 Mathieu Lonjaret wrote: >>> As far as I am concerned: >>> http://9fans.net/archive/2008/05/263 >>> >>> and here's maht's blog entry about it: >>> http://maht0x0r.blogspot.com/2007/11/roll-your-own-plan9-iso.html >>> >> >> Excellent - thanks! (I believe there was one other source of >> notes on the subject... at least from what I remember of that >> thread I mention - but this should get be going) >> >> Cheers >> >> > > i've written http://src.oitobits.net/9null/raw-file/bba1ea6a9313/util/mkiso > for 9null. be careful it uses a non-standard -B option to mkiso(8). > reading http://src.oitobits.net/9null/raw-file/2478889c5356/util/mkiso and http://src.oitobits.net/9null/raw-file/2478889c5356/boot/pc/mkfile may be more useful for a standard installation. iru
Re: [9fans] custom-built plan9 iso?
On Sat, May 15, 2010 at 8:41 PM, Corey wrote: > On Saturday 15 May 2010 2:57:12 Mathieu Lonjaret wrote: >> As far as I am concerned: >> http://9fans.net/archive/2008/05/263 >> >> and here's maht's blog entry about it: >> http://maht0x0r.blogspot.com/2007/11/roll-your-own-plan9-iso.html >> > > Excellent - thanks! (I believe there was one other source of > notes on the subject... at least from what I remember of that > thread I mention - but this should get be going) > > Cheers > > i've written http://src.oitobits.net/9null/raw-file/bba1ea6a9313/util/mkiso for 9null. be careful it uses a non-standard -B option to mkiso(8).
Re: [9fans] nupas update
> I do, but the intent is that you bind -a package /, and the > 'installed' in there has the > files. that won't work unless the differences are at the same level as the bind, in this case /. - erik
[9fans] nupas improper error output
The following tells the story: term% /n/sources/plan9/386/bin/upas/fs -f /imaps/imap.gmail.com /n/sources/plan9/386/bin/upas/fs: opening /imaps/imap.gmail.com: imap.gmail.com/imaps:server certificate XXX not term% upas/fs -f /imaps/imap.gmail.com upas/fs: opening /imaps/imap.gmail.com: imap.gmail.com/imaps:fd out of range or not open (cert replaced with "XXX") So there's some part of the error reporting in nupas that hides the real problem, which is with the certificate having changed. Best, ak
Re: [9fans] nupas update
On Sat, May 15, 2010 at 9:28 PM, Akshat Kumar wrote: > I notice you don't keep a list of > installed file paths in /installed/$i I do, but the intent is that you bind -a package /, and the 'installed' in there has the files. I have this allergy to dropping stuff into / :-) > Perhaps the file itself can contain > the binds and mounts specific > to its going about its own removal. Yes, this is a good idea. I have not taken this idea as far as it can go; consider it a preliminary step and I welcome the kinds of improvements that you smart guys are proposing! thanks ron
Re: [9fans] nupas update
By the way, Ron, in order to sort this mess out, with the help of Federico, I essentially carried out the operations in the install script of your new package system. I notice you don't keep a list of installed file paths in /installed/$i -- is that something you've already tried, for maintaining removal info and what not? Perhaps the file itself can contain the binds and mounts specific to its going about its own removal. Best, ak On 5/16/10, ron minnich wrote: > On Sat, May 15, 2010 at 4:45 PM, erik quanstrom > wrote: >> sometimes replica gets in its own way. usually when >> it gets confused, i remove /dist/replica/$x and >> /dist/replica/client/$x* and often remove any potentially >> conflicting files. i suppose it would be better to get >> replica to tell me about conflicts and use -s. > > Sometimes eh :-) > > For me, more often than that :-) > > This type of situation is why I like the concept of packages that > never overwrite files in the root file system. To back out you just > get rid of the package file, reboot --> fixed. I feel we need > improvement on this score. > > Seems to me with a reasonable set of mount and then binds we could > make this type of thing work, and copy files all over / would be a > thing of the past. That's what I was trying to do with my attempted > package system but failed. Possibly we could put a file in the file > system image called autorun.ini that sets things up, i.e. does binds > and whatever else is needed? That in essence is what tinycore does ... > save for the binds . > > ron > >
Re: [9fans] standalone terminal w/ kfs no fossil
> I'm thinking about going through another installation, and I'm wondering > whether there's usefulness in undertaking a standalone terminal install > using only kfs rather than fossil? And if so, how is this currently done? there's currently no kfs/cwfs install option. it's only my list of things to do. > As far as I can tell, I'd want to use Erik's 9atom iso - which seems to > support Ken's fs (http://www.quanstro.net/plan9/9atom/index.html)? - > but the current install scripts only prompt for fossil or fossil+venti. remember that kfs != ken's fs != cwfs. but they are all three strongly related. ken's fs stands apart in being a stand alone kernel with no user space; it only make sense to provide an install option for the other two. - erik
Re: [9fans] standalone terminal w/ kfs no fossil
I use kfs on a standalone Plan 9 box. The computer has a 100 MHz CPU with some 48 MB RAM. fossil hogs all processing power. kfs on the other hand is wonderfully stable and low maintenance. Plus, the code is beautiful. The install procedure from CD involved manually going through the install commands. The install scripts are easy to read and figure out. Just make your partition and use the install scripts as a guide for copying stuff over from the CD onto kfs disk. That's all to it. Best, ak On 5/16/10, Corey wrote: > > I'm thinking about going through another installation, and I'm wondering > whether there's usefulness in undertaking a standalone terminal install > using only kfs rather than fossil? And if so, how is this currently done? > > As far as I can tell, I'd want to use Erik's 9atom iso - which seems to > support Ken's fs (http://www.quanstro.net/plan9/9atom/index.html)? - > but the current install scripts only prompt for fossil or fossil+venti. > > >
Re: [9fans] nupas update
> This type of situation is why I like the concept of packages that > never overwrite files in the root file system. To back out you just > get rid of the package file, reboot --> fixed. I feel we need > improvement on this score. the ramfs trick will not work if you have a standard plan 9 network with >1 machine. if you used /lib/namespace instead, things would be better. unfortunately since union mounts are not deep, this would be a very difficult thing to construct. i still think it's a mistake to think that not overwriting things is a panacea. the essential problem in this case is that is is difficult (if not impossible) to test the tuple (original version upgrade version, base system). - erik
[9fans] standalone terminal w/ kfs no fossil
I'm thinking about going through another installation, and I'm wondering whether there's usefulness in undertaking a standalone terminal install using only kfs rather than fossil? And if so, how is this currently done? As far as I can tell, I'd want to use Erik's 9atom iso - which seems to support Ken's fs (http://www.quanstro.net/plan9/9atom/index.html)? - but the current install scripts only prompt for fossil or fossil+venti.
Re: [9fans] package system for Plan 9: alpha!
hmm... this looks good, you are still using the .iso's from the existing packages. using hget makes it faster of course, you could hget from http://plan9.bell-labs.com/sources/contrib but that would mean the user/package thing... centralization sometimes makes things easier. kudos On Sat, May 15, 2010 at 12:43 PM, ron minnich wrote: > Here is a refinement of fgb's fine work on a contrib system. I have > taken his ideas a bit further, based on my use of his tools in an > unreliable environment. I was getting quite frustrated as I had > multiple failures in the midst of an install, and seeing the message > 'xyz already installed', when it was only 1/2 installed, was wasting > time. Also, I'm just not patient enough to wait for replica to do its > work. > > While I think both replica and the contrib system are quite capable, > each in their own way, I felt they were lacking for my purposes. I > have become very impressed with how tinycore linux does binary > packages. I decided to enumerate what I like about that system, and > based on that, what I'd like to have on Plan 9. Not all goals are met > however. > > 1. reconstitute root file system on boot, in ram, then mount packages > as file systems, so basic root remains pristine > 2. fast -- listing and dependencies should take well under a second; > package install of even big things should be under 3 minutes. > 3. easy to list package dependencies quickly > 4. auto-install of a package and its dependencies > 5. separate package download from install; hence download can proceed > in parallel (not really in tinycore, just possible) > 6. know what packages are installed quickly and easily > 7. easy to remove a package; just remove one file, reboot, it's gone (see 1) > *note*: when your system boots in 10 seconds, reboot is not that big a deal > 8. no false positive: don't think a package is installed when it is > not or is only partially done (due to failure for example) > 9. false negatives are ok: if a package is installed but you don't > think it is, reinstallation should be cheap > 10. No need for continuous tinkering of db or other files to keep it > working correctly. > 11. Works well in a high latency, even if high bandwidth, network. > > Which of these goals does replica meet, e.g. for /sys/src? > From my point of view, none of them. > > Which of these goals does the current contrib system meet? > Much as I like the contrib system, it still depends on replica, so, > from my point of view, none of the goals are met. > I once saw it take four hours to install openssl. That's just not workable. > > Which of these goals does the gui-based contrib system meet? > This is the system that downloads .iso files and then runs replica > against them. It meets 3, to some extent, but is still too slow for > me; it sort of meets 6; but, unfortunately, it fails on 8. > > Which of these goals does my extension meet? > 2 -- can download/install all of hg, including all dependencies, in 3 > minutes, 2 of which are hget > 3 -- .1 seconds for 'deps hg'; .1 second for list packages; < .1 > second for list installed > 4 -- it knows the dependencies and will install everything with one command > 5 -- get and install are seperate commands > 6 -- ls /installed > 8 -- yes -- /installed/ is only created when the package is > completely installed (but there are bugs still) > 9 -- yes > 10. there is little in the way of a db file, just a /installed > directory (which you get by a bind -a) > 11. It's far faster than existing systems because it uses hget > > 1. is obviously not yet met. I think it would be worth doing a tiny 9, > just as we have tinycore, for terminals. > 7. is still not met. Package removal is still a mess. I had hoped to > just mount the .iso's and run the tools out of them but have not > figured out all the issues yet. A simple rbind failed to do the trick. > > Here are some examples. > > # available packages > term% time list > 4th > 8169 > 82563 > 9load-e820 > 9win > X11 > abaco > > (etc.) > 0.00u 0.00s 0.11r list > > # what packages does hg need? > term% time deps hg > z > bz2 > openssl > python > 0.00u 0.00s 0.10r deps hg > > #install tiff > term% install tiff > package is tiff > Package z already installed, no need to do it > 9660srv 1151: serving /srv/tiff > FINIS > > #install tiff again > term% install tiff > package is tiff > Package z already installed, no need to do it > Package tiff already installed, no need to do it > FINIS > term% > > Sources to these tools, including the build script, are at > http://9grid.net/magic/webls?dir=/rminnich/src/package-tools > > You can try them out -- it's all there. Packages are in > http://9grid.net/magic/webls?dir=/rminnich/src/package > > I don't pretend the scripts are very good, they just represent a > starting point. Experience (mine) is that the system work well. For > example, just doing: > > get openssh > install openssh > > takes very little time and has worked reliably for me on 9vx. > > A
Re: [9fans] nupas update
On Sat, May 15, 2010 at 4:45 PM, erik quanstrom wrote: > sometimes replica gets in its own way. usually when > it gets confused, i remove /dist/replica/$x and > /dist/replica/client/$x* and often remove any potentially > conflicting files. i suppose it would be better to get > replica to tell me about conflicts and use -s. Sometimes eh :-) For me, more often than that :-) This type of situation is why I like the concept of packages that never overwrite files in the root file system. To back out you just get rid of the package file, reboot --> fixed. I feel we need improvement on this score. Seems to me with a reasonable set of mount and then binds we could make this type of thing work, and copy files all over / would be a thing of the past. That's what I was trying to do with my attempted package system but failed. Possibly we could put a file in the file system image called autorun.ini that sets things up, i.e. does binds and whatever else is needed? That in essence is what tinycore does ... save for the binds . ron
Re: [9fans] fscons users -r/-w vs. editing /adm/users manually
On Saturday 15 May 2010 6:28:00 erik quanstrom wrote: > > So, assuming a non-venti server: when removing users from the fossil > > filesystem, there's no effective difference whether I do so by manually > > editing /adm/users versus fscons: users -r/-w [file] ? > > > > I'm just slowly trying to accumulate "best practices" for my > > documentation efforts. > > personally, i'd shy away from recommendiations on removing > users, since it might not be appropriate for all system setups. > Certainly - fair and proper warning and details will be provided, however I'm taking a "full disclosure" approach to my notes/documentation,and am attempting to cover the sort of questions/scenarios that new users such as myself might be confronted with. ( I'm trying to write the kind of docs that I myself would have liked to have had available during my own initial forays into Plan 9 setup and administration ) [I mean no sleight against the current wiki] > anyway, if you edit /adm/users, you may have to tell the fs about > what you've done. > Perfect, thanks: In the event that a hostowner intentionally wants to remove a user from the users table, I'll recommend that 'users -r/-w [file]' be used rather than merely editing /adm/users directly. cheers
Re: [9fans] fscons users -r/-w vs. editing /adm/users manually
> So, assuming a non-venti server: when removing users from the fossil > filesystem, there's no effective difference whether I do so by manually > editing /adm/users versus fscons: users -r/-w [file] ? > > I'm just slowly trying to accumulate "best practices" for my documentation > efforts. personally, i'd shy away from recommendiations on removing users, since it might not be appropriate for all system setups. anyway, if you edit /adm/users, you may have to tell the fs about what you've done. - erik
Re: [9fans] "laggy" drawterm on local network?
On Saturday 15 May 2010 6:26:05 erik quanstrom wrote: > > Ah... heheh - cleary: because I'm using drawterm and drawterm > > doesn't do IL? (sorry if that's a lame question) > > currently, that's up to the host os. and none of the host > oses do. > Of course, that makes sense - thanks!
Re: [9fans] "laggy" drawterm on local network?
> Ah... heheh - cleary: because I'm using drawterm and drawterm > doesn't do IL? (sorry if that's a lame question) currently, that's up to the host os. and none of the host oses do. in theory one could send raw packets from dt directly. - erik
Re: [9fans] boot errors using most recent plan9.iso
On Saturday 15 May 2010 5:25:38 erik quanstrom wrote: > > ... but I'm wondering: why does 9load seem to sometimes suffer > > from apparent regressions in the official iso? > > i think the bios calls that the official distribution > supports have been the source of a lot of trouble. > i've been looking into why that might be, but don't > have any answers yet. > Roger that: I can confirm that the install went just fine using your iso's in lieu of the current official iso. (I had used the official iso several months ago on the very same machine, and had no issue... which is what led me to wondering about 9load regressions in the official distro). Cheers
Re: [9fans] fscons users -r/-w vs. editing /adm/users manually
On Saturday 15 May 2010 5:55:33 erik quanstrom wrote: > On Sat May 15 19:56:50 EDT 2010, co...@bitworthy.net wrote: > > If one wants to remove an existing user from the fossil file server, > > is it perfectly ok to simply edit /adm/users, as the hostowner user, > > directly? Or is it considered better practice to issue users -r/-w via > > fossilcons? Or is there effectively no real difference? > > if you are using venti and thus have a dump (snapshots), i would > recommend against removing users since removing users can make > the dump unintelligible. at coraid, we just disable auth. > Ack - I should have mentioned: fossil only, no venti - no snapshots. So, assuming a non-venti server: when removing users from the fossil filesystem, there's no effective difference whether I do so by manually editing /adm/users versus fscons: users -r/-w [file] ? I'm just slowly trying to accumulate "best practices" for my documentation efforts.
Re: [9fans] "laggy" drawterm on local network?
On Saturday 15 May 2010 4:49:32 erik quanstrom wrote: > On Sat May 15 17:33:49 EDT 2010, co...@bitworthy.net wrote: > > On Saturday 15 May 2010 2:31:57 Corey wrote: > > > I'm on a 802.11g here on my lan in my house, where my cpu/auth server > > > sits - and drawterm is noticeably slow/laggy. > > > > > > > > Oh yeah - I'm using tcp and not il. > > clearly! > Ah... heheh - cleary: because I'm using drawterm and drawterm doesn't do IL? (sorry if that's a lame question) > /dev/draw is very efficient, but graphics are being > pushed over the wire. and since tcp is not record preserving, > a local wireless network is just the sort of thing where the > delayed ack might hurt. > I'd like to try IL next, just so I have some direct personal experience with it vs. TCP. > i use wireless (borrowed laptop) about once a month and > don't see any issues. perhaps you're on a busy or contended > channel? > Wow - o.k., I just went and switched my laptop off the wireless, and connected via ethernet... and damn - huge difference: drawterm operations are now silky smooth. I'll now try different channels on my wifi router, see if that makes a difference with my drawterm's performance over wireless. Thanks!
Re: [9fans] fscons users -r/-w vs. editing /adm/users manually
On Sat May 15 19:56:50 EDT 2010, co...@bitworthy.net wrote: > > If one wants to remove an existing user from the fossil file server, > is it perfectly ok to simply edit /adm/users, as the hostowner user, > directly? Or is it considered better practice to issue users -r/-w via > fossilcons? Or is there effectively no real difference? if you are using venti and thus have a dump (snapshots), i would recommend against removing users since removing users can make the dump unintelligible. at coraid, we just disable auth. - erik
[9fans] programs not using ARGBEGIN
here's a different approach.
#!/bin/rc
cd /$objtype/bin
for(i in `{find})
# if(! ~ $i */ape/*) # obviously
if(test -f $i)
if(! ~ `{file $i | sed 's/ /_/g'} *:_rc_executable_file)
if(! grep -s ARGBEGIN `{src -n $i|sed -n 's/([^:]+):.*/\1/p'}
/dev/null)
echo $i
many of these programs have no reason to parse
(any) traditional arguments, and some have earned their
wierdness by tradition, but programs like aux/clog
should be cleaned up. iirc, acid also has some argument
processing quirks.
- erik
Re: [9fans] boot errors using most recent plan9.iso
> ... but I'm wondering: why does 9load seem to sometimes suffer > from apparent regressions in the official iso? i think the bios calls that the official distribution supports have been the source of a lot of trouble. i've been looking into why that might be, but don't have any answers yet. - erik
Re: [9fans] "laggy" drawterm on local network?
On Sat May 15 17:33:49 EDT 2010, co...@bitworthy.net wrote: > On Saturday 15 May 2010 2:31:57 Corey wrote: > > I'm on a 802.11g here on my lan in my house, where my cpu/auth server > > sits - and drawterm is noticeably slow/laggy. > > > Oh yeah - I'm using tcp and not il. clearly! /dev/draw is very efficient, but graphics are being pushed over the wire. and since tcp is not record preserving, a local wireless network is just the sort of thing where the delayed ack might hurt. i use wireless (borrowed laptop) about once a month and don't see any issues. perhaps you're on a busy or contended channel? - erik
[9fans] fscons users -r/-w vs. editing /adm/users manually
If one wants to remove an existing user from the fossil file server, is it perfectly ok to simply edit /adm/users, as the hostowner user, directly? Or is it considered better practice to issue users -r/-w via fossilcons? Or is there effectively no real difference?
Re: [9fans] nupas update
On Sat May 15 19:18:57 EDT 2010, aku...@mail.nanosouffle.net wrote: > So, how to resolve this mess and finally install the > nupas package? It'd also be nice if somehow files > in /mail/lib and other places where installed without > hassle (though I'd like to keep some custom configs > there). first off, i'm sorry about the problems. i should have tested the nupas->nupas upgrade path more thoroughly. contrib isn't quite the right tool for a direct replacement. sometimes replica gets in its own way. usually when it gets confused, i remove /dist/replica/$x and /dist/replica/client/$x* and often remove any potentially conflicting files. i suppose it would be better to get replica to tell me about conflicts and use -s. i've attached the prototype for the files included in the replica perhaps this will help. you can get a full listing of what + expands to from a listing of /n/contrib/quanstro/root/... - erik386 bin upas addhash aliasmail bayes deliver filter fs imap4d isspam list marshal mbappend ml mlmgr mlowner msgcat msgtok nedmail pop3 qer runq scanmail send smtp smtpd spam spf testscan token unspam vf acme bin 386 Mail mail lib spamhaus validatesender rc bin usenupas splitmbox service !tcp993 tcp143 service.auth tcp993 sys man 1 faces filter mail marshal mlmgr nedmail 4 upasfs 6 mdir rewrite 8 aliasmail pop3 qer scanmail send smtp splitmbox usenupas src cmd faces + upas Mail + alias + bayes + binscripts + common + doc + filterkit + fs mkfile bos.c cache.c fs.c header.c idx.c imap.c mbox.c mdir.c mtree.c plan9.c planb.c pop3.c ref.c remove.c rename.c seg.c strtotm.c dat.h imap4d + marshal + misc + mkfile mkupas ml + ned mkfile nedmail.c
Re: [9fans] custom-built plan9 iso?
On Saturday 15 May 2010 2:57:12 Mathieu Lonjaret wrote: > As far as I am concerned: > http://9fans.net/archive/2008/05/263 > > and here's maht's blog entry about it: > http://maht0x0r.blogspot.com/2007/11/roll-your-own-plan9-iso.html > Excellent - thanks! (I believe there was one other source of notes on the subject... at least from what I remember of that thread I mention - but this should get be going) Cheers
Re: [9fans] nupas update
I have nupas from a long time back and recently decided to run contrib/install quanstro/nupas However, it seems that the nupas package has since been moved from nupas to overwrite the base upas, along with base files in /sys/man, other src directories (faces, etc.) and some files in /mail/lib. In short, my upas install is now botched with a mix of stuff from quanstro/nupas that could be updated, and a lot of missing stuff. I don't have a problem with overwriting completely, since nupas has been working so well for me for so long, but now I'm left in the cold with no proper upas or nupas (the old /386/bin/nupas was also removed during the pull). As such, I tried a subsequent pull with the -s flag to list directories I would like updated, but pull thinks everything is up to date, so it makes no action. Then I tried my hand at contrib/remove quanstro/nupas | rc contrib/install quanstro/nupas but of course that brings me back to where I was with the first contrib/pull. And of course a subsequent pull doesn't do anything, as described above. So, how to resolve this mess and finally install the nupas package? It'd also be nice if somehow files in /mail/lib and other places where installed without hassle (though I'd like to keep some custom configs there). Thanks, ak On Wed, Sep 2, 2009 at 7:16 PM, erik quanstrom wrote: > i've pushed an update of my nupas contrib > package to sources. imap successful in use > with apple mail (snow leper, too), iphone, > outlook, opera, ff, upas/fs. > > note on installing: > as devon pointed out, installation is still a > big pain. > 1. move /sys/src/nupas -> onupas > 2. contrib/install quanstro/nupas > > if you want to go cold turkey nupas, then > a. mv /386/bin/upas /386/bin/oupas > b. mv /386/bin/nupas /386/bin/upas > c. (opt) edit top-level mkfile to install in > /386/bin/nupas. > > if you want to hedge your bets > a. add "usenupas" to your profile > b. edit cpurc as you see fit to use nupas > binaries. > > cavet: i have not had a chance to retest the > contrib package. > > as always, feedback welcome. > > - erik > >
Re: [9fans] if only it had a tad more memory ...
On Fri, May 14, 2010 at 7:01 PM, erik quanstrom wrote: > > > It supposedly has 256K (which seems a lot for this type of app). I > > > noticed that they provide the Gerber file, schematic and assembly > diagrams, > > > and probably everything needed to seriously hack the thing if you > cannot > > > bend the chip and/or PIO lines to your will. > > > > > It's not running linux I take it :-) > > i wouldn't know what to do with it. it's not enough to run > plan 9 or even inferno. at 100mbit, you can't do packet filtering or > anything > like that. > > what would one use it for? > > - erik > > Looks like a serial to ethernet gateway. I can't think of anything else.
Re: [9fans] custom-built plan9 iso?
As far as I am concerned: http://9fans.net/archive/2008/05/263 and here's maht's blog entry about it: http://maht0x0r.blogspot.com/2007/11/roll-your-own-plan9-iso.html hth, Mathieu --- Begin Message --- Quite a while back, I recall someone was inquiring whether there was any documentation/notes available with regards to the process of creating one's own customized plan 9 iso - or related documentation detailing how the official iso/distro is built. If I remember correctly, there were a couple responses that provided links to these docs... but I'm unable to find the thread in question. Anyone know where I could find such info? --- End Message ---
Re: [9fans] iwp9.org (Re: BibTex collections of all 4 proceedings)
> the one big push for new mexico is spaceport america ... maybe we'd > get to see a test launch :-) > > but that's a serious hike from ABQ :-) True, then we can maybe move the venue to Los Cruses, Truth or Consequences, or maybe even Hatch (and right about time for the chili festival) ;-) I know an odd hole-in-the-wall biker bar down the road from hatch that serves the WORST food imaginable... I do not think I have any connections to Spaceport America, but could give it a fly ;-) EBo --
[9fans] custom-built plan9 iso?
Quite a while back, I recall someone was inquiring whether there was any documentation/notes available with regards to the process of creating one's own customized plan 9 iso - or related documentation detailing how the official iso/distro is built. If I remember correctly, there were a couple responses that provided links to these docs... but I'm unable to find the thread in question. Anyone know where I could find such info?
Re: [9fans] "laggy" drawterm on local network?
On Saturday 15 May 2010 2:31:57 Corey wrote: > I'm on a 802.11g here on my lan in my house, where my cpu/auth server > sits - and drawterm is noticeably slow/laggy. Oh yeah - I'm using tcp and not il.
[9fans] "laggy" drawterm on local network?
I'm on a 802.11g here on my lan in my house, where my cpu/auth server sits - and drawterm is noticeably slow/laggy. For instance, mousing up/down the rio menus, and drawing/moving new rio windows, scrolling through large amounts of text... all produce regular finegrained intermittent delays before "catching up"... it's just past the threshold of annoying/frustrating - especially as I was expecting smother operation here on my lan over relatively decent bandwidth. Before possibly spinning my wheels attempting to fix/diagonse potential issues on my home network/routing - I'd like to ask: is this actually normal, or is it likely something's up w/ my network to cause such noticeable lag on drawterm? (I've at least done the obvious to ensure no other network traffic is saturating my lan's pipe) Thanks!
Re: [9fans] iwp9.org (Re: BibTex collections of all 4 proceedings)
the one big push for new mexico is spaceport america ... maybe we'd get to see a test launch :-) but that's a serious hike from ABQ :-) ron
Re: [9fans] -- in rsc's g script
On Sat May 15 09:54:25 EDT 2010, rudolf.syk...@gmail.com wrote:
> > '--' tells the Plan 9 program argument parser to stop looking for
> > options. See arg(2).
>
> so is it a program dependent feature in the sence that I must know
> which program uses arg(2) and which does not?
> (E.g that grep uses it but some other command (is there any?) does not?)
> Must I read the program's source or should it be documented in man
> pages? -- there is nothing about this in the man page of grep...
for the record, grep also accepts -e which escapes the next option.
here's a list of all the single-file commands in /sys/src that don't
use ARGBEGIN/ARGEND. compiling a comprehensive list is
an exercize left to the reader. of course, only a hand full of
shell scripts use getflags and conform to the general convention.
- erik
---
; x=`{grep -l ARGBEGIN *.c}
; for(i in *.c) if (! ~ $i $x) echo $i
ar.c
awd.c
basename.c
cal.c
cat.c
chmod.c
clock.c
dd.c
echo.c
factor.c
fortune.c
getmap.c
html2ms.c
join.c
kbmap.c
kprof.c
lens.c
mc.c
msleep.c
mv.c
p.c
pbd.c
pr.c
pwd.c
sleep.c
sort.c
swap.c
tail.c
test.c
time.c
tprof.c
uniq.c
unlnfs.c
unmount.c
xd.c
Re: [9fans] -- in rsc's g script
> consider the classic question: "how do I remove a file called -z" rm ./-z
Re: [9fans] iwp9.org (Re: BibTex collections of all 4 proceedings)
On May 15, 2010, at 10:12 AM, EBo wrote: If I thought people would actually come, I would see if I could organize something in Ouray Colorado. Do you live in that neck of the woods? Yes. There aren't many tech people around here and I think it would be great to get a group of Plan 9 people here. However, since that is unlikely, I am figuring out if I can make it to Seattle this year. I have a client in Eugene Oregon that I visit and Seattle isn't that much further. Kim
Re: [9fans] iwp9.org (Re: BibTex collections of all 4 proceedings)
> If I thought people would actually come, I would see if I could organize > something in Ouray Colorado. Do you live in that neck of the woods? > It is about 300 miles north of Albuquerque > in the San Juan Mountains. You get there by first flying to Denver, > Phoenix, or Albuquerque, then catching a puddle-hopper to Montrose and > then renting a car or catching a shuttle to go the remaining 35 miles to > Ouray. I think it fails the "transport hub" test but it would be > equally > inconvenient for everyone and the hotel rates are cheap in October. ROFLOL! This reminds me back in the 90's when they were rebuilding I25 through Albuquerque and the I24/I40 interchange. Things were a mess, and us locals called the construction zone the orange barrel raceway. Well, to break the frustration one of the local radio stations hosted a competition where the winner won an All Expenses Paid Vacation to Gimon Oklahoma where the orange barrels are made. To top things off, a farmer named Joe picked them up at the regional airport in a tractor, and took them on the 40 minute ride to their motor lodge hospitality suite. I believe that the mayor gave them a key to the city outhouse or something, and they were the guest judge for the local chilli cooking contest... I think if we really tried hard we could find a fun and completely unacceptable locations. My vote would be Illfeld New Mexico (population ~75), where I served my blacksmithing apprenticeship. I think the only public accommodations at all is the RV park 6 miles down the road. No, we would likely be pitching tents and hauling water ;-) EBo --
[9fans] package system for Plan 9: alpha!
Here is a refinement of fgb's fine work on a contrib system. I have taken his ideas a bit further, based on my use of his tools in an unreliable environment. I was getting quite frustrated as I had multiple failures in the midst of an install, and seeing the message 'xyz already installed', when it was only 1/2 installed, was wasting time. Also, I'm just not patient enough to wait for replica to do its work. While I think both replica and the contrib system are quite capable, each in their own way, I felt they were lacking for my purposes. I have become very impressed with how tinycore linux does binary packages. I decided to enumerate what I like about that system, and based on that, what I'd like to have on Plan 9. Not all goals are met however. 1. reconstitute root file system on boot, in ram, then mount packages as file systems, so basic root remains pristine 2. fast -- listing and dependencies should take well under a second; package install of even big things should be under 3 minutes. 3. easy to list package dependencies quickly 4. auto-install of a package and its dependencies 5. separate package download from install; hence download can proceed in parallel (not really in tinycore, just possible) 6. know what packages are installed quickly and easily 7. easy to remove a package; just remove one file, reboot, it's gone (see 1) *note*: when your system boots in 10 seconds, reboot is not that big a deal 8. no false positive: don't think a package is installed when it is not or is only partially done (due to failure for example) 9. false negatives are ok: if a package is installed but you don't think it is, reinstallation should be cheap 10. No need for continuous tinkering of db or other files to keep it working correctly. 11. Works well in a high latency, even if high bandwidth, network. Which of these goals does replica meet, e.g. for /sys/src? >From my point of view, none of them. Which of these goals does the current contrib system meet? Much as I like the contrib system, it still depends on replica, so, from my point of view, none of the goals are met. I once saw it take four hours to install openssl. That's just not workable. Which of these goals does the gui-based contrib system meet? This is the system that downloads .iso files and then runs replica against them. It meets 3, to some extent, but is still too slow for me; it sort of meets 6; but, unfortunately, it fails on 8. Which of these goals does my extension meet? 2 -- can download/install all of hg, including all dependencies, in 3 minutes, 2 of which are hget 3 -- .1 seconds for 'deps hg'; .1 second for list packages; < .1 second for list installed 4 -- it knows the dependencies and will install everything with one command 5 -- get and install are seperate commands 6 -- ls /installed 8 -- yes -- /installed/ is only created when the package is completely installed (but there are bugs still) 9 -- yes 10. there is little in the way of a db file, just a /installed directory (which you get by a bind -a) 11. It's far faster than existing systems because it uses hget 1. is obviously not yet met. I think it would be worth doing a tiny 9, just as we have tinycore, for terminals. 7. is still not met. Package removal is still a mess. I had hoped to just mount the .iso's and run the tools out of them but have not figured out all the issues yet. A simple rbind failed to do the trick. Here are some examples. # available packages term% time list 4th 8169 82563 9load-e820 9win X11 abaco (etc.) 0.00u 0.00s 0.11rlist # what packages does hg need? term% time deps hg z bz2 openssl python 0.00u 0.00s 0.10rdeps hg #install tiff term% install tiff package is tiff Package z already installed, no need to do it 9660srv 1151: serving /srv/tiff FINIS #install tiff again term% install tiff package is tiff Package z already installed, no need to do it Package tiff already installed, no need to do it FINIS term% Sources to these tools, including the build script, are at http://9grid.net/magic/webls?dir=/rminnich/src/package-tools You can try them out -- it's all there. Packages are in http://9grid.net/magic/webls?dir=/rminnich/src/package I don't pretend the scripts are very good, they just represent a starting point. Experience (mine) is that the system work well. For example, just doing: get openssh install openssh takes very little time and has worked reliably for me on 9vx. And, since I installed hg earlier, openssh install skipped the openssh install step. Left to the reader (or me in a bit): don't download iso when the package is installed! -- but it's so fast I have not bothered. I'm able to install packages now without worrying about whether I will be ready to disconnect my laptop and go home before the install is done! Next step, if this system is found to be useful, is to adapt fgb's gui program. ron
Re: [9fans] iwp9.org (Re: BibTex collections of all 4 proceedings)
On May 14, 2010, at 9:58 PM, EBo wrote: I lived in NM for 8 years, I loved it, still do, but ABQ fails the "transport hub" criterion. I had lots of complaints about that when we had conferences in santa fe. Actually, Santa Fe is a pain to have as a destination for an international conference unless there is a reason to be at the capital or Los Alamos... EBo -- If I thought people would actually come, I would see if I could organize something in Ouray Colorado. It is about 300 miles north of Albuquerque in the San Juan Mountains. You get there by first flying to Denver, Phoenix, or Albuquerque, then catching a puddle-hopper to Montrose and then renting a car or catching a shuttle to go the remaining 35 miles to Ouray. I think it fails the "transport hub" test but it would be equally inconvenient for everyone and the hotel rates are cheap in October. Kim
Re: [9fans] -- in rsc's g script
I don't beleive greps manual page says it writes its output to file descriptor 1 and reaqds from file descriptor zero but it does, as do all conventional (sic) plan9 programs. Similarly they all use arg(2) to parse their args so they will all support --; however if you are unsure you could look at the source, yes. -Steve
Re: [9fans] -- in rsc's g script
> '--' tells the Plan 9 program argument parser to stop looking for > options. See arg(2). so is it a program dependent feature in the sence that I must know which program uses arg(2) and which does not? (E.g that grep uses it but some other command (is there any?) does not?) Must I read the program's source or should it be documented in man pages? -- there is nothing about this in the man page of grep... Thanks Ruda
Re: [9fans] -- in rsc's g script
On Sat, 15 May 2010 15:16:35 +0200 Rudolf Sykora wrote: > could anybody tell me what's the meaning of '--' in > > grep -n $flags -- $1 *.[Cbchm] /dev/null '--' tells the Plan 9 program argument parser to stop looking for options. See arg(2). GNU getopt has the same feature. Robert Ransom
Re: [9fans] -- in rsc's g script
see arg(2) for all the details. -- indicates the end of any options, it ensures that any following arguments which happen to begin with a minus are not interpreted as options. consider the classic question: "how do I remove a file called -z" -Steve
[9fans] -- in rsc's g script
Hello, could anybody tell me what's the meaning of '--' in grep -n $flags -- $1 *.[Cbchm] /dev/null ? This I found in Russ Cox's g script. Thanks Ruda
