Re: [9fans] videos of IWP9 talks
Andrey, thanks a lot for helping to put those together. tim--- Begin Message --- Lucho and I are slowly going through encoding the videos of the IWP9 talks for those who weren't there. To ease the downloading pain we will announce the ones we've already completed for your viewing pleasure, and will let you know when we've added more. The videos are located at: http://9grid.net/IWP9/ They are encoded with H.264, which should play fine in QuickTime and mplayer (using the x.264 ffmpeg decoder). We have raised the highs so human voices (as well as background noise, no way to filter that with the basic tools we have) are most discernible and raised the volume of the video to the maximum allowable. It may still be too quiet for some of you. Best results obtained when you use headphones. Some of the talks will be missing, others will be cut short (acid trips for example). We apologize for the inconvenience. Andrey (and Lucho)--- End Message ---
Re: [9fans] panic
> i think this is realted to recient problems with huge kernels. actually this looks like something different. i never got a panic with the previous issue, the kernel just hung after it was loaded. unless Andrey saw something different
Re: [9fans] VMWare Fusion on the Mac, can't install Plan 9 ....
> in my case commenting out the consinit line does not fix the problem. > i can still load an older kernel in parallels, but crash when > attempting to load a recent one. what kernel? cpu or terminal? if it's cpu build a smaller kernel and try that. i ran into this recently with a pccpuf kernel.
Re: [9fans] o9fs
> I must be confused. Are you writing a 9P driver for OpenBSD? If so, > it's going to run on OpenBSD, and most of us may not be able to help > you. Otherwise, ignore everything I say. obviously he's posting because some of us use OpenBSD on a regular basis along with Plan 9. in that case, this is extremely useful. quit being an ass or go away.
Re: [9fans] consterm
> Has anyone done a term program to connect to Plan 9 or Inferno -- > kinda like drawterm, without the draw bits? I guess I am thinking > about something that exports /dev/cons, /mnt/term, /dev/audio, etc. -- > but then just runs an rc on the other end instead of rio so I can just > run it within an xterm (or whatever). Seems like it would be a useful > thing to have. unless i'm mistaken, Russ started working on a cpu(1) equivalent for plan9ports awhile back... /n/sources/contrib/rsc/cpu.tar.gz % grep cpu /n/sources/contrib/rsc/INDEX cpu.tar.gz: beginnings of cpu for p9p
Re: [9fans] error when booting plan9
> yeah, i've seen it, but didn't found an answer there. try downloading a new iso sunday or monday.
Re: [9fans] error when booting plan9
> i think this is a legit question as changes to 9load were made for today's > iso. considering that 9load is still trying to load via the bios i'd suspect that a new iso was actually not generated today for some reason.
Re: [9fans] error when booting plan9
> i'm getting this error wheb trying to boot plan9 using qemu. > i'm using qemu 0.9.0 and i've downloaded CD Image of plan9 from here: > http://plan9.bell-labs.com/plan9/download.html in the date: nov-2-2007 > > the error is here: http://i4.photobucket.com/albums/y111/Adrielbr/qemu.png > if you cannot see png images, look here: http://rafb.net/p/C1y6sh32.txt > > is there any way to fix it? or is it an qemu error? this has been discussed over the last couple weeks. please check the archives before posting. http://9fans.net/archive
Re: [9fans] new 9load panic
i also just got something similar while attempting to install the new iso within qemu PS1...Plan 9 from Bell Labs ELCR: 0A00 apm ax=f000 cx=f000 dx=f000 di=fff0 dbx=9e22 esi=-f0010 bios0: drive: 0x80: 10737418240 bytes, type 3 biosinit: sorry, only one bios drive; can't read last one dev A0 port 1F0 config 0040 capabilities 0B00 mwdma 0007 udma 203F LLBA sectors 20971520 dev A0 port 170 config 85C0 capabilities 0300 mwdma 0007 udma 203F found partition sdD0!cdboot; 49952+1440 sectread: bios failed to read 512 @ off 1073741822 from 80 biosread: failed to read 512 @ off 549755812864 of 80, want 512 got -1 using sdD0!cdboot!plan9.ini .FLAGS=286 TRAP=e ECODE=0 PC=3f AX 80017fdb BX 80036900 CX 0020 DX 80017f5c SI DI 80017f66 BP 80001250 CS 0010 DS 0008 ES 0008 FS 0008 GS 0008 CR0 8011 CR2 78512900 CR3 c000 panic: exception/interrupt 14 > it is a desktop pc, it has sata but not ahci, the bios is set up as > "enhaced mode" and "sata-only", and have two hard disks (one sata and > one ide) and one cdrom (ide). i can see sdC0 (ide disk), sdC1 (cdrom) > and sdE0 (sata disk). > > i checked again the values and add the lines missing (the PC had a > typo, it is 800017bfa, sorry) > > MBR...PBS1...Plan9 > ELCR: 0C28 > apm: ax f000 cx f000 dx 0x40 > bios0: drive 0x80, 120034123776 bytes, type 3 > bios1: driver 0x81, 160041885696 bytes, type3 > islba: drive f2: no dap extensions > sectread: bios failed to read 512 @ > biosread: failed to read 512got -1 > dev A0 poer 1F0 config 0C5a capabilities 2F00 mwdma 0007 udma 203F > LLBA sectors 234441648 > dev B0 port 1F0 config 85C0 capabilities 0F00 mwdma 007 udm 101F > sectread: bios failed to read 512 @ off 0 from 80 > biosread: failed to read 512 @ off 0 of 80, want 512 got -1 > sectread: bios failed to read 512 @ off 1073741822 from 80 > biosread: failed to read 512 @ off 549755812864 of 80, want 512 got -1 > using: sdC0!9fat!plan9.ini > .FLAGS 10292 TRAP e ECODE 2 PC 800017bfa > AX acf08123 BX 80061a99 CX 800711d8 DX 003d > SI DI 80001377 BP 80001250 > CS 0010 DS 0008 ES 0008 FS 0008 GS 0008 > CR0 8011 CR2 acf08123 CR3 c000 > panic: exception interrupt 14
Re: [9fans] drawterm authentication failure
> * Tim Wiess ([EMAIL PROTECTED]) wrote: >> for P9P factotum make sure you have the relevant entries >> in $PLAN9/ndb/local. > > That did it. Mordor worked, obviously, because the entry is already there by > default. Embarrassing, isn't it? great. some of the references in the man page need to be updated to reflect the P9P environment vs straight Plan 9, but the text for -a pretty much explains it.
Re: [9fans] drawterm authentication failure
> I'm fairly certain that factotum is only started once. As I wrote before, > connecting to mordor works, so it seems I'm experiencing some peculiarity of > my plan 9 server that apparrently exhibits some subtle difference between > cpu and drawterm. Perhaps I should just step back a little. Not running > factotum is a workaround, but i have the feeling that ignoring the issue > will come around some day and bite me. for P9P factotum make sure you have the relevant entries in $PLAN9/ndb/local.
Re: [9fans] dns ptr records.
delayed response, but thanks for letting everyone know > thanks to geoff for pointing me in the correct direction. > > the rfc in question is rfc 2317. i'll outline what's required, > since it wasn't obvious to me. > > here's an example setting up t2317 ptr records for 65.14.39.130 and > 65.14.39.131 in the network 64.14.39.128/123. > > # first we have to have the correct ipnet setup. > # dns needs this information to find the netmask. > > ipnet=coraidt1 ip=65.14.39.128 ipmask=/123 > # other stuff you may need goes here. > > # next we need to declare our dom. dns normally does this > # for us, but for 2317-style reverse lookups, we do it ourselves. > > dom=128.39.14.65.in-addr.arpa soa= > refresh=3600 ttl=3600 > ns=ns1.coraid.com > ns=ns2.coraid.com > > # and the entries. > dom=130.128.39.14.65.in-addr.arpa > dom=131.128.39.14.65.in-addr.arpa > > - erik
Re: [9fans] Replica "auth protocol"
Geoff, I've had a user account on sources for a long time but have never created a contrib dir. However I still intend to do so for some work I have in the queue. What is the process of creating new accounts now? Tim > Sorry, I forgot to mention here that we've removed all accounts from > sources except those of people who have contrib directories and the > usual pseudo accounts and administrators. > > So you'll probably want to modify 9fs to mount sources with srv -n > unless you have a contrib directory.
Re: [9fans] Mips kernel
> While it is cool to keep old dead hardware going, I wish I could > entice you folks to look at embedded boards with the 4-core mips chip. > Same processor as in sicortex. Much more useful to the world at large. yeah, these are the types of chips i'm hoping to work on later. if anybody has any extra dev boards for a multi-core mips chip they want to donate to the cause let me know... :)
Re: [9fans] Mips kernel
> Don't the linksys routers run on MIPSel's. I don't know if little endian > MIPS is interesting to you though. i'm just focusing on the eb stuff right now. although i think somebody worked on a linksys port previously.
Re: [9fans] Mips kernel
> in case you are still wanting to hack on the SGI's, i can test it on an o2 > r5k. thanks. i currently porting to an Origin 200 and Indigo2 r10k. i'd like to get it running on an O2 as well.
Re: [9fans] Mips kernel
> Somone was working on a new 64bit port I believe but I guess that stalled > (it has gone very quiet). yeah unfortunately it is stalled again. however i'm taking some vacation time in the next couple weeks and this is at the top of my list of projects to work on. this initial port has always been targeted at SGI's systems but when i'm through with that i'm planning to migrate it over to some embedded platforms. i've been looking at possible candidates lately, but i'd love to get suggestions from others in case there's a nice one that i've missed. tim
Re: [9fans] Plan9 unknown people
when i first saw that image a couple years ago i wondered what type of keyboard that was in front of Dorward. i think i recall seeing the same type in some other lab pictures too. does anybody know? >> I found an old Plan9 photo at : >> http://cm.bell-labs.com/cm/cs/who/dmr/pix/Plan9-1995.gif >> >> Could anyone put names on it >> ( I already recognize Ritchie and Pike ;-) )? > > Foreground (from left): Dennis Ritchie, Dave Presotto, Rob Pike. > > Background (from left): Tom Killian, Allen Eisdorfer, Tom Duff, Phil > Winterbottom, Jim McKie, Howard Trickey and Sean Dorward.
Re: [9fans] Colors and other fun
> Vim ships with a file quotes.txt containing testimonials. This is my > favorite: > > I typed :set all and the screen FILLED up with options. A whole screen of > things to be set and unset. I saw some of my old friends like wrapmargin, > modelines and showmode, but the screen was FILLED with new friends! I love > them all! I love VIM! I'm so happy that I've found this editor! I feel > like how I once felt when I started using vi after a couple of years of > using > ed. I never thought I'd forsake my beloved ed, but vi ... oh god, vi was > great. And now, VIM. (Peter Jay Salzman, USA) heh... nice.
Re: [9fans] Anyone else see this?
> http://slashdot.org/comments.pl?sid=238941&threshold=1&commentsort=0&mode=thread&cid=19566827 who cares? it's slashdot.
Re: [9fans] Re: CA Bay Area Plan9 users group
> And thank *you* for giving such an excellent talk! The meeting was a huge > success and we'll look forward to hosting you all again in the future. i didn't even realize that video con was an option for those close to a branch office. i'll be there next time
Re: [9fans] speaking of kenc
fascinating. could you please continue this thread off the list now? thanks. > Roman Shaposhnik wrote: >> On Sun, 2007-05-06 at 07:12 +0200, [EMAIL PROTECTED] wrote: assembler is there because it is needed. if you are writing or porting a compiler and you dont have an assembler you will end up writing one anyway. >>> Assembler is there because the designers _make_ it necessary. >> >> I think I would agree with this point 100%. >> >> Thanks, >> Roman. >> >> > > Designers work in binary gate-array state tables. > > Not much choice until CPU go over to optical, and can *maybe* use UTF-8 > directly > as I/O in color frequency coding as well as simple on/off states. > > Even then only at a hefty price. > > Until then, asm's mnemonics are easier for humans to work with than octal, > hex, > or binary, and there isn't much to be done about that IF/AS/WHEN you > absolutely, > positively, *have to* get down to the lowest possible layer and find a > binary-only animal at that layer. > > Fortunately, that 'have to' is 'damn seldom' thanks to a wide variety of > toolsets, and those who do it often are no more fussed about doing it than > having a different brand of beer now and then. > > Build a CPU that 'needs no assembler' and the first thing that happens is > some > contrarian will write one for it *anyway*. And/OR port forth to it. > > And they will be used. But never 'forced'. > > That because the second contrarian who arrives will port a 'C' compiler to it. > > Any of these can be labelled ugly or inelegant - but they are the tools that > get > the job done faster than most other choices. > > And time - wall clock, CPU, or hours of our lives - is not just money. > > Time is the scarcest, and least 'renewable' resource any of us will ever have. > > So we must adapt to what we have while we invent better machines. > > When machines start to adapt to US, we should become very, very wary, 'coz > they > will have become smarter than we are, and they will also have become either > certifiably insane to make the attempt or clever liars to fake it. > > Can't trust either of those to keep a beer keg cold... > > Choices, folks. Choices! > > Bill
Re: [9fans] Seattle Area Plan9 Users Group
> i'm thinking it should be on Wednesday May 9th ☺ works for me.
Re: [9fans] Seattle Area Plan9 Users Group
> anyone interested? perhaps someplace downtown? yeah, i was going to suggest this myself.
Re: [9fans] speaking of kenc
> good point. except, dennis was mostly ignored. > why should mortals expect different results? perhaps we just need to speak lounder.
Re: [9fans] ipv6
Geoff, Thanks! I'm using v6 quite a bit on my network, so I'll cetainly be testing these changes. Tim > Over the last two days I've pushed out a new ipconfig, some small > utilities, and changes to the kernel and manual pages. ipconfig(8) is > a good place to start. ipconfig is now able to configure more of the > ipv6 stack, in particular automatically configuring the link-local > address and enabling sending or receiving of router advertisements. > > I haven't been able to test the IPv6 functionality very thoroughly > here, though it does seem to work at least minimally. Feedback on the > new ipconfig from people who are using IPv6 is welcomed. > > The ipv6 attribute is now documented in ndb(6), but the trade-off > between just using an ip attribute with an IPv6 address and using the > ipv6 attribute is not yet obvious to me. > > One thing we don't have yet is DHCPv6. The sheer size of the stack of > paper that is the DHCPv6 RFCs is daunting.
Re: [9fans] non-PC hardware
fwiw i've had a 64-bit mips port in the works. it was stalled many, many months ago due to the lack of spare cycles i had at the time. however i'm really hoping to pick it back up in the next coming weeks. most of the toolchain is working and some of the kernel parts are there. i absolutely do plan on continuing this, so i'll keep 9fans posted as soon as i'm back on track with it. tim > On 3/27/07, ron minnich <[EMAIL PROTECTED]> wrote: >> arm >> ppc >> x86_64 >> >> not a bad choice, what else would you want to run on? >> >> thanks >> >> ron >> > > mips
Re: [9fans] non-PC hardware
> 2007/3/28, Lawrence E. Bakst <[EMAIL PROTECTED]>: >> Sparc is Sun only, > > Isn't www.opensparc.net good for new manufacturers and uses of sparc > processors? In fact I don't know if someone other than Sun plans > building such processors or variants. Fujitsu has some nice ultrasparc systems.
Re: [9fans] Resizing acme tags in plan9
> I also find SAM's remote editing ability very convenient, but in ACME > it may be better to implement this by separating the filesystem from > the editing commands so that remote editing can be done by applying > instructions to a remote ACME fileserver. Not that I know what I'm > talking about, but it seems an option from a distance. i've been thinking about this a lot lately and am planning on really starting to look into now as a little more free time has come up. i always thought about making the changes in the filesystem. to be able to have certain windows (fs directories) bound to local files and others bound to remote files. reads/writes on the latter would be translated to a sam-like protocol and sent to the other host. your first remote window could be started with something like 'New hostname', which would bring up a directory window. tim
Re: [9fans] IWP9 talks?
> In spring/summer you can't beat Seattle/Vancouver area. Agreed. I was going to try and set something up here in Seattle if those other proposals don't work out.
Re: [9fans] Newbie question
> My question was if it's possible to use plan9 without rio, like other > unixes. plan9 isn't unix.
Re: [9fans] keyboard problems after aux/vga
got some more time today to get back to this... it turned out that the problem was that the PIT had just stopped counting, after vga went into realmode when writing to /dev/realmode. so all of the timers keyed off of timerintr were not being triggered, such as the keyboard, uart and mouse cursor timers. i don't have any docs on the machine's southbridge (VT8235) to determine if there is something special that needs to be done in this case, but manually reinitializing the PIT after coming back from realmode does fix the problem. i'll keep investigating any other thoughts/suggestions appreciated. tim
Re: [9fans] keyboard problems after aux/vga
> vesa is tough. the first thing i would check is if X11 runs in vesa mode > under linux on this machine. > > if vesa memory isn't where the driver expects or is a different size, you are > likely to overwrite something important. are you trying the lowest vesa > resolution? i've tried a variety of resolutions with the same results. i'll try X/vesa and see what happens
[9fans] keyboard problems after aux/vga
9fans, i recently swapped my old terminal out for a small VIA EPIA M1000 based system. everything's working well when i boot straight up into rc, but as soon as i start vga (vesa mode) the system stops receiving keyboard input. i'm trying to track this down right now, but i'm not too familiar with VBE so i thought i'd solicit any suggestions from the group first. is there any reason that touching the VBE registers would cause this? there's no mouse cursor either, but that may be a seperate issue. i know others have run P9 on EPIA systems successfully, so this could all be the result something funky with my setup thanks. tim
Re: [9fans] undefined reference to `sched_yield'
btw, if you don't want to wait, just change the version number in the OpenBSD check in src/lib9/sleep.c to 200611. if you run -current though, you shouldn't need to change anything. > OpenBSD 4.0 running in QEmu 0.8.2 on FreeBSD 6.0 > > > # cd /usr/local/plan9 > # ./INSTALL > * Resetting /usr/local/plan9/config > * Building everything (be patient)... > >>> cd /usr/local/plan9/src/cmd; mk all > 9l -o o.9p 9p.o > /usr/local/plan9/src/lib9/sleep.c:25: undefined reference to `sched_yield' > collect2: ld returned 1 exit status > mk: 9l -o o.9p ... : exit status=exit(1) > mk: for i in ... : exit status=exit(1) > # > > MD5 (plan9port.tgz) = e6aba1ebf35fe0407304069dd1ea35c8
Re: [9fans] undefined reference to `sched_yield'
this is my fault. the developers added a real sched_yield in 3.9 but was not built into the kernel by default. i assumed it would be for 4.0, but they just turned it on only after the release. i'll send a patch over to Russ which will fix this for 4.0 systems. sorry about that. tim > OpenBSD 4.0 running in QEmu 0.8.2 on FreeBSD 6.0 > > > # cd /usr/local/plan9 > # ./INSTALL > * Resetting /usr/local/plan9/config > * Building everything (be patient)... > >>> cd /usr/local/plan9/src/cmd; mk all > 9l -o o.9p 9p.o > /usr/local/plan9/src/lib9/sleep.c:25: undefined reference to `sched_yield' > collect2: ld returned 1 exit status > mk: 9l -o o.9p ... : exit status=exit(1) > mk: for i in ... : exit status=exit(1) > # > > MD5 (plan9port.tgz) = e6aba1ebf35fe0407304069dd1ea35c8
Re: [9fans] Anyone to try to convert Acme to full UI (w/graphics)
> portable or not it's in the p9p version it is not in the plan9 version. i don't think portability was the issue. there are a couple bugs in the implementation and last time i talked about it with Russ, he wanted to wait until those were resolved before merging the changes in P9.
Re: [9fans] Binit and Bterm
> So will Binit properly reinitialize its argument, reusing the buffers > rather than allocating new ones and leaking the old? yes the buffer will be reinitialized, but as Russ said, it is not dynamically allocated.
Re: [9fans] Binit and Bterm
since you are just doing reads then no i don't believe
the Bterm is necessary.
> I’ve got a function in the Brain-Dead SHell™ that I’m writing for
> homework that looks like this:
> Biobuf in;
>
> void bdsh(int f) {
> Binit(&in, f, OREAD); yyparse(); Bterm(&in);
> }
> This function gets called for each file named in argv[] after main()
> open(2)s it.
>
> My question is: is the call Bterm necessary, or will Binit
> reinitialize the global Biobuf correctly on its own—or am I courting
> trouble some other way? The man page for bio(2) is a bit vauge on
> reusing Biobufs.
>
> --Joel
Re: [9fans] Aquarela usage
> anyone actually exporting nfs from plan 9 to linux? > Or are you all using the linux 9p implementation? my file server has always been exported via nfs to the openbsd systems on my network. never had any problems.
Re: [9fans] Venti on OpenBSD
could you send me a stack trace from the core? tim > Hello all, > > I have given up on using raw partions and am trying regular files as > discussed > in http://archive.netbsd.se/?ml=Plan9-9fans&a=2005-12&t=1586319. > > Now I am getting a segmentation violation: > > sara# cd /venti > sara# dd if=/dev/zero of=dvd_00 seek=4966055935 bs=1 count=1 > sara# 9 rc > % ls -l dvd_00 > --rw-r--r-- M 0 root wheel 4966055936 Jul 26 11:45 dvd_00 > % venti/fmtarenas -a 128m isi dvd_00 > part dvd_00: file dvd_00 offset 0 size 4,966,055,936 > 24824: signal: sys: segmentation violation > > Is this a problem with OpenBSD or am I missing something? > > Thanks, > Henry > > On Monday, July 24 2006 02:12 pm, Henry Baragar wrote: > [stuff deleted] >
Re: [9fans] pbcopy/pbpaste like functionality for snarf/paste buffers
cat /dev/snarf > One of my favorite things about Mac OS X is that the clipboard buffer > can be accessed in two ways from the command line. > > For example I use an application for taking meeting notes that just > lets me plot out an outline then export it in an XML format. I throw > it through a sed/awk script (because who the hell wants to mess with > XSLT unless they have to?) which dumps out a simplified wiki syntax > version for posting meeting minutes to an internal page. > > I can just do "notes-to-wiki.sh somefile.xml | pbcopy" > > Likewise I've been known to grab stuff off of a page and then pass it > through some filters. > > Copy stuff to the clipboard buffer then do. > > "pbpaste | filter-scripts" > > Etc. > > Is there equivalent technology for Plan 9/Rio? How hard would this be to add. > > Is it already somewhere in my Rio fileystem. Don't have access to my > plan 9 box at the moment. > > I hope it's not terribly simple :-)
Re: [9fans] Install from CD fails
wow... that's pretty insane. > you're getting way too fancy. /bin/date anyone? > > sh-3.00$ export LD_KDEBUG=all > sh-3.00$ date > 515: > 515: file=librt.so.1 [0]; needed by date [0] > 515: find library=librt.so.1 [0]; searching > 515: search cache=/etc/ld.so.cache > 515:trying file=/lib/librt.so.1 > 515: > 515: file=librt.so.1 [0]; generating link map > 515:dynamic: 0x44d35ebc base: 0x size: 0x00013ef8 > 515: entry: 0x44d2f060 phdr: 0x44d2d034 phnum: 9 > 515: > 515: > 515: file=libc.so.6 [0]; needed by date [0] > 515: find library=libc.so.6 [0]; searching > 515: search cache=/etc/ld.so.cache > 515:trying file=/lib/libc.so.6 > 515: > 515: file=libc.so.6 [0]; generating link map > 515:dynamic: 0x4423fd3c base: 0x size: 0x00128bdc > 515: entry: 0x4412feaa phdr: 0x4411b034 phnum: 10 > 515: > 515: > 515: file=libpthread.so.0 [0]; needed by /lib/librt.so.1 [0] > 515: find library=libpthread.so.0 [0]; searching > 515: search cache=/etc/ld.so.cache > 515:trying file=/lib/libpthread.so.0 > 515: > 515: file=libpthread.so.0 [0]; generating link map > 515:dynamic: 0x4436ced0 base: 0x size: 0x000111c4 > 515: entry: 0x44362804 phdr: 0x4435e034 phnum: 9 > 515: > 515: checking for version `GLIBC_2.2' in file /lib/librt.so.1 > [0] required by file date [0] > 515: checking for version `GLIBC_2.1.3' in file /lib/libc.so.6 > [0] required by file date [0] > 515: checking for version `GLIBC_2.3.4' in file /lib/libc.so.6 > [0] required by file date [0] > 515: checking for version `GLIBC_2.1' in file /lib/libc.so.6 [0] > required by file date [0] > 515: checking for version `GLIBC_2.3' in file /lib/libc.so.6 [0] > required by file date [0] > 515: checking for version `GLIBC_2.2' in file /lib/libc.so.6 [0] > required by file date [0] > 515: checking for version `GLIBC_2.0' in file /lib/libc.so.6 [0] > required by file date [0] > 515: checking for version `GLIBC_PRIVATE' in file > /lib/ld-linux.so.2 [0] required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_2.2' in file > /lib/libpthread.so.0 [0] required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_2.3.3' in file > /lib/libpthread.so.0 [0] required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_2.1' in file > /lib/libpthread.so.0 [0] required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_2.0' in file > /lib/libpthread.so.0 [0] required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_PRIVATE' in file > /lib/libpthread.so.0 [0] required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_2.1.3' in file /lib/libc.so.6 > [0] required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_2.2' in file /lib/libc.so.6 [0] > required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_2.0' in file /lib/libc.so.6 [0] > required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_2.1' in file /lib/libc.so.6 [0] > required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_2.3.2' in file /lib/libc.so.6 > [0] required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_PRIVATE' in file /lib/libc.so.6 > [0] required by file /lib/librt.so.1 [0] > 515: checking for version `GLIBC_2.1' in file /lib/ld-linux.so.2 > [0] required by file /lib/libc.so.6 [0] > 515: checking for version `GLIBC_2.3' in file /lib/ld-linux.so.2 > [0] required by file /lib/libc.so.6 [0] > 515: checking for version `GLIBC_PRIVATE' in file > /lib/ld-linux.so.2 [0] required by file /lib/libc.so.6 [0] > 515: checking for version `GLIBC_2.1' in file /lib/ld-linux.so.2 > [0] required by file /lib/libpthread.so.0 [0] > 515: checking for version `GLIBC_PRIVATE' in file > /lib/ld-linux.so.2 [0] required by file /lib/libpthread.so.0 [0] > 515: checking for version `GLIBC_2.1.3' in file /lib/libc.so.6 > [0] required by file /lib/libpthread.so.0 [0] > 515: checking for version `GLIBC_2.3.2' in file /lib/libc.so.6 > [0] required by file /lib/libpthread.so.0 [0] > 515: checking for version `GLIBC_2.0' in file /lib/libc.so.6 [0] > required by file /lib/libpthread.so.0 [0] > 515: checking for version `GLIBC_2.2' in file /lib/libc.so.6 [0] > required by file /lib/libpthread.so.0 [0] > 515: checking for version `GLIBC_2.1' in file /lib/libc.so.6 [0] > required by file /lib/libpthread.so.0 [0] > 515: checking for version `GL
Re: [9fans] Google Summer of Code
> Google - sending the software world back to the stone age. > > My 2Ghz 1Gb RAM workstation struggles to allow me to read email with > gmail... amazing how far backwards we can go! i think your workstation has some serious unrelated issues. a pII 450 i have can load gmail just fine. funny how you continue to trash google, but yet you clearly use their services.
Re: [9fans] v9fs and Russ tra
> you could make it available on a web page (somewhere) for people to see :-) i certainly will once it's in a state for people to see. :) i need some more time to wrap up a few things before then.
Re: [9fans] v9fs and Russ tra
> i have an OpenBSD port in progress. it is currently stalled due to lack > of time. but once finished, the code could certainly be reused to > build ports for (Net|Free)BSD. sorry, need to read what i type. i didn't mean to imply that it was a v9fs port. the code was written from scratch.
Re: [9fans] v9fs and Russ tra
>> How uptodate is the *BSD support? In particular how well is >> FreeBSD supported? > > the freebsd support only ever reached the LD_PRELOAD stage. I started a > vfs (see my web page) but never got it done. Not even the BSD guys liked > the private namespace ideas back then, so there was not a lot of incentive. > > You'll be starting from a clean sheet ... > > ron i have an OpenBSD port in progress. it is currently stalled due to lack of time. but once finished, the code could certainly be reused to build ports for (Net|Free)BSD.
Re: [9fans] ttf2subf
> i've been working with code2000, which looks hideous in mono mode, but > is pretty readable subpixel or antialias mode, but ttf2subf is too > agressive in its antialiasing and does not snap near-grid vertical or > horizontal lines to the grid. i've noticed this too when playing with verdana. it's still usuable but can get annoying with certain bodies of text.
Re: [9fans] ports from GPL
> their major mistake, apart from not thinking before coding, is that > all of those stupid inlines blow your cache and ken is clever. this is very true. i'm always amazed to see how often that keyword is abused these days.
Re: [9fans] kernels
i don't use Linux much, but on BSD and other Unix systems this is actually quite normal. and it's done for many of the same reasons Russ mentioned.
Re: [9fans] amd64 support in p9p?
on OpenBSD you'll need to copy over rfork_thread and roll
your own {get,set}context functions. however as Russ mentioned,
you don't really need to use OpenBSD's ucontext_t (sigcontext)
for this.
tim
> Hi all,
> is there anybody interested in helping to port the
> plan9 from user space to amd64/x86_64?
> The most platform dependend code seems to be the libthread
> stuff. On OpenBSD-amd64 I can borrow an assembler version of
> rfork_thread from the OpenBSD librthread and can improvise
> the _tas function. The get/setmcontext pose a problem because
> I do not know if struct ucontext must really be exactly the same
> as struct sigcontext.
>
> Best regards,
>
> Matthias
Re: [9fans] acme + mh
> i have been using upas pretty much fulltime on p9p. > although the porting work isn't very presentable, > faces, plumber, acme/mail, upas/^(alias fs marshal ned send smtp) > do work well enough to get by. that's great to hear. nice job on the work done so far. if i have some time this weekend i'd like to start playing with what's there.
Re: [9fans] acme + mh
> can you cat /mail/fs/mbox/113/subject? > > On Mon Feb 6 10:32:25 CST 2006, [EMAIL PROTECTED] wrote: >> >> i've always used mh for mail on unix. i like it, as it gives you >> many of the same benefits to having a fs interface to your mail >> that upas/fs does. >> >> tim no and i wasn't suggesting that mh is capable of providing as a rich an interface as upas/fs. just that it is what i prefer when i can't use upas/fs, since people were asking. and Russ was wondering if he was the only one around here using it. :)
Re: [9fans] acme + mh
> I don't know that anyone is using the mh Mail program > but me, but I'm happy with it. I made a few changes > and bug fixes - http://swtch.com/Mail. The major > drawback is that using mh commits you to one machine, > unless you do some clever synchronization behind > the scenes. I've been carrying my laptop around just to > read mail, which I hadn't done in years. Anyway, I think > that the Mail+mh was a useful experiment but is not > a good long-term solution. i've always used mh for mail on unix. i like it, as it gives you many of the same benefits to having a fs interface to your mail that upas/fs does. tim
Re: [9fans] new web site
Russ, i think the new site looks great. i find it much easier to navigate through. > The HTML versions of the papers also look much better on screen. > For example: > > http://plan9.bell-labs.com/sys/doc/auth.html truely. i think those pages really demonstrate the usefulness of a program like htmlroff.
Re: [9fans] acme mail on unix
oops, sorry for the noise, didn't mean to send this to the list. > Russ, > This is great! I am very eager to try this out. > However I didn't get the Mail script you attached. It just > came through as an empty file. Would you mind sending that > again? > > tim > > > > I am sending this from inside acme Mail on Linux. > > Or at least the program is called Mail. > > It's not actually the Mail from Plan 9. > > > > I am running mh and have 'customized' it to print > > something close to sensible output. Mail itself > > is a shell script. The interactive delay is a little > > annoying sometimes, you have to run inc and Get > > to check for new mail, and the script itself needs > > to be cleaned up, but it's still entirely usable. > > > > I have attached my .mh_profile, Mail/mhl.format, > > Mail/mhl.headers, and the Mail script itself. > > > > Russ
Re: [9fans] acme mail on unix
Russ, This is great! I am very eager to try this out. However I didn't get the Mail script you attached. It just came through as an empty file. Would you mind sending that again? tim > I am sending this from inside acme Mail on Linux. > Or at least the program is called Mail. > It's not actually the Mail from Plan 9. > > I am running mh and have 'customized' it to print > something close to sensible output. Mail itself > is a shell script. The interactive delay is a little > annoying sometimes, you have to run inc and Get > to check for new mail, and the script itself needs > to be cleaned up, but it's still entirely usable. > > I have attached my .mh_profile, Mail/mhl.format, > Mail/mhl.headers, and the Mail script itself. > > Russ
Re: [9fans] 9con in Madrid?
I am not absolutely positive that I'll be able to attend, however if I can I'd be happy to talk on issues related to some of the projects I'm currently working on. - 64-bit MIPS port & VM enhancments - new packet filter - 9P for OpenBSD I'm eventually planning on putting some material together to describe the process of porting Plan 9 to new architectures. This would be something I'd be happy to present at 9con. Just some thoughts... Let me know how things progress. Tim > Ok. Send me a mail those who would go/give conferences on the 5, 6, 7. > Unless there is (strong) opposition, this is the date. Some funding > for travelling > may be considered if someone is giving an interesting enough conference. > > > On 11/30/05, Dave Lukes <[EMAIL PROTECTED]> wrote: >> Well, my birthday's on the 16th, so I'm biased:-). >> >> Uriel wrote: >> >> >So, can we agree on a date? Apparently May seems the most convenient for >> >most people, what about the 5,6,7 or the 12,13,14? >> > >> >On Tue, Nov 22, 2005 at 09:55:53AM -0700, Ronald G Minnich wrote: >> > >> > >> >>I've done these sorts of programs before if you want help, or you just >> >>want it done (I'm going to regret this). I think 2.5 days might do it. >> >>What we used to do for extreme linux is have 90 minute sessions, heavy >> >>on discussion. So you have three 20 minute talks, 30 minutes of >> >>discussion of the material presented. You do this four times a day. You >> >>can mix it up -- have sessions with 3 30-minute talks if you can find it. >> >> >> >> >> >This sounds like a good plan. >> > >> > >> > >> >>Then you pick the broad areas in which to have the discussion. >> >> >> >> >> >My suggestions for broad areas(I'm biased, so pleas make more >> >suggestions): >> > >> >Plan 9 development status, current projects. >> >Plan 9 future development plans and goals. >> >Tech transfer to other systems(p9p, v9fs, ...) >> >Inferno/Limbo >> >9grid and other global infrastructure >> >Development process. >> > >> >uriel >> > >> > >> >> > > > -- > - curiosity sKilled the cat
Re: [9fans] drawterm
> i just downloaded it. ran it under fc4 and it drops core.
> now, if i can just find out where they put the core file!!
I noticed that it seg faults when you don't specify an auth server. Due
to a null dereference in netmkaddr(authserver, "tcp", "567") from
authdial().
I added the patch below to fix it as well as provide support for $auth.
Index: cpu.c
===
RCS file: /cvs/drawterm/cpu.c,v
retrieving revision 1.3
diff -u -r1.3 cpu.c
--- cpu.c 4 Nov 2005 17:06:57 - 1.3
+++ cpu.c 4 Nov 2005 22:59:48 -
@@ -181,6 +181,12 @@
fatal(0, "set $cpu");
system = p;
}
+ if(authserver == nil) {
+ p = getenv("auth");
+ if(p == 0)
+ fatal(0, "set $auth");
+ authserver = p;
+ }
if(err = rexcall(&data, system, srvname))
fatal(1, "%s: %s", err, system);
Re: [9fans] VESA ISO Changes?
> The vesa code will be included with the new VM changes, which > should appear within a week or so. Just out of curiosity, what type of changes are you incorporating? Are they just machine specific (x86) changes or have you been working on the mi part of the VM as well?
Re: [9fans] First-timer help
> I've already read through the wiki. I did run newuser after I manager > to login as my new user. However, I still cannot set any passwords, so > logging in is kinda insecure. The user authentication methods used in P9 are a little different than unix. Read up on keyfs(4) and factotum(4). Basically P9 was designed to have terminals authenticate themselves to a separate CPU or authentication server. > And why do you have to reboot in order to change users? UNIX has had > that from the beginning, and I don't see any reason to drop it. Again P9's an entirly different system. There are many similarities with Unix, but there are far more differences. And thinking in terms of Unix when dealing with P9 will most likely just lead to frustration and confusion. It may take a little time to get over the hurdle of adapting to a new environment, but your paitence and efforts will be rewarded many times over. If you haven't already, start reading the docs in /sys/doc or http://www.cs.bell-labs.com/sys/doc/
