Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook
tim weiss started work on kencc mips64 port and I started (w/o the compiler) playing with Plan 9 on mips64 based on the old carrera port. the stupid initial code is at http://src.oitobits.net/9sgi On Thu, Mar 19, 2009 at 8:24 PM, ron minnich wrote: > On Thu, Mar 19, 2009 at 4:14 PM, Anthony Sorace wrote: >> i was looking at this a week or two ago, trying to find an ARM or MIPS >> laptop to play with. my first question was whether the "missing" parts >> of the MIPS instruction set are things that our compilers currently >> generate; SoC (oh, and my day job) ramped up before i could find the >> list of missing instructions. any idea? >> >> getting quotes or delivery in the US seemed tricky, too. > > so, here's a silghtly controversial (maybe) suggestion. Maybe my > memory is wrong, but i believe the vx32 kernel is gcc-compiled. There > is gcc for this CPU. It might be easier to start from the vx32 kernel > and gcc to target this machine, rather than do a 64-bit MIPS port of > the plan 9 C compiler. Or not: a few of the folks on this list could > probably retarget in very short order (I'm not one of the,however). > > ron > > -- iru
Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook
On Fri, Mar 20, 2009 at 12:15 PM, erik quanstrom wrote: > wouldn't it just be easier to use 32-bit compatability mode > (http://www.mips.com/products/processors/architectures/mips64/) > for bootstrapping using vc? that's how i started playing. iru
Re: [9fans] Security, take 2.
On Fri, Apr 17, 2009 at 2:43 PM, Devon H. O'Dell wrote:
> Given the feedback from the list, I've come up with two alternatives.
> (Well, one of them was actually Mechiel's brainchild).
>
> Idea #1 (From Mechiel)
> Instead of doing typed allocations, give every user an allocation
> pool, from which all kernel allocations will take place. To extend on
> this, the size of the pool is somewhat dynamic -- as new users log in,
> all users' ability to consume kernel resources goes down by a fair
> percentage. (Except for eve.) As users log out, all users gain the
> percentage of resources back. The number is based on a 90% resource
> allocation -- i.e. the kernel may keep 10% of its initial resources
> for things it needs to do all by itself, without users interfering.
> When a malloc occurs with up, that size is stored in a counter. The
> proc also holds per-proc information, so that a username change can
> intelligently move only the resources from that proc over to the new
> user, instead of everything from the old user (which is clearly
> wrong).
>
> This implementation has one magic number: 0.9. The fair share is
> percentage based from that, but I'm not experience in fair share
> algorithms, so maybe there's a better way to do that. Also, the
> security of this implementation is provable.
>
> Downside is that this implementation is somewhat intrusive:
> introducing 9/port/kreslimit.c and touching 9/port/portdat.h,
> 9/port/portfns.h, 9/port/alloc.c, 9/port/proc.c, and 9/port/devcap.c
>
> I only have one question about implementation: where in process
> creation is the process username set? In newproc(), I see p->user set
> to "*nouser"; I can only assume this is `fixed' later, but I don't
> know where. I ask, because for natively started processes (i.e. not a
> user logging in from drawterm, that's handled through devcap), I need
> to incref on the proc structure that holds the user's pool info. I
> know I need to do this in e.g. #c/user, and devcap. But when a user
> starts a new process after logging in, it needs to add a ref. Where in
> proc.c (or elsewhere) is it finally determined who the user is? (Is
> that in renameuser()? I wasn't sure).
>
> Idea #2
> Implement a similar thing as mult.bsd.lv. This would be implemented as
> a device and would give you a `blank' Plan 9 system:
> echo {cpushare} {maxmem} {newroot} > /dev/virtual/new
>
> I haven't thought a whole lot about how this would work, but I'm
> guessing at least the maxmem would be implemented similarly, by
> creating a new pool. I'd have to learn more about the scheduler to do
> the CPU limiting, and newroot would be as easy as a bind(). This would
> also be somewhat intrusive (but maybe not more so than Kreslimit), but
> has hard values, and provable security. (And the advantage of being
> able to spawn `new' Plan 9 instances from Plan 9.) More like jail(8)
> in FreeBSD (but much cleaner, due to its provability), less like
> vkernel(8) in DragonFly BSD.
>
> --dho
>
>
you may want to take a look at Solaris Zones:
http://opensolaris.org/os/community/zones/
iru
Re: [9fans] off-topic: "small is beautiful" article
On Thu, Jun 25, 2009 at 1:42 PM, John Floren wrote: > TinyScheme has been in contrib for a long time, but I don't know its > limitations or how it would stack up against 'ChibiScheme' > > John Alex (the article's author) mentions it at http://groups.google.com/group/plan9-gsoc/browse_thread/thread/885367b29bb79b43/3df41742786f88d6?lnk=gst&q=tinyscheme#3df41742786f88d6 iru
Re: [9fans] Question about Plan9 project
it is so difficult to 'fork' the project that it took me less than 10 minutes to turn the kernel sources into a hg repository. On Sat, Jul 18, 2009 at 2:59 PM, ron minnich wrote: > On Sat, Jul 18, 2009 at 9:59 AM, Uriel wrote: > >> Plan 9 is *not* an open source project, it can hardly be called a >> project even: There is no release management, there is no development >> process, there is no way to know what anyone is working on, no way to >> have any idea of what changes and features to expect in the future or >> when, or when any given bug might be fixed, or even a bug database for >> that matter, > > > This is an interesting statement and should be revised. So let's correct it. > > Take that above text and add this, please: > "That is visible to Uriel, or that will ever be visible to Uriel, or > that Uriel has any possibility of influencing, given that Uriel has > burned every last bridge he might have ever had with the Plan 9 > developers to the ground.". > >> So you are on your own, you can take the code (while the site happens >> to be up, or from a mirror), do whatever you like with it, but that is >> all there is and all anyone can count on. > > So, let's revise this one too.. > > "I, Uriel, taking up Noah Evans offer, will be forking the code base > and releasing an OS called Plan-U. I will provide servers that resolve > all the problems seen with the bell labs server, and I will take on > the task, with my friends, of providing all the things I see lacking > in the current setup. It's much easier to contribute a solution than > complain, and I am not the type who gets perverse joy out of just > complaining and yelling at people on a mailing list. That game is for > losers. Rather, I wish to provide a constructive solution, and I know > that after a few months people will ignore the bell labs site and > flock to mine. It worked for openbsd, and it can work for Plan U. As > part of this effort, I hereby unsubscribe from this list, and am > starting a new one called ufans for my new OS release. Please join me > in this important work. " > > There now, wouldn't that be much easier? You already run a bunch of > servers; I think you could pull it off. And it might lower your blood > pressure :-) > > You declined Noah's serious offer to take over sources; here's another > chance! Go for ti! You should not assume it would not work. > > Ron > >
Re: [9fans] plan9port behind corporate firewall with no DNS or port access
On Sat, Jul 25, 2009 at 1:39 PM, Salman Aljammaz wrote: > Uriel wrote: >> If your work firewall proxies port 80, then things get trickier, you >> could mount sources on the home inferno instance, and then export it >> using mjl's httpd as a read-only http 'tree'. > > assuming you've got openssh, one trick i used to do back in school was > run sshd on on port 443. > > you can then forward specific ports (-L) or even run socks (-D) on ssh. > > salman > > > on unix: % cat .ssh/config Host xxx ProtocolKeepAlives 30 ProxyCommand /path/to/proxytunnel/proxytunnel -p proxyhost:proxyport -P proxyuser:proxypass -d xxx.org % ssh -D localproxyport -Llocaladdress:localport:sources.cs.bell-labs.com:564 u...@xxx.org on Plan 9: % srv -nq tcp!localaddress!localport sources /n/sources and there you have it. only tested it for non-authenticated connections. iru
Re: [9fans] 9p question
On Thu, Jul 30, 2009 at 1:08 PM, Russ Cox wrote: > On Thu, Jul 30, 2009 at 8:28 AM, Venkatesh Srinivas wrote: >> How come you can't TWalk along an open Fid? > > In the original 9P protocol, that didn't make sense, > because walk always updated the fid it was starting from. > If you open a fid and then walk it elsewhere, > is it still open? Is that an implicit close? > And the operation isn't needed by the Plan 9 kernel anyway, > so out it goes. > > In the current 9P protocol, I think it would be fine to > allow a walk to start at an open fid as long as newfid > was being used to create a new fid. This would > make it easy to implement fchdir on Unix. > it would surely make it easier for unix implementations. i have had plenty of issues with that in o9fs. but as yourself pointed out, what would that walk mean? iru
Re: [9fans] a few Q's regarding cpu/auth server
On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidis wrote: > On Thu, 6 Aug 2009 11:33:18 +0100 > "Steve Simon" wrote: > >> I cannot imageine the senario where random people will have access >> to the cpu/auth/file server's consoles. It just doesn't happen >> if you are serious about security. >> >> However if you want to protect your console against your friends >> I wrote a script to do it /n/sources/contrib/steve/rc/conslock >> you may also want to look at screenlock(1) >> >> Incidentially I may use this at home to protect my servers console >> against my 2 year old who rather likes keyboards, though this is >> a different type of security. >> >> -Steve >> > > Speaking of family, I'd imagine a little password protection might go a long > way to keeping > the peace in many families. Respect for siblings' property > isn't exactly hard-wired into > human nature, is it? no password protection will suffice when ethics fails. iru
Re: [9fans] a few Q's regarding cpu/auth server
On Fri, Aug 7, 2009 at 9:39 AM, Ethan Grammatikidis wrote: > On Fri, 7 Aug 2009 09:29:25 -0300 > Iruata Souza wrote: > >> On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidis >> wrote: >> > On Thu, 6 Aug 2009 11:33:18 +0100 >> > "Steve Simon" wrote: >> > >> >> I cannot imageine the senario where random people will have access >> >> to the cpu/auth/file server's consoles. It just doesn't happen >> >> if you are serious about security. >> >> >> >> However if you want to protect your console against your friends >> >> I wrote a script to do it /n/sources/contrib/steve/rc/conslock >> >> you may also want to look at screenlock(1) >> >> >> >> Incidentially I may use this at home to protect my servers console >> >> against my 2 year old who rather likes keyboards, though this is >> >> a different type of security. >> >> >> >> -Steve >> >> >> > >> > Speaking of family, I'd imagine a little password protection might go a >> > long way to keeping > the peace in many families. Respect for siblings' >> > property isn't exactly hard-wired into >> > human nature, is it? >> >> no password protection will suffice when ethics fails. > > ETHICS? In a SEVEN YEAR OLD who knows what rm does? What the fuck planet > are you from? Don't get me started on my teenage years. > having respect for the shared (or private if you wish) stuff is ethical. if only prohibition is applied, no password protection will work. a seven year old in anger can surely set fire on the computer or whatnot if ethics fails him. iru
Re: [9fans] Acme Configuration
On Fri, Aug 7, 2009 at 1:54 PM, Noah Evans wrote: > you mean outside of the dump when acme is dies for reasons other than > being killed/exited? > > with win state, how are you going to handle the state of the shell? I > can see why they're dynamic, it could be potentially misleading to see > a changed namespace/rfork etc... and expect the shell to have the same > environment as the history. > i've been thinking about that. maybe just dumping the win contents (not the whole environment) would do the job. iru
Re: [9fans] manpages broken/outdated
On Mon, Aug 10, 2009 at 8:09 AM, Noah Evans wrote: > man 4 disk # disk(4) > > On Mon, Aug 10, 2009 at 12:10 PM, Bela Valek wrote: >> I have checked it on 3 different installations, the 'usbdisk' manpage >> is missing, on fresh installations too. Its not a filesystem >> corruption for sure. Most other USB-related manpages still list the >> nonexistent -f and -l parameters for the 'usb/disk' command. >> >> Greetings: Béla >> >> > > i guess you meant usb(4)
Re: [9fans] manpages broken/outdated
On Mon, Aug 10, 2009 at 8:59 AM, Noah Evans wrote: > Try it. try updating your system.
Re: [9fans] dump9660?
On Thu, Aug 20, 2009 at 6:34 PM, Venkatesh Srinivas wrote: > Hi, > > Do any of you still use dump9660? Any recent experiences or stuff I > should watch out for using it? > mk9660(8) is the main user, but i don't think she reads the list. iru
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 3:26 PM, Uriel wrote: > Er, it doesn't need a new PBS, booting Plan 9 from a Plan 9 kernel > already worked just fine with what russ did years ago. > > uriel > i heard that from you already. i just don't know why haven't you done it yet. for the ones interested, the code is at http://src.oitobits.net/9null. i'm writing a README explaining how to compile and install. iru
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 4:07 PM, Tim Newsham wrote: >> for the ones interested, the code is at http://src.oitobits.net/9null. >> i'm writing a README explaining how to compile and install. > > Are there plans for this to get folded into the mainline? > I wrote it with the hope of getting it into the mainline, so the choice is up to people with access to the labs. iru
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 3:48 PM, Uriel wrote: > Can it load and parse plan9.ini? > > uriel > it can. can you? iru
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 5:14 PM, erik quanstrom wrote: >> Do we stick with that file format forever? is it perfect and never to >> be changed? > > would it be fair to ask a the same question from a little > different perspective? > > could someone explain what the disadvantages and problems > with 9fat are? i'm asking out of ignorance, since 9fat hasn't > been a problem for me. > 9fat serves only two purposes: a) be a home for plan9.ini, b) be a home for some kernels. in the actual state of affairs, you must have 9fat and it must reside at the very beginning of the Plan 9 slice on the disk. 9null (the project we're talking about) doesn't require any of it, but allows it. you can have a fat partition with plan9.ini and, say, 9pcf. but it can't reside at the very beginning of the disk. in fact, you should be able to have plan9.ini and kernels anywhere you want: fossil, kfs, ext2, iso9660, &c. the Plan 9 slice layout used by 9null is: sector 0: pbs sector 1: Plan 9 partition table sector 2..k: 9pcload kernel sector k..n: data iru
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 6:38 PM, erik quanstrom wrote: >> > It has not been a problem for anyone I know. It might not be perfect >> > or beautiful, but I have yet to hear any suggestion for a replacement >> > that has all the advantages of 9fat (simple, reliable, easily >> > accessible from other systems, etc.) >> >> I think "easily accessible from other systems" should be removed >> from the list. There are alternatives, such as booting a live cd. >> Many other operating systems also keep their kernels on native >> filesystems and do not suffer because of it. > > i have found it convienent to be able to update a kernel > from linux, osx, windows. i would imagine this is important > for vm solutions, too. do you think it's preferable to build > a live cd for this including the little bit prepared in another > os? i've found live cds to be pretty annoying to maintain. > as i said early in this thread, with 9null you kernel may live in any fs you like as long as Plan 9 has can read it.
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 6:41 PM, erik quanstrom wrote: >> 9null (the project we're talking about) doesn't require any of it, but >> allows it. you can have a fat partition with plan9.ini and, say, 9pcf. >> but it can't reside at the very beginning of the disk. in fact, you >> should be able to have plan9.ini and kernels anywhere you want: >> fossil, kfs, ext2, iso9660, &c. >> >> the Plan 9 slice layout used by 9null is: >> sector 0: pbs >> sector 1: Plan 9 partition table >> sector 2..k: 9pcload kernel >> sector k..n: data > > is there a 9pxenull? that is a PXE-loadable 9null. > all machines here except the auth and file servers > PXE boot. > i didn't take a look at pxe booting yet, but i'd be happy to have it working. iru
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 6:57 PM, Steve Simon wrote: > 9fat is also a pain in that the 9load file must be created with, > and retain its append only file, which has a special meaning to 9fat > telling it to create the file in sequential blocks. > > This could (and has) caused problems if you access the 9fat partition > from os's other than plan9. > > The only times I have had to change plan9.ini from somthing else > than the booted system (because I have broken the boot process) > I booted the plan9 live cdrom. > > I would be happy if 9load and 9fat disappeared and it was > replaced with a plan9 bootstrap kernel and (say) an rc(1) script. > that's just what 9null is: new pbs, 9pcload (bootstrap kernel), /boot/boot using rc(1) scripts. instead of a 'root from' you may get a 'kernel is at' prompt to which you can ask for a shell (!rc) iru
Re: [9fans] new 9atom.iso
On Fri, Aug 28, 2009 at 8:06 AM, Uriel wrote: > On Fri, Aug 28, 2009 at 7:23 AM, ron minnich wrote: >> On Thu, Aug 27, 2009 at 6:54 PM, Federico G. >> Benavento wrote: >> >>> I could achieve the same as I did by doing "copy 9load E:" on windows >>> with this new approach, but I'd need to boot some linux live CD >>> and dd my way out to put the new loader there which I'll be too >>> hacky and I'd probably need a version of prepdisk for linux >>> on that live cd as well, if I got it right. >> >> yep, this is a good point. It's the same reason that Peter Anvin >> argued against using linux as a boot loader in place of grub or pxe or >> whatever. There are simple standards on booting PCs, and if you >> conform to them, you are more going to work in all cases. If you don't >> conform to them, there are more cases where you can't work. Your Vista >> example is a good case study. >> >> So the FAT partition is good when you want to interoperate. But as you >> point out, it's kind of 1/2 of a real fat partition, which means >> sometimes, even if it looks ok in vista or whatever, it's not really >> ok. It's not really possible to fit a true FAT file system handler in >> a 512 byte pbs. The Plan 9 pbs (and I assume most of them) are really >> a "find a file by name, get the offset, and just start loading >> contiguous data form whatever is at that offset in the partition until >> done". That's why there are things like install_grub, or lilo, or >> other such tools. If you delete and replace 9load and it ends up >> discontiguous, well, you may not be able to boot, hence the need to >> sometimes remove and replace all the files in the FAT. >> >> There are a number of reasons to like using a plan 9 kernel to boot >> your machine: drivers, native file systems, and so on. Interoperation >> with vista is not one of them. It may well be in the long term that >> the best way to remove 9load is to make Plan 9 grub-bootable. > > You try to present this as if using a Plan 9 kernel to boot somehow > precludes the use of the existing 9fat setup, this is not true, and > the whole point of the original GSoC project was precisely that: to > boot using a kernel without changing anything about 9fat and plan9.ini > so we could have a drop in replacement for 9load. > there was no 'without changing' anything. it was just to replace 9load. the project proposal was accepted without touching the 9fat subject. if it's not specified, it's open to discussion. > > And given that such a setup would have all the advantages you list > here, plus would retain the advantages people enjoy from 9fat, it is > hard to understand why doing something else is such a great idea. > this has been explained already: 9null does not care about the filesystem where the kernel lives, as long as Plan 9 knows how to mount it. if you like fat because of interoperability, that's ok, we have dossrv and 9null can use it. we simply don't require it. i don't see how fgb's solution would not work with 9null. i myself have setup a fossil disk for testing outside of the Plan 9 machine with 9null and it booted just fine. it would have been the same if i had setup a fat partition outside. iru
Re: [9fans] new 9atom.iso
On Fri, Aug 28, 2009 at 9:50 AM, matt wrote: > erik quanstrom wrote: > >> i love it. we have complaining that fat doesn't do more >> than 8.3 and trolling that there's a patent liability for >> doing more than 8.3 within 24 hrs. >> > > thanks but I'm not trolling, not complaining > >> just to be clear. fat itself is not patented. just some >> particular aspects of a 8.3 workaround. >> >> >>> >>> though maybe the inability to do fat32 will save you. >>> >> >> dossrv and 9load both read fat32. >> > > I was refering to format not dossrv > > BUGS > Format can create FAT12 and FAT16 file systems, but not > FAT32 file systems. The boot block can only read from FAT12 > and FAT16 file systems. > >> >>> >>> I like the sound of the sector 1 idea, I'm sure making a tool to r/w it >>> in Linux / whatever can't be hard. >>> >> >> i think that's the point of using fat. no tools required. >> > > No tools except a second OS installed on your machine / one you can plug > your disk in to > >> you're already in a pickle if you've gotten to this point. >> consider the acer inspire machine this week that > > but as you say here, if you're having trouble, you need something to help > you. The great help you've been giving people here was via iso files > > Anyway, there are good arguments on both sides. There's only one way to > solve this : > > FIGHT > i fought myself. pbs32 (9null's pbs) now works with 9fat without caring about it. it loops reading a block and checking for the a.out(8) signature. if the 9pcload is on 9fat, not a problem anymore. iru
Re: [9fans] new 9atom.iso
On Fri, Aug 28, 2009 at 11:54 AM, Iruata Souza wrote: > On Fri, Aug 28, 2009 at 9:50 AM, matt wrote: >> erik quanstrom wrote: >> >>> i love it. we have complaining that fat doesn't do more >>> than 8.3 and trolling that there's a patent liability for >>> doing more than 8.3 within 24 hrs. >>> >> >> thanks but I'm not trolling, not complaining >> >>> just to be clear. fat itself is not patented. just some >>> particular aspects of a 8.3 workaround. >>> >>> >>>> >>>> though maybe the inability to do fat32 will save you. >>>> >>> >>> dossrv and 9load both read fat32. >>> >> >> I was refering to format not dossrv >> >> BUGS >> Format can create FAT12 and FAT16 file systems, but not >> FAT32 file systems. The boot block can only read from FAT12 >> and FAT16 file systems. >> >>> >>>> >>>> I like the sound of the sector 1 idea, I'm sure making a tool to r/w it >>>> in Linux / whatever can't be hard. >>>> >>> >>> i think that's the point of using fat. no tools required. >>> >> >> No tools except a second OS installed on your machine / one you can plug >> your disk in to >> >>> you're already in a pickle if you've gotten to this point. >>> consider the acer inspire machine this week that >> >> but as you say here, if you're having trouble, you need something to help >> you. The great help you've been giving people here was via iso files >> >> Anyway, there are good arguments on both sides. There's only one way to >> solve this : >> >> FIGHT >> > > i fought myself. > pbs32 (9null's pbs) now works with 9fat without caring about it. > it loops reading a block and checking for the a.out(8) signature. if > the 9pcload is on 9fat, not a problem anymore. > a.out(6), sorry
Re: [9fans] scheme plan 9
On Wed, Sep 2, 2009 at 8:32 AM, Eris Discordia wrote: > Although, you may be better off reading SICP "as intended," and use MIT > Scheme on either Windows or a *NIX. The book (and the freaking language) is > already hard/unusual enough for one to not want to get confused by > implementation quirks. (Kill the paren!) > for the most part of the book Plan 9 is as good as the mentioned options, except if you want a more lispy editor. iru
Re: [9fans] "Blocks" in C
On Thu, Sep 3, 2009 at 4:50 PM, David Leimbach wrote: > > > On Thu, Sep 3, 2009 at 12:36 PM, erik quanstrom > wrote: >> >> > > > Apple's using it all over the place in Snow Leopard, in all their >> > > > native >> > > > apps to write cleaner, less manual-lock code. At least, that's the >> > > > claim >> > > > :-). >> > > >> > > could someone explain this to me? i'm just missing how >> > > naming a block of code could change its locking properties. >> > > >> > > >> > The explanation is in the manual I linked to earlier in this discussion. >> > If >> > you want to see examples there's two I can think of available for >> > download. >> > One is called DispatchLife the other is DispatchFractal. >> > >> > I've looked at DispatchLife, and there's no explicit locking of state >> > for >> > every cell being concurrently update in Conway's game of life. >> >> i can't find DispatchLife after a few minutes of googling. >> i've read the manual, and it looks like csp to me. clearly >> i am a reprobate outside the apple reality distortion field. >> > > Google doesn't have all the answers, I actually had to use Bing today, and > it worked... anyway here's the link to DispatchLife. > http://developer.apple.com/mac/library/samplecode/DispatchLife/ > >> >> could you explain why this isn't csp and why this can't be done >> with regular c (that is why we need the concept of an >> unnamed function pointer) and the thread library? > > I'm actually planning to figure this stuff out a bit more and "blog" about > it, hopefully by Friday sometime (tomorrow). > I don't agree that any of this stuff is strictly needed. One can plod along > with pthreads and do it wrong all day. One doesn't *need* C either, I've > seen whole OSes for x86 written in assembly. > It all depends on how much crap you want to keep track of. > Dave > or how much crap you want to dive into without noticing. iru
Re: [9fans] "Blocks" in C
On Fri, Sep 4, 2009 at 1:44 PM, Roman Shaposhnik wrote: > There's been a *lot* of speculation on this thread and very little fact. > (...) > Trust me, I've seen how it is generated. > so we should trust you and not the facts? is that what you are saying? because i haven't seen any 'factual' code yet. iru
Re: [9fans] lisp again.
On Mon, Sep 7, 2009 at 9:54 AM, John Floren wrote: > On Mon, Sep 7, 2009 at 8:47 AM, LiteStar numnums wrote: >> Well, lisp != common lisp aside, I wouldn't mind a native CL system. I >> haven't looked at the SBCL backend in quite sometime, but, assuming it's not >> terribly insane, that would be a decent route. Most CL work that isn't >> specific to one of the proprietary systems (Allegro, LispWorks, &c.) is >> written with SBCL or, to a lesser extent, CCL. If anyone's interested in >> working on a CL port to plan9, I'll start a lisp cabal, that can work on >> other systems next. >> >> I'll look today... > [previous message and grotesque signature snipped] > > One challenge with SBCL and some other implementations is that you > need a Common Lisp system already in place to compile them. I looked > into Clisp, which can be compiled with a C compiler, but after > fighting configure for a while I quit. > maybe the bootstrap can be done with linuxemu. iru
Re: [9fans] lisp again.
On Mon, Sep 7, 2009 at 10:53 AM, erik quanstrom wrote: >> maybe the bootstrap can be done with linuxemu. > > wouldn't that just give you yet another linux elf binary? > you are right. it must know how to compile correct a.out(6). iru
Re: [9fans] nice quote
On Wed, Sep 9, 2009 at 12:48 PM, Charles Forsyth wrote: > anyone written any software recently? writing a new boot(8) that uses rc(1) to drive the boot process. iru
Re: [9fans] "Blocks" in C
On Tue, Sep 8, 2009 at 1:40 PM, Bakul Shah wrote:
> On Tue, 08 Sep 2009 08:31:28 PDT David Leimbach wrote:
>>
>> Having wrestled with this stuff a little bit, and written "something". I
>> can immediately see how one can get away from needing to "select" in code so
>> much, and fire off blocks to handle client server interactions etc. It's
>> kind of neat.
>
> alt(3) is a nicer way to avoid select().
>
> I still say CSP is the way to go. In plan9/limbo channels
> work across coroutines in one process. Seems to me extending
> channels to work across preemptive threads (running on
> multiple cores) or across processes or machines is might lead
> to a more elegant and no less performant model. It seems
> to be a more natural model when you have zillions of
> processors on a chip (like TileraPro64, with zillion = 64).
> They can't all go to shared external memory without paying a
> substantial cost but neighbor to neighbor communication is
> far faster (tilera claims 37Tbps onchip interconnect b/w and
> 50Gbps of I/O bw).
>
> It is nice that a Apple C block treats all non local
> variables (except __block ones) as read only variables. But
> every time I look at blocks I see new problems. What if a
> block calls a function that modifies a global like in the
> example below? If this works, what is the point of treating
> globals as readonly? If this doesn't work, how do ensure
> trash_x() causes a seg fault, particularly when it is defined
> in another file?
>
> int x;
>
> void trash_x() { x = -42; }
>
> ... ^{ trash_x(); } ...
>
> My view: if you can't solve a problem cleanly and in a
> general way with a feature, it does not belong in a language
> (but may belong in a library).
>
for those who still care
http://libdispatch.macosforge.org/
Re: [9fans] linux stats in last year from linuxcon
On Thu, Sep 24, 2009 at 11:21 AM, Patrick Kelly wrote: > > > On Tue, Sep 22, 2009 at 9:55 PM, David Arnold wrote: >> >> On 22/09/2009, at 4:47 PM, Jack Norton wrote: >> >>> In the end I don't care what the linux devs do, but they need to come up >>> with a game plan and either fork (server, desktop linux) or include it all >>> and try and make everyone happy (the latter will end in chaos me thinks). >> >> There are several Linux distributions aimed at digital audio workstation >> usage. They come with an appropriate kernel configuration/patchset (and >> audio daemons). > > > Yes, but as I said, most of them haven't been updated in forever, and mostly > run on hardware from 1-2 years ago (debian philosophy?) > > Gentoo seems to be the only one regularly updated, and keeping itself up to > date. That or build your own kernel, with patches, which as stated, most > musicians aren't going to want to do. > > If there is a distrobution thats still around and regularly updated, please, > let us know. > wrong door, sir. search for linux in the door with the penguin. thanks
Re: [9fans] 9vx as a perfect proto environment
On Sun, Sep 27, 2009 at 2:14 PM, Russ Cox wrote: >> It's fast. But the big beauty of it for me is that in vx32/src/9vx/a >> is pretty much a plan 9 kernel in plan 9 C vernacular. I just spent an >> easy short time prototyping some new stuff that I can now drop into a >> real plan 9 kernel for Blue Gene, no changes needed. The >> edit/build/test boot cycle is measured in seconds. The fact that we >> have a friendly path via codereview(1) and bitbucket is the icing on >> the cake. > > This is definitely one of my favorite things about 9vx. > It's a great environment for doing kernel hacking. > >> [comments about instability] > > I don't think there's any inherent reason why 9vx must be unstable, > but it certainly has a couple bugs. I haven't had the time to track > them down and fix them, but I'm always happy to point in the > right direction if you can reproduce one. There have been a > few reports about it dying with cryptic errors from vx32. I'd like > to track those down but a reproducible test case is an absolute > requirement for the gritty low-level code at the bottom. > > The fact that 9vx works as well as it does has always made me > feel like I was cheating. It feels like it should be impossible > or at least much harder, and yet there it is, and most things run. > the new boot code i am working on was written in 9vx. i found it - and other programs as well - to hang on one of my machines, but i still think it occurs because of ubuntu + what appears to be a bad video driver + pulseaudio + X + ... if that seems familiar to anyone, let me know that i'm not alone. iru
Re: [9fans] iwp9: getting from Atlanta to Athens
On Mon, Oct 5, 2009 at 8:46 PM, erik quanstrom wrote: > On Mon Oct 5 17:35:11 EDT 2009, m...@acm.jhu.edu wrote: >> Hi, >> >> For those of us traveling to IWP9, what are recommended ways to get >> from Atlanta to Athens? We were likely going to Atlanta by train... >> >> Thanks, >> -- vs > > i've updated the iwp9.org page with a link to a local shuttle. > the shuttle is pretty expensive, so i think it will be cheeper to > rent a car. the holiday inn and hilton garden both have parking > a go go. > > - erik > > if anyone want to rent a car, let me know so maybe a few people can share the expenses. iru
Re: [9fans] iwp9: getting from Atlanta to Athens
On Tue, Oct 6, 2009 at 12:19 PM, erik quanstrom wrote: >> >> if anyone want to rent a car, let me know so maybe a few people can >> share the expenses. > > i should have mentioned that driving is generally very easy > as long as you can use the carpool lane. (but then again, i didn't > mind driving in greece.) you only need two > people for this. if you use i-85 (interstate 85 north) you can > get in the carpool lane and stay there until you're all the way > out of atlanta. at the end of the carpool lane (when you > see the big fry's electronics), head down 316. just go straight > until you hit "loop 10". cross loop 10 and proceede downtown. > i do not drive, so that's why i asked :]
Re: [9fans] IWP9 hack session
i second that. On Tue, Oct 6, 2009 at 5:11 PM, Eric Van Hensbergen wrote: > Should have come up with that before people booked travel. Thursday night > at a pub perhaps? > > Sent from my iPhone > > On Oct 6, 2009, at 2:50 PM, ron minnich wrote: > >> I'd like to have a hack session the wed. morning before IWP9. >> >> What I'd like to propose is a sheeva plugfest. People commit to bringing a >> plug >> and we get them set up to run Plan 9. >> >> Any interest? >> >> ron >> > >
Re: [9fans] 9P in lua
On Tue, Oct 13, 2009 at 11:10 AM, Sergey Zhilkin wrote: > There is a LUA for P9 > http://plan9.bell-labs.com/sources/contrib/iru/lua-5.1-plan9.tgz > > But ... 9P on LUA maybe iRu knows ? > i don't. not yet. > 2009/10/13 Roman Shaposhnik : >> Guys, >> >> has anybody seen 9P implemented in Lua? Either client, server or both? >> >> Thanks, >> Roman. >> >> > > > > -- > С наилучшими пожеланиями > Жилкин Сергей > With best regards > Zhilkin Sergey > >
Re: [9fans] So quiet!
On Sat, Oct 24, 2009 at 1:32 PM, roger peppe wrote: > 2009/10/23 W B Hacker : >> We can't 'ave two 9'ers actually *agree* on sumat! > > i found it interesting that face to face there seemed to > be much more agreement than disagreement. > very constructive. > i second that. we could even write code together. > i've had a brilliant time. > > did your bike like it too? :] iru
Re: [9fans] So quiet!
On Sun, Oct 25, 2009 at 7:49 PM, Steve Simon wrote: >> I thought it was just wonderful, and noticed similar reactions from >> everyone else. It was a very fine meeting. > > Makes me even more sick I was unable to come. > > could somone post a quick summary of the plan9 extra-cirricular > activities, e.g. was sheeva plug port was completed successfully? > i started writing a new pbs with cinap which uses the BIOS to read data and protected mode to move it. thank you so much cinap, gorka, and everyone who criticized. iru
Re: [9fans] sed question (OT)
On Thu, Oct 29, 2009 at 2:08 PM, erik quanstrom wrote: >> To capitalize the first letter of each line wouldn't this be enough? >> >> s/^./\u&/ > > ; echo abc def | sed 's/^.\u&/' > sed: s command garbled: s/^.\u&/ > i guess you missed the second slash
Re: [9fans] sed question (OT)
On Thu, Oct 29, 2009 at 2:06 PM, Lorenzo Bolla wrote: > To capitalize the first letter of each line wouldn't this be enough? > s/^./\u&/ > > L. % echo rwrong | sed 's/^./\u&/' urwrong
Re: [9fans] dtrace for plan 9
On Sun, Nov 1, 2009 at 4:44 PM, Nathaniel W Filardo wrote: > On Sun, Nov 01, 2009 at 11:58:10AM -0500, erik quanstrom wrote: >> On Sun Nov 1 11:55:47 EST 2009, devon.od...@gmail.com wrote: >> > Also, D is not compiled in kernel. The dtrace utility compiles the D >> > script, and the script goes through some sanity checking in the D >> > compiler. The bytecode is sent to the kernel to execute. There are >> > some in-kernel safety guarantees -- for instance, a D script causing a >> > nil ptr deref in kernel obviously shouldn't (and does not) cause the >> > system to panic. >> >> that wasn't my main concern. >> >> there are many interrupt routines that depend on >> the exact sequence of events and probing is likely >> to wreck havoc. > > D is not able (AFAIK, anyway... the design seems like it oughtn't be) to > change the externally observable sequence of events to hardare. It may of > course change the timing of those events, but that's often less of an issue. > If you don't disable safety (as root, you can, AIUI) DTrace writes only to > its own logs, even if it can read almost everything. > >> how do you prevent probes from reading read-to-clear >> registers? > > DTrace has a notion of "toxic" regions of memory -- lists provided by > drivers -- which D is not allowed to access. It is possible to get these > wrong, and that's a bug, just like it would be possible to get the driver > itself wrong. > >> how do you know a probe in an irq routine won't set >> off a latent race? > > AIUI since D bytecode is loop-free (it permits only forward branches, making > it trivially terminating), hooks run in non-preemptable context can safely > inherit non-preemption from their hooked context. > > If you've got a race between CPUs that's tickled by DTrace, it could also be > tickled by changing your compiler, or dynamic CPU clocking, or a higher > priority IRQ, or ... take your pick. That's a bug and it's not DTrace's > fault. > > All that said, DTrace is not perfect and probably has some corner cases that > may cause trouble. I'm sure the Solaris developers would love to hear from > you if you find one. > if i remember correctly, in 2006 i took Sun's SA-327-S10 course on dtrace. after learning some D, i tried the obvious thing: enabling all probes. something strange has happened after that. here i try to reproduce from memory the steps i took and the strange thing i found (if anyone is still able to reproduce the thing, i'm curious) on a solaris 10 system: 1. log in to a CDE session 2. open two ksh terminal windows (w1 and w2 from now on, respectively) 3. type some commands at random in w1 4. type some commands at random in w2 5. with the up arrow key, check the command history on both windows 6. run dtrace enabling all probes in w2 (the system may become slow) 7. interrupt dtrace 8. check the command history of the windows i was told dtrace was non-intrusive at the time, but w2 would show the command history from w1. iru
Re: [9fans] dtrace for plan 9
On Tue, Nov 3, 2009 at 4:29 PM, Lyndon Nerenberg wrote: >> i was told dtrace was non-intrusive at the time, but w2 would show the >> command history from w1. > > More likely this is ksh sharing a history file. > > at the time i couldn't reproduce it with other shells. anyway, iirc, no such side-effect was seen without running dtrace (that still doesn't say anything directly against dtrace, of course).
[9fans] kernel compiling with -R
hello, is there any reason why the kernel is not linked with its text segment rounded? iru
Re: [9fans] MIPS LSB compiler
On Fri, Nov 13, 2009 at 3:48 PM, Tim Newsham wrote:
>> * A ducktyping of sorts with interfaces and such. On the surface
>> it just saves
>> you a bunch of "extends XXX", but it actually seems to bridge
>> the gap between
>> dynamically typed world and a statically typed one to an extent
>> that makes me
>> rethink whether static typed languages are as devoid of fun as a
>> Principia Mathematica is.
>
> The type system is more restrictive than duck typing. Thats sort
> of the point of any static type system. But there are useful constructs
> that you can express in a dynamically typed language or a language
> with a more complex type system that you cannot express in go. A
> good, simple example is "map". Go would need generics to support it.
>
$GOOROOT/src/pkg/bytes/bytes.go:248 func ToLower(s []byte) []byte
{ return Map(unicode.ToLower, s) }
Re: [9fans] usb disks in plan9
On Sun, Nov 22, 2009 at 3:57 PM, Tim Newsham wrote: >> Usb disks don't know how to handle partitions. >> You have to use partfs IIRC or some other tool to >> partition it. > > Hmm.. Here is what I would like to do. I would like to put > a FAT32 and a fossil (or kfs) filesystem on a usb flash drive > and use the FAT32 for botting and the fossil as my root > filesystem. > > Lets say that the usb disk did support partitioning, or I used > the entire usb disk as a single filesystem, is there any > way to specify to mount /srv/usb's sdU4.0/data (or whatever name) > as root? Or would I have to hack a mount of /srv/usb into > /sys/src/9/boot and specify something like "local!/dev/sdU4.0/data"? > > If I use something like partfs, I would have to hack this > into the /sys/src/9/boot stuff, right? with my changes [1] to boot(8), you could just use !rc as the root and you'd be dropped to rc(1) and could try your setup without having to change the actual sources. iru [1] http://src.oitobits.net/9null > > Is there any long term desire to allow booting off of USB drives? > > Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com > >
[9fans] auth_getkey(2) and factotum path
hello, i am playing with a kernel configuration where i have factotum in /$cputype/bin/auth/factotum instead of /boot. today this is not possible because auth_getkey(2) requires /boot/factotum or /factotum to be present. would it be a problem if auth_getkey tried the usual place too? iru
Re: [9fans] Announcing: rootless post kernel load startup
On Sat, Jan 2, 2010 at 1:56 PM, mycroftiv 9gridchan wrote: > More recent work - available on sources in > contrib/mycroftiv/rootlessboot as both patches and a compiled ready to > use kernel and optional rootfs.tgz additional tools to be placed in > 9fat partition. > > "Rootless" bootup is a rewrite of the post-kernel load bootup process > as handled by boot and init. The motivation is severalfold: the basic > nature of the Plan 9 kernel as a 9p multiplexer means that there is no > inherent reason to make any given filesystem special and necessary to > keep the system usable. The particular case of a tcp-booted cpu server > losing its network root fs is a traditional example. It is sometimes > the case that a system with local fossil and remote venti can't be > successfully booted if the IP address of the venti has changed from > that given in plan9.ini. The overall goal is to improve reliability by > enabling a running system to always repair and recover itself even if > it experiences failure of normally criticial resources like a local > venti+fossil. > > The rootless boot method combines boot and init into a much smaller > program that does much less, and adds the rc shell and a few other > tools to the kernel's compiled-in /boot. An rc script called plan9rc > handles the tasks of starting up factotum, ipconfig, venti, fossil, > and setting up a desired initial filesystem mount and running > additonal options scripts and/or conventional cpurc or termrc from an > external fs. Depending on the settings in plan9.ini, this can all be > done interactively with the ability to drop to an rc shell. The > plan9rc script can act to imitate the standard bootup process, or > setup the environment in a different way - for instance by creating a > ramfs with additional tools loaded from 9fat to create a working > environment independent of the environment created by the standard > bootup. > > As an example of the flexibility of this approach, I have tested this > scenario: a rootless system starts up with interactive=yes set in the > plan9.ini. It starts factotum, ipconfig, and then a venti server, and > then pauses its bootup process. A second machine is then started as > the fossil file server, and it is instructed to dial the venti and > begin serving fossil and its normal startup. Once the fossil is > serving, we return to the machine serving venti, and continue through > the bootup process, and choose to imitate tcp-booting - and select the > external fossil for the external service to mount. The fossil is > dialed and bootup continues as if it was a standard tcp root cpu > server. The end result is that even the system hosting the venti is > still "rooted" via an external fossil which is in turn using the venti > as a backing store. This sequence would not be possible using the > standard bootup method. Rootless booting also enables tcp booted cpu > servers to be recovered without rebooting. The initial console process > is usually kept in a protected namespace, with no connections to > non-kernel resources. Consequently, if the non-kernel 'root' is lost, > the dead processes can be killed off, another root acquired, and work > resumed. If no local resources are available, a srv and mount of > sources allows access to the tools of the full distribution. > > contrib/mycroftiv/rootlessboot holds the source for the modifications, > as well as a compiled kernel. Also available is a rootfs.tgz for use > in creating an optional ramfs based independent environment. If you > wish to use this, put it in your 9fat. There is a lot of flexibility > in exactly what is compiled into /boot and whether or not a ramfs with > additonal tools loaded. Some users may prefer a light kernel that > acquires a relatively large rootfs.tgz, whereas others might prefer to > make a heaver compiled in /boot. The sample kernel on sources and > rootfs.tgz there are both fairly heavy to try to support most common > possibilities - venti, fossil, kfs, cfs are all compiled in, for > instance. > > The rootlessboot directory has a fair amount of small modifications > that are necessary or helpful, such as changing rc to look for > /boot/rcmain rather than /lib/rcmain, and giving cfs the ability to > post a srv. contrib/mycroftiv/rootlessboot/bootdir.extras/plan9rc > controls the boot process and provides many options for controlling > its behavior via plan9.ini variables. The default behavior is intended > to closely mimic the standard existing logic for handling plan9.ini. > The prebuilt kernel is a cpu kernel but setting service=terminal in > plan9.ini will produce terminal style behavior. As always, I would > recommend using a plan9.ini menu or setup so that choice of kernel > used is selectable at boot. > > I have read the paper on the 9null kernel load boot process from this > year's IWP9 and I am hoping that this work is consistent with its > approach. As I have been working only on the post kernel load actions, > I believe it to be mostly
Re: [9fans] parallels
On Fri, Jan 8, 2010 at 5:12 PM, wrote: > I don't have enough experience with VirtualBox to make a sensible > comparison. > > The thing that none of the VM monitors seem to offer (though I'd love > to be proven wrong) is debugging tools for the guest operating > systems. This is odd, as it was one of the major uses of VM/370. So > if a guest kernel goes off into space, the VM monitor shuts down the > virtual machine or resets it, but provides no means to find out what > happened, though it's in a perfect position to easily do so. > > > bochs offers you that to some extent.
Re: [9fans] problem with pull
On Thu, Feb 4, 2010 at 4:50 PM, Rudolf Sykora wrote: > Also, could you tell me what those errors are about and what the > /n/boot directory is good for? > /n/boot seems to be the mount of #s/boot, the root file server srv file.
Re: [9fans] New User with Problems
On Mon, Feb 8, 2010 at 8:41 AM, Steve wrote: > I've been scouring the Interwebs and haven't been able to find much of > a solution. > > Yesterday I decided to give P9 a try and burned the ISO file available > on Plan 9's installation page here: > http://plan9.bell-labs.com/wiki/plan9/download/index.html > > It was the direct link to the CD image so none of the other choices > that are available below. > > After burning the image to CD, I restarted my computer with the > primary booting option as the CD rather than the HD. I received the > following: > > 1 FD 2.88 MB System Type (00) > PBS1... > Plan 9 from Bell Labs > ELCR: 0CA0 > pcirouting: South bridge 8086, 2812 not found > no plan.ini > cpu0: 1862 MHz P6 loop 105279 > apm ax=f000 cx=f000 dx=fdf7 di=0 ebx=801c esi=10041c > Boot devices: fd0 > boot from: > > I've checked the requirements and my PC seems to be in order there. > > I did look around and the only possible problems I could find were > that maybe since I don't have Windows it was trying to look for the > FAT file (I'm strictly an only Linux user) in which case I do not have > VMWare and I'd be curious if there is a non-DOS ISO file that could > run on a Linux only system. The only other explanations that seemed > somewhat logical were that something went wrong in the pcirouting and > I missed something in the PC requirements listed on site or the ISO > file burned to my CD is faulty. > > Thoughts? > > -E > > the cd can't seem to find plan9.ini(8), the boot configuration file. the "boot from:" prompt is 9load(8) (the bootloader) asking you for a Plan 9 kernel to load, you may want to try fd0!dos!file where file may be 9pcf.gz, 9pcflop.gz. iru
Re: [9fans] New User with Problems
On Mon, Feb 8, 2010 at 1:13 PM, David Leimbach wrote: > > > On Mon, Feb 8, 2010 at 6:34 AM, erik quanstrom > wrote: >> >> > I did look around and the only possible problems I could find were >> > that maybe since I don't have Windows it was trying to look for the >> > FAT file (I'm strictly an only Linux user) in which case I do not have >> > VMWare and I'd be curious if there is a non-DOS ISO file that could >> > run on a Linux only system. The only other explanations that seemed >> > somewhat logical were that something went wrong in the pcirouting and >> > I missed something in the PC requirements listed on site or the ISO >> > file burned to my CD is faulty. >> > >> > Thoughts? >> >> i put a modified 9load on sources /n/sources/contrib/quanstro/9load >> perhaps you would be able to download it and put it in your 9fat >> partition with the distribution cd? >> >> if not or doesn't work, send the output of lspci off line. >> the main problem is that the distribution cd is not recognizing >> your pata/sata devices. >> >> - erik >> > > If you try Erik's 9atom ISO, you may have better luck. It'd be nice if the > 9load changes he made were already rolled up into the standard ISO, but I > guess they haven't made it yet? > Also there's a project to boot plan 9 from plan 9 without 9load, but I've > sort of lost track of where that is. I believe it was showing signs of > great success though :-) > Dave > http://src.oitobits.net/9null may be what you've heard of. i managed to boot kernels without 9load, but now it is somehow dog slow for loading from hard disks (cds are ok). i'm working on fixing that this week. iru
Re: [9fans] How to mount a P9 partition?
fossil/fossil -f /dev/sdD0/fossil -c 'srv fossil' this should post /srv/fossil as you want. then you can proceed to mounting as you did with the cd. On 2/19/10, Jonas Amoson wrote: > Hello! > > I am trying to access files that I have on a harddrive > on which the Plan 9 installation refuses to boot. I am > now booting from a new harddisk (sdC0) and would like > to mount the file system of the problematic disk (now > sdD0) in a directory (say /n/olddisk). I have succeeded > to mount CD:s (sdD1) by starting 9660srv and mounting > it from /srv: > > 9660srv -f /dev/sdD1/data > mount /srv/9660 /n/cdrom > > My guess is that I have to start a file server in a similar > fashion, and it does not complain when I write: > > fossil/fossil -f /dev/sdD0/fossil > > I was expecting some new entry named /srv/fossil that I > could mount in a directory, but that does not seem to > how it works. Running "ls /dev/sd*" gives the following: > > /dev/sdC0/9fat > /dev/sdC0/ctl > /dev/sdC0/data > /dev/sdC0/fossil > /dev/sdC0/nvram > /dev/sdC0/plan9 > /dev/sdC0/raw > /dev/sdC0/swap > /dev/sdD0/9fat > /dev/sdD0/ctl > /dev/sdD0/data > /dev/sdD0/fossil > /dev/sdD0/nvram > /dev/sdD0/plan9 > /dev/sdD0/raw > /dev/sdD0/swap > /dev/sdD1/ctl > /dev/sdD1/raw > /dev/sdctl > > > > > style="font-size:13.5px">___ style="font-family: Tahoma, sans-serif; font-size: 12px; color: #00f" > href="http://spray.matchaffinity.se/?mtcmk=614114";>SprayAffinity.se > - Träffa bara personer som passar dig!
Re: [9fans] (no subject)
On Sun, Mar 7, 2010 at 2:42 PM, wrote: >> We have fgb's contrib, and before that just the INDEX files in / >> contrib on sources. Neither is a perfect solution, but I don't think >> the problem here would be addressed by the Labs providing some new >> resource. Between the above and the wiki, there's plenty of >> opportunity for folks to make ports known. > > I'm merely suggesting a grouping function and I certainly am not in a > position to prescribe how it should be implemented. As I mentioned, I > like the way NetBSD's package does it, but the price is very steep. > Fgb's contrib sounds very good, I have not had occasion to try it but > I presume it retains the scattered nature of the contrib directory. > My choice would be to add a directory wherein to store both modified > sources and binaries for Open Source projects once they have been > validated. who's gonna validate the beasts? > Of necessity, one would have the version clearly indicated > and where possible duplications as occur frequently with popular > packages such a zlib would be removed. But there seems to me to be a > need to keep them together, although that may be just that I'm looking > at the problem from the single perspective of how it's done in NetBSD. please take 10 minutes to try fgb/contrib. while at it, run contrib/gui. when a package is duplicated, it should be clear from the package list on the left. iru
Re: [9fans] ports duplication
On Mon, Mar 8, 2010 at 1:26 AM, wrote: >> As for the smaller things, I would prefer to see ten different bits of >> code that achieve the same end vs. just one. Diversity is good, and a >> broader selection of code gives a bigger field to mine for ideas and >> concepts. > > I really don't think that's going to be the problem here, we do not > have an excess of ports, we have a problem determining whether a port > exists or, i don't think we have that problem if the port in in sources. you may have it because you don't seem to use fgb/contrib or any other tool for that. > It also helps a lot if one can establish a level of confidence in a > port, what would that level be? iru
Re: [9fans] Man pages for add-ons
On Sun, Mar 28, 2010 at 9:59 PM, Ethan Grammatikidis
wrote:
> On 29 Mar 2010, at 00:28, hiro wrote:
>>
>> Following your logic we must be one of the luckiest mailing list around
>
> I was speaking of lunix & co, on the basis that given enough additional apps
> & things the same problems will arise.
>
>> We use ls -t. It's better than git for your task.
>
>
> ...
>
> Surely not.
>
> ...
>
> Why didn't I think of that?
>
> ...
>
> Oh so if ls -lt in bin you see things grouped... the -l is important..
> yes... Oh when stuff is scattered through bin lib and other dirs you need ls
> -lt `{ find * } . Agh! Horrendous way-too-long-to-read output... I can pipe
> it into less -S and search. Wait, no less. That's fair enough, I can search
> in terminal... no search in terminal.
>
> Do not want to post "fail, feature needed." No contextual output from diff,
> and it would be a weak solution anyway. Perhaps some script to take the
> output from ls, pick the timestamp of a specified filename, and output only
> lines matching that timestamp. I could write that with only a little pain.
> :s Huh, I think we have a solution, but it's not just ls -t. ... And to
> simplify: rather than write a script I could ls -l a known file, snarf the
> timestamp, and ls -lt `{ find * } | grep . Well, that's bearable.
>
> I hope my stream of consciousness is readable, it's rather late here.
>
> Speaking of late, remember you should never let make install run at midnight
> (or it breaks the above solution).
>
since we are trying so hard to create new problems for Plan 9, should
i assume the old ones have all been solved?
iru
Re: [9fans] Plan ? (was: native install)
On Mon, Mar 29, 2010 at 10:21 PM, Corey wrote: > On Monday 29 March 2010 17:24:08 erik quanstrom wrote: >> > In any given social environment, communicating dissatisfaction of >> > the status quo is often the logical first step towards choices (a) >> > and/or (b) - due to the fact that going off on one's own to work >> > alone in a vacuum on a major undertaking is generally recognized >> > as an inherently ill-fated strategy. >> >> except that these same arguments have been going on for as long >> as i have read this list and no one has done anything about it. >> after 15+ years, i think it's fair to ask "where's the beef?" >> > > "Where's the beef?" is certainly a fair and reasonable thing to ask. > > What I'm wondering, however, is "_what's_ the beef?" > > As you said, these arguments have indeed been going on for some > time - so, why only talk and no action? It's weird. > > I can't help but wonder: where's the crux of the inertia? > > Are the core Plan 9 design concepts in fact ineffective or unsuitable for > building a general purpose computing environment? > > I find that very hard to believe - but there's over 15 years of evidence > which seems to imply just that. > > No one's willing to spearhead a "General Purpose 9" experiment, and no > one's interested in collaborating on and contributing to such a project? would you invite us for that experiment or keep talking, talking, talking... and talking? > "If you want [general purpose], you know where to get it." seems to > be the period that ends all such discussion. > a bunch of special purpose crap put together does not make a general purpose one. iru
Re: [9fans] Plan ? (was: native install)
On Mon, Mar 29, 2010 at 9:20 PM, Corey wrote: > Is it that the core Plan 9 design concepts[1] are in fact inappropriate or > uninteresting for anything beyond that which Plan 9 currently provides? > [1] /sys/doc
Re: [9fans] bootiso.s fixed
i guess this email was for me. ;] On Wed, Apr 7, 2010 at 7:52 PM, wrote: > found it! > > the problem was the LBPB() to load byte 0 from the pvd for comparsion. > i loaded it into rBX instead of rBL. found this out after dumping the > buffer and noticed that the contents where the same on t23 and amd > machine. > > it all works now. tested on t23, bochs, and amd machine and its > blazing fast :) > > updated the tarballs: > > /n/sources/contrib/cinap_lenrek/tuttleboot.tgz > http://9hal.ath.cx/usr/cinap_lenrek/tuttleboot.tgz > > attached the file and the diff to this mail... > > -- > cinap > > #include "x16.h" > #include "mem.h" > > /* > * simple Plan 9 bootblock for ISO9660 that can load a uncompressed a.out > kernel > * image. looks for 386/9pcload. if heres no 386 it searches 9pcload in the > root. > * this is a non floppy emulation el torito bootblock! > * > * Diagnostics are: > * ♥ alive! > * ? i/o error, will retry > * ! i/o error, giving up > * F bad a.out magic > * S could not find the file > * > */ > > #define DATA32SEL SELECTOR(1, SELGDT, 0) > #define EXEC32SEL SELECTOR(2, SELGDT, 0) > #define EXEC16SEL SELECTOR(3, SELGDT, 0) > > #define FARRET \ > BYTE $0xCB > #define SWAPB(r) \ > BYTE $0x0F; BYTE $(0xC8|r) > #define XORAL(i) \ > BYTE $0x34; BYTE $i > > /* 2048 byte sectors */ > #define SECTSHIFT 0x0B > #define BY2SECT (1< > /* > * Data is kept on the stack, indexed by rBP. > */ > #define Xdap 0x00 /* disc address packet */ > #define Xdrive 0x12 /* boot drive, passed by BIOS or MBR */ > #define Xentry 0x14 /* a.out entry, text, data*/ > #define Xtextsz 0x18 > #define Xdatasz 0x1c > #define Xload 0x20 /* load pointer */ > #define Xcount 0x24 /* # of sectors to load */ > #define Xbuf 0x28 > #define Xtotal (Xbuf+BY2SECT) > > /* a.out header offsets */ > #define Amagic 0x00 > #define Atextsz 0x04 > #define Adatasz 0x08 > #define Aentry 0x14 > #define Aouthdr 0x20 > > TEXT magic(SB), $0 > /* jmp .+ 0x3E (_start0x40); nop; nop; nop; nop; nop; nop */ > BYTE $0xEB; BYTE $0x3E; BYTE $0x90; BYTE $0x90 > BYTE $0x90; BYTE $0x90; BYTE $0x90; BYTE $0x90 > > TEXT bipvd(SB), $0 > LONG $0x > TEXT bibootfile(SB), $0 > LONG $0x > TEXT bibootfilelen(SB), $0 > LONG $0x > TEXT bichecksum(SB), $0 > LONG $0x > TEXT bireserved(SB), $0 > LONG $0x > LONG $0x > LONG $0x > LONG $0x > LONG $0x > LONG $0x > LONG $0x > LONG $0x > LONG $0x > LONG $0x > > _start0x40: > CLI > > /* be carefull! do not trash rDL until we reached start() */ > LWI(magic-Xtotal(SB), rSP) > MW(rSP, rBP) > LWI(start(SB), rAX) > > _farret16: > CLR(rCX) > MTSR(rCX, rDS) > MTSR(rCX, rES) > MTSR(rCX, rSS) > PUSHR(rCX) > PUSHR(rAX) > FARRET > > TEXT return16(SB), $0 > MFCR(rCR0, rAX) > XORAL(1) > MTCR(rAX, rCR0) > LWI(return16ret(SB), rAX) > JMP _farret16 > > TEXT return16ret(SB), $0 > STI > RET > > TEXT start(SB), $0 > STI > > SBPB(rDL, Xdrive) > > /* alive! */ > LWI(0x0E03, rAX) > BIOSCALL(0x10) > > /* A20! we has to enable itt! */ > LWI(0x2401, rAX) > BIOSCALL(0x15) > > /* find the primary volume descriptor */ > CLR(rDX) > LWI(0x0010, rAX) > > LWI(0xFF, rCX) > CLR(rBX) > _nextpvd: > CALL16(BIOSread(SB)) > LBPB(Xbuf, rBL) > CMPI(1, rBX) > JEQ _pvdfound > CLR(rBX) > ADDI(1, rAX) > ADC(rBX, rDX) > LOOP _nextpvd > > CALL16(srcherror(SB)) > > _pvdfound: > /* load lba and length of root directory */ > LBPW((Xbuf+156+2), rAX) > LBPW((Xbuf+156+4), rDX) > LBPW((Xbuf+156+10), rCX) > LBPW((Xbuf+156+12), rBX) > > CALL16(walk(SB)) > CALL16(srcherror(SB)) > > TEXT load(SB), $0 > CLR(rCX) > SBPWI(0x, Xcount+0) > SBPWI(0x, Xcount+2) > CALL16(BIOSread(SB)) > > _loop: > PUSHA > CALL16(BIOSread(SB)) > CALL16(movehigh(SB)) > POPA > ADDI(1, rAX) > ADC(rCX, rDX) > JMP _loop > > TEXT BIOSread(SB), $0 > > LWI(5, rDI) /* retry count (ATAPI ZIPs suck) */ > > _retry: > PUSHA > PUSHS(rDS) > PUSHS(rES) > PUSHS(rFS) > PUSHS(rGS) > > SBPW(rAX, Xdap+8) > SBPW(rDX, Xdap+10) > SBPWI(0x0010, Xdap+0) /* reserved + packet size */ > SBPWI(0x0001, Xdap+2) /* # of blocks to transfer */ > MW(rBP, rSI) > ADDI(Xbuf, rSI) > SBPW(rS
Re: [9fans] /sys/lib/newuser patch
On Sun, Apr 11, 2010 at 7:04 PM, EBo wrote: > >> newuser assumes that your home directory exists, and on a >> normal plan 9 install, it's likely not possible to create anything >> in /usr without doing it on the fs console. > > Maybe I am missing something here, but this is not a normal plan9 install, but > 9vx. There I can create a user's directory in $9vx_root/usr provided that the > permissions are open. > > in the base system that came with 9vx I get an error that /src/fscons does not > exist when running "con -l /srv/fscons". > > So, how is the initial setup supposed to be done on 9vx which defaults to a > $user instead of glenda > create the user dir on the host machine. run 9vx -u $user and then run /sys/lib/newuser. you seem to be following the wiki instructions on how to add a new user. they are not valid for 9vx, since it usually uses the hosts filesystem. iru
Re: [9fans] Hi and, plan9-native abaco sources?
On Tue, Mar 11, 2008 at 6:35 AM, prem <[EMAIL PROTECTED]> wrote: > On Mar 10, 10:18 pm, [EMAIL PROTECTED] wrote: > > > Abaco's website is now hosted athttp://abaco.oitobits.net;) > > > > > Thanks! I guess it hasn't made it into the google index yet. > > > > -Sean > > I am unable to compile abaco sources from .../contrib/fgb/ > > draw(im, r, getcolor(i->color), nil, ZP) of drawrule() > > error: > html.c:255 not a member of struct/union : color > > have you bothered reading the thread you are answering?: iru
Re: [9fans] abaco @ plan9port [WAS: Hi and, plan9-native abaco sources?]
On Wed, Mar 12, 2008 at 10:36 AM, erik quanstrom <[EMAIL PROTECTED]> wrote: > > I think this is a bad idea, what if you want to use an alternate > > webfs (on a different NIC), or an non-standard cookies file? do you > > want to wait whilst webcookies rescans it databse at startup and > > webfs rescans its cache (work in progress)? > > > > If we continue this way why not put the code for webfs and and webcookies > > in abaco, and why not include upas and nntpfs too; I guess you can see > where > > this is leading... > > > > I think fgb's simple shell script is an elegant solution, if this is what > > you want (sh to rc translation not withstanding) but keeping webfs and > webcookies > > as long lived external servers has significant benefits - it is The plan9 > way™ > > after all. > > standard slippery slope argument. > > i think that abaco (by inheratance from webfs) may confuse > elegance with unfriendliness. for example, why do i have > to type "http://";? why can't i type "g $query" to google > something? why doesn't esc in the tag highlight like acme? > > abaco is great stuff. this is why i took the time to add a few > of these things to my version. they might not be the height > of elegance. they may not be added in the right place. perhaps > webfs should do this. but usability is important, too. > have you sent your patches to fgb? iru
Re: [9fans] Announcing Vim for Plan 9
On Thu, Mar 13, 2008 at 3:24 PM, andrey mirtchovski <[EMAIL PROTECTED]> wrote: > i thought :colorscheme only worked for vim -g :) > > oh well, here's a reproducible bug: > > start vim, type :colorscheme ron (or whatever you like from > /lib/vim/vimfiles/color/), hit 'i', try to type some text. crash log > attached. > cpu% grep home crash.txt take me back home iru
Re: [9fans] CSS parser for abaco [WAS: abaco @ plan9port]
On Thu, Mar 13, 2008 at 11:58 AM, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > > Hi folks, > > as abaco doesn't yet have CSS support, I intend to write some > tiny CSS parser/loader. > > If we represent the CSS contents as an tree structure, we basicly > have these node types: > > * media type: container for holding media-specific data. > per default we're operating in "all". to make it simplier, > the parse could be told to only honor one specific type. > * @import: tells us to include another file > it could be either resolved within the parsing process by > an call-back or simply added to the output tree > * per-object: has one and more object addresses (eg. via ID, > classname or even some path) and contains a list of properties. > for make it simpler, we can "flatten" multiple addresses by > inserting an copy per single address > * object properties: are just name+value pairs of (almost) > arbitrary strings. some of the values could be also parsed and > split into several other properties (eg. some url() statement > could be replaced by an addittional *-url property). > > While parsing this way into a list of property lists isn't that > challenge, there are still some open questions, eg. should most > of the properties representing specific type of data (eg. borders > and padding) be split off to the finest granilarity and maybe also > identified by an integer ID instead of the name or does this > belong to the client (-> renderer) ? > a css parser is already being added. if you had bothered yourself searching the archives, you'd know that. iru
[9fans] LPL
9fans, in 2007's gsoc I started writing o9fs, a 9p-capable virtual filesystem for openbsd. first I used conv* and some other pieces from Plan 9; them I decided to rewrite based on libixp because of possible licensing problems between LPL code and openbsd's. now I've reread LPL and it got me thinking... can I relicense LPL code to, say, the ISC license? thanks, iru ps: o9fs license: http://gsoc.cat-v.org/hg/o9fs/file/47232d2ef4b7/LICENSE
Re: [9fans] LPL
On Fri, Mar 14, 2008 at 7:01 PM, Russ Cox <[EMAIL PROTECTED]> wrote: > > can I relicense LPL code to, say, the ISC license? > > No. Just like you can't relicense GPL'ed code to ISC, > because the ISC license does not contain all the same > restrictions that the LPL (or GPL) does. > > However, the u9fs source is available under > a license which is essentially equivalent to the > ISC, and the OpenBSD guys would probably have > no problem whatsoever with it. See > /sys/src/cmd/unix/u9fs/LICENSE > good, the pieces I wanted more are in u9fs. thanks russ. iru
Re: [9fans] It looks like our GSoC application was rejected
On Tue, Mar 18, 2008 at 12:32 PM, Skip Tavakkolian <[EMAIL PROTECTED]> wrote: > perhaps a little introspection is needed. was it that they didn't like > the proposals this year or that they didn't like the outcome of last > year's effort? > > or maybe they just want to spread their love. > last year's big problem was the number of failed projects, not the effort made by the organization.
Re: [9fans] It looks like our GSoC application was rejected
On Tue, Mar 18, 2008 at 1:52 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Tue, Mar 18, 2008 at 9:26 AM, Iruata Souza <[EMAIL PROTECTED]> wrote: > > > last year's big problem was the number of failed projects, not the > > effort made by the organization. > > I am going to assume you know this because you know the % of failed > projects for Plan 9, you know the % failed for all other projects, and > you know that all other projects had a lower % failed than Plan 9, and > all these were renewed? Or, better, someone at Google told you? > > Otherwise, if this is idle speculation, we've got the Venti thread for > that one :-) > this is the written down result of my fast introspection. in fact, if you read it again you might note i didn't say anything about gsoc08. iru
Re: [9fans] System call mania
On 3/22/08, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > Hello. I was recently looking in libc when I noticed a few things > about system calls: > > 1) brk and sbrk are implemented atop brk_, which is not documented > 2) the seek function seems to be a system call, but the alpha folder > defines a function seek which calls _seek > 3) Some items in that file have underscores, like BRK_ and _READ > > This leads me to the following question: what exactly are the system > calls in Plan 9? > grep -i syscall /sys/src/9/port iru
Re: [9fans] System call mania
On 3/22/08, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > That confirmed one suspicion: the REAL calls are those who are simply > named in /sys/src/libc/9syscall/sys.h, and that the USER-LEVEL calls > are a big mess in libc. Thanks! > doesn't the name system call suggests you something? iru
Re: [9fans] Drawterm + QEMU
On Tue, Mar 25, 2008 at 3:50 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > Okay, so now that I have drawterm working on my Mac, I'd like to have > it working remotely at my school. Which IP addresses should I use > instead of the localhost to connect to my CPU remotely? > http://web.ncf.ca/ac895/books/opl_seminar_notes.html iru
Re: [9fans] bug in echo?
2008/3/26 Rob Pike <[EMAIL PROTECTED]>: > echo -n -n' > ' > > -rob > > I know this is a silly question, but doesn't this defeats the purpose of the first -n? iru
Re: [9fans] bug in echo?
On Wed, Mar 26, 2008 at 5:56 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > Yes I know what I quoted. I changed the B to a Delta to represent > change and turned dom to doom. YOU ARE THE TARD IF YOU DID NOT GET > THAT. It now reads CHANGE --> DOOM! > > We need to keep echo the same because of the fact we can't agree on > something. > what makes you think agreeing with you is of any relevance? iru
Re: [9fans] bug in echo?
On Wed, Mar 26, 2008 at 7:26 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > I don't care if you agree with Bill Gates on the issue. The problem > is that everyone has about 30 different ways of solving the problem > and there isn't a definite solution that will cause something to > break. Let's face it -- this is 98.438604% futile. > see, even facing this percentage of futileness, you haven't bothered yourself to think what are you doing here. iru
Re: [9fans] 9P support for MC
On Wed, Mar 26, 2008 at 9:02 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > > Hi folks, > > I'd just want to let you know I've added 9P support to the > Midnight Commander (via libmvfs + libmixp). > > cu I'm forwarding this to 9p-hackers. iru
[9fans] hot or not
http://www.ugu.com/sui/ugu/show?I=ugu.hotnot&HN=1113&RT=10 iru
Re: [9fans] Plan 9 refuses to boot from iMac
On Wed, Apr 16, 2008 at 6:45 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > Hello. Tired of waiting for Q's developers to fix the bug resulting in QEMU, > which Q provides a wrapper for, freezing every time I boot, I decided to try > to run Plan 9 on native Mac hardware. I have a December 2006 iMac with a > 2GHz Intel Core 2 Duo. When I boot the iMac from the latest Plan 9 disc, > here's what I get. > > PBSI... Plan 9 from Bell Labs > ELCR... 0C00 > > and everything comes to a halt. This is what I got back on Tiger when I > first joined 9fans. Does anyone know what's wrong? Thanks. > > when tired of waiting we have a friend here called /sys/src/9/pc iru
Re: [9fans] Drawterm not working in Leopard
On Mon, Apr 28, 2008 at 4:12 AM, Juan M. Mendez <[EMAIL PROTECTED]> wrote: > 2008/4/27 Vinícius de Figueiredo Silva <[EMAIL PROTECTED]>: > > > http://web.ncf.ca/ac895/books/opl_seminar_notes.html > > I don't think it's necessary to send so many useless answers, or > wisecracks for something that could be useful (or not) for others > plan9 users. > No matter how obvious it was for you, and since there is all kind of > user experience on the list, the traffic on 9fans maybe grateful. > being it obvious or not, people are expected to try to solve their own problems before asking someone (on 9fans or not) to solve it. there is a word describing the change in the order of these actions: laziness. iru
[9fans] ext2srv
9fans, I have hacked ext2srv to support symlinks so that now, when resolving a name, a walk will present the client with the file pointed to by the link, not the link itself. In hope for it to be useful to someone I have put it under /n/sources/contrib/iru/ext2srv.tgz iru
Re: [9fans] ext2srv
On Tue, May 13, 2008 at 7:32 AM, <[EMAIL PROTECTED]> wrote: > > > Does it still suffer from the 2GB size problem, or s it solved already? > Thanks, > sincerely, I added symlinks because of fgb's (and others) needs. I can take a look on the 2GB issue too if that would help someone. iru
Re: [9fans] ext2srv
On Tue, May 13, 2008 at 9:07 AM, <[EMAIL PROTECTED]> wrote: > would help me much until I get rid of linux completely. I have dirs with big > photos (~ 300MB each) so I had to split them into subdirs to hadle them via > ext2srv. i also tried tofiddle with the source, but I gave up. > since i already got my hands dirty could you, or anyone, explain what are the limits/bugs/constraints you've found using ext2srv? I've heard of the 2gb limit but don't know exactly what it is all about. iru
Re: [9fans] Where is Uriel?
On Mon, May 19, 2008 at 6:57 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > He has been MIA since March 11, and his last cat-v blog update was from > around that time. Isn't he supposed to be taking care of some things, like > the Contrib Index page of the wiki? I just modified his contrindx and > updated it myself. > i have the impression that you doesn't really know what private and public means. iru
Re: [9fans] simulation and newsqueak
On Fri, May 30, 2008 at 7:53 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > Have you done a port of Newsqueak to Plan 9? I tried using Rob's original > code (and failed, albeit not very miserably). > > What do you mean by "monte carlo" - the solitaire? Perhaps a look at the > concept would be helpful. > http://www.isv.uu.se/~ingelman/graduate_school/courses/montecarlo/ iru
Re: [9fans] crosstool fails on gentoo
On Mon, Jun 2, 2008 at 7:32 PM, Roman Shaposhnik <[EMAIL PROTECTED]> wrote: > On Mon, 2008-06-02 at 22:37 +0200, Uriel wrote: >> *yet another layer of complexity so you can look at all that stuff >> at the same time*. >> > all I care about is that it doesn't leak I don't have any solaris boxes to play now, but I remember when taking a dtrace course - more or less two years ago - that I managed to see the performance of a nice machine go down only by setting all it's tracing points. I know that this could be considered normal if it wasn't for the fact that, with two xterms opened, the one which started dtrace, after a series of ^C, had 'transfered' to it the command-line history of the other xterm. It was a peculiar situation since the instructor was telling us about the non-intrusiveness of the tool. iru
Re: [9fans] crosstool fails on gentoo
On Mon, Jun 2, 2008 at 8:21 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 4:00 PM, Iruata Souza <[EMAIL PROTECTED]> wrote: > >> I don't have any solaris boxes to play now, but I remember when taking >> a dtrace course - more or less two years ago - that I managed to see >> the performance of a nice machine go down only by setting all it's >> tracing points. I know that this could be considered normal if it >> wasn't for the fact that, with two xterms opened, the one which >> started dtrace, after a series of ^C, had 'transfered' to it the >> command-line history of the other xterm. It was a peculiar situation >> since the instructor was telling us about the non-intrusiveness of the >> tool. >> > > it's worth reading the papers. Dtrace is quite capable. > > But look at the issues. You are taking a piece of code and splicing in > another piece of code. It can get fun. What if someone was running the > code you are splicing (think: SMP). What about time to remove it: make > sure that (a) nobody is running the spliced in code (how do you do > that in the general case) and (b) nobody is trying to run where you > are putting the code back. What if the original code had an INT > instruction? What if it tickled an IRQ? What if code you spliced in > takes a fault? > > Check out the kprobes device in linux to see how nasty it can get. > > At the same time, people delivering software to end users make good > use of dtrace, so it's kind of hard to fault Sun for putting it in > there -- they do have paychecks to hand out. And I expect that lots of > customers demand that it stay in there ... > just like many people, I have made good use of dtrace myself. but the need for a tool like that seems to me one more evidence of the trend in talk about in your first post. in the pile of layers one has to dig to find/fix/rework something, sometimes dtrace seems like the better - or even the only one at hand - thing to deal with it. put short: dtrace-like tools are good but, in general, having the need for it is not. iru
Re: [9fans] Modularizing plan9port
On Wed, Jun 11, 2008 at 2:53 PM, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > * Uriel <[EMAIL PROTECTED]> wrote: > >> Cross-compiling in Gnu/land is a nightmare not worth going into. > > No, it isn't - as long as you've got a proper toolchain and > get around autoshit. (eg. I've got my own libtool implementation ;-p) > no, it isn't - as long it is.
Re: [9fans] I/O load crashes Qemu
On Sat, Jun 14, 2008 at 1:58 AM, Bruce Ellis <[EMAIL PROTECTED]> wrote: > I don't know how the praise of "excellent" was bestowed on QEMU. It > may work well on a x86 emulating an x86 but try something else. It > ends in tears. > just like opening up an x86 machine and trying to stick a mips processor inside. at the end of the day you get qemu-mips. iru
Re: [9fans] I/O load crashes Qemu
On Sat, Jun 14, 2008 at 9:53 AM, erik quanstrom <[EMAIL PROTECTED]> wrote: >> I don't know how the praise of "excellent" was bestowed on QEMU. It >> may work well on a x86 emulating an x86 but try something else. It >> ends in tears. >> > > this isn't a defense of qemu. i don't know enough about it > to defend it. > > however, why is it a requirement that a vm be able to emulate > other machines? > because it claims to do so? iru
Re: [9fans] P9p's mount(1) on linux
http://swtch.com/v9fs seems to have a nightly updated copy of v9fs in
the linux kernel tree.
On Thu, Jun 19, 2008 at 12:05 AM, Uriel <[EMAIL PROTECTED]> wrote:
> Thanks for your reply, but I'm not clear what you mean: should p9p's
> mount check the kernel version? or are you talking about 9mount?
>
> By the way, where can one find the git tree with the latest v9fs? I
> was googling and struggling with the swik 'thing' (words fail me...),
> but couldn't find it, I know it is somewhere...
>
> Also any other feedback on what changes and improvements 9mount might
> need before it can be made part of p9p (or maybe shipped with the
> standard linux mount(1) tools?).
>
> uriel
>
> On Thu, Jun 19, 2008 at 3:57 AM, Eric Van Hensbergen <[EMAIL PROTECTED]>
> wrote:
>> because I'm difficult you may need to check the version of the kernel
>> you are running, some of the options syntax has changed and you may
>> want to set some of the newer security options (the access option) to
>> be more consistent with the Plan 9 mindset.
>>
>> -eric
>>
>> On Wed, Jun 18, 2008 at 8:42 PM, Uriel <[EMAIL PROTECTED]> wrote:
>>> Here is a tinny patch to make p9p's mount(1) work on linux even if you
>>> have the v9fs (or fuse *yuck*) modules built into your kernel rather
>>> than as modules.
>>>
>>> Still there is the issue of what to do if you are not root, maybe a
>>> 9pmount helper program that is suid could take care of this? Sqweek
>>> wrote a very nice 9mount program (
>>> http://sqweek.dnsdojo.org/code/9mount/docs ) that maybe could be
>>> added to p9p, unfortunately v9fs has changed its interface/params once
>>> more and 9mount doesn't work with recent kernels *sigh*
>>>
>>> Peace and best wishes
>>>
>>> uriel
>>>
>>> P.S.: Can someone please forward this to russ, last I heard he had my
>>> email address in his kilfile.
>>>
>>> diff -r fe7a4a762f75 bin/mount
>>> --- a/bin/mount Sun Jun 15 01:46:23 2008 -0400
>>> +++ b/bin/mount Thu Jun 19 03:41:08 2008 +0200
>>> @@ -6,12 +6,12 @@
>>> }
>>> switch(`{uname}){
>>> case Linux
>>> - if(lsmod|9 grep -si '^9p(2000)? '){
>>> + if(cat /proc/filesystems|9 grep -si ' 9p(2000)?$'){
>>>if(u test -S $1)
>>>exec u mount -t 9p -o proto'='unix,name'='$USER $1 $2
>>>exec u mount -t 9p -o proto'='tcp,name'='$USER $1 $2
>>>}
>>> - if(lsmod|9 grep -si '^fuse ')
>>> + if(cat /proc/filesystems|9 grep -si ' fuse$')
>>>exec 9pfuse $1 $2
>>>echo 'don''t know how to mount (no 9p, no fuse)' >[1=2]
>>> case FreeBSD
>>>
>>>
>>
>>
>
>
--
iru
Re: [9fans] Getting drawterm to work in Leopard (again)
On Thu, Jun 19, 2008 at 3:08 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > Hello. I'm trying to get drawterm to work in Leopard again. Here is my > command line: > >drawterm-osx-intel -c 'tcp!127.0.0.1!17010' -a 'tcp!127.0.0.1!2567' > -s 'tcp!127.0.0.1!5356' -u pietro > is connecting to 127.0.0.1 really what you want? i ask 'cause i dont know how qemu networking under osx works. iru
Re: [9fans] 9vx on OpenBSD-4.3
On Mon, Jun 30, 2008 at 3:15 PM, Iruata Souza <[EMAIL PROTECTED]> wrote: > On Mon, Jun 30, 2008 at 3:04 PM, Tim Wiess <[EMAIL PROTECTED]> wrote: >> If you can wait a couple days I'll have some time later in the >> week to port this over to OpenBSD. >> >> >>> I'm currently trying to get 9vx work on OpenBSD-4.3 (i386, 750Mhz, >>> 256MB RAM), but each time I want to start 9vx I get the following: >>> >>> $ ./9vx.FreeBSD -u glenda >>> Abort Trap >>> $ >>> >>> Of course FreeBSD Binary Emulation has been turned on using >>> /etc/sysctl.conf. >>> >>> Furthermore I tried also to use the Linux binary (using the Linux >>> Emulation, which I also switched on), but I get the same message back >>> in this case too. >>> >>> If you need some more informations about the system, drop me a line. >>> >>> Any hints how to solve this problem welcome >>> >>> Thanks, >>> Malik > I started the porting some days ago. Seems the only missing part is > one bit in i386_set_ldt. > I can upload it somewhere if anyone want to play with the missing stuff. > correcting myself: it's the only missing part now that i've done some work. iru
Re: [9fans] 9vx on OpenBSD-4.3
On Mon, Jun 30, 2008 at 3:04 PM, Tim Wiess <[EMAIL PROTECTED]> wrote: > If you can wait a couple days I'll have some time later in the > week to port this over to OpenBSD. > > >> I'm currently trying to get 9vx work on OpenBSD-4.3 (i386, 750Mhz, >> 256MB RAM), but each time I want to start 9vx I get the following: >> >> $ ./9vx.FreeBSD -u glenda >> Abort Trap >> $ >> >> Of course FreeBSD Binary Emulation has been turned on using /etc/sysctl.conf. >> >> Furthermore I tried also to use the Linux binary (using the Linux >> Emulation, which I also switched on), but I get the same message back >> in this case too. >> >> If you need some more informations about the system, drop me a line. >> >> Any hints how to solve this problem welcome >> >> Thanks, >> Malik I started the porting some days ago. Seems the only missing part is one bit in i386_set_ldt. I can upload it somewhere if anyone want to play with the missing stuff. iru
Re: [9fans] sad commentary
On Mon, Jun 30, 2008 at 6:20 PM, Eris Discordia <[EMAIL PROTECTED]> wrote: > Barring a "mystical" bond with its exquisite kernel, of course. > it seems you have done much kernel programming, eh? iru
Re: [9fans] sad commentary
On Tue, Jul 1, 2008 at 4:47 AM, Eris Discordia <[EMAIL PROTECTED]> wrote: > On the contrary, while I do like using keyboard I'm very much a "polymath." > Mouses are very good input devices for certain applications. The way the > mouse is used--or "abused"--in rio and acme poses a problem. It is the "easy > way out" to attribute that to my--probably Windows-doped--taste. There "is" > a least common denominator that accommodates the basics of all tastes, and > "that" is lacking in rio. I'm glad you are explicitly basing your claims. again, I'm glad to see you consider your audience on this list to be outside *your* common denominator. I'm even more and more glad to see I got basic tastes in common with a prisoner in the other side of the planet walking in the deathrow. thanks for the enlightenment. iru
Re: [9fans] sad commentary
On Tue, Jul 1, 2008 at 4:47 AM, Eris Discordia <[EMAIL PROTECTED]> wrote: > Window decorations (as they're called in X-speak) are not "mere > decorations," they're useful. The two button (+/- wheel) mouse is prevalent > because for most people only the index and middle finger are robust enough. > The ring finger is never on par with them, except of course with the > unnecessary adjustment Plan 9 users seem to go through. Assigning the middle > finger to both second and third buttons is another solution which is equally > uncomfortable. > I see you have been doing a lot of research on ergonomics. > Microsoft certainly has put a lot of money into researching human > interfacing and the outcome is free for all to get and implement. Don't > think for a moment that because it's Microsoft it has to be taken lightly. > Hundreds of small rounded corners have made the Windows GUI experience a > much better experience than that of "any" alternative GUI. > of course I agree your personal opinions could be taken as representatives of human kind's opinions but, just in case, would you mind showing the results of your great research on the subject? thanks, iru
Re: [9fans] sad commentary
On Tue, Jul 1, 2008 at 5:25 AM, Eris Discordia <[EMAIL PROTECTED]> wrote: > All these could "theoretically" become "supported" (that's different from > being "included") in an OS if it manages to gather enough public momentum. > Without that you can do only your "serious" stuff which excludes quite some > of the "good" stuff. Public momentum comes from providing "the public" with > enough incentive so that a small portion of that public actually writes what > the rest will need. > like you do with your system, right? > Incidentally, I find it a bit hypocritical to do "research" (read: find out > how a system can Get New Jobs Done (tm)) on a system but turn to another > whenever one actually needs to Get Something Done (tm). > sorry if I can't write a flash player in two minutes. it won't happen again. iru
Re: [9fans] sad commentary
On Tue, Jul 1, 2008 at 5:42 AM, Eris Discordia <[EMAIL PROTECTED]> wrote: > A stand-alone Plan 9 system amounts in conceptual complexity "for > the user" to at least three interconnected machines. Very little has been > done to cover that. > does distributed gets translated to something else in your web browser? iru
Re: [9fans] sad commentary
On Tue, Jul 1, 2008 at 5:01 AM, Eris Discordia <[EMAIL PROTECTED]> wrote: > "For Dummies" books are essentially non sequiturs arising from marketing > schemes. RTFM is really the way to go, but you need to have an "incentive," > a "promise," to RTFM. Obviously, sometimes the incentive is replaced by a > compelling to obey company/university/institution policies. I'm glad to see curiosity or research are not incentive nor promise. thanks, iru
Re: [9fans] 9vx on OpenBSD-4.3
On Fri, Jul 4, 2008 at 8:00 PM, Malik Bazz <[EMAIL PROTECTED]> wrote: > Just curious, did your porting attempt suceed? > > Hope you'll post some news for the OpenBSD port here... > sorry for not reporting until now. I´m not at home and have no access to my tree right now, but I can already run 9vx. console says the kernel is getting 0M of memory. that is surely because of my hacks. I only wished it to compile. now it's time for me to understand the code and write/modifiy the necessary bits for it to run correctly. If you can wait until next Wednesday, i´ll upload it. thanks for asking, iru
Re: [9fans] 9vx on OpenBSD-4.3
On Thu, Jul 10, 2008 at 4:02 PM, Malik Bazz <[EMAIL PROTECTED]> wrote: > Me again - Were you successfull in porting 9vx to OpenBSD? > If you need some testing help, contact me. > http://iru.oitobits.net/src/vx32-0.10-openbsd-compiled.tgz I guess you'll have problems compiling. Let me know if you do. thanks, iru
Re: [9fans] 9vx on OpenBSD-4.3
On Thu, Jul 10, 2008 at 4:11 PM, Brian L. Stuart <[EMAIL PROTECTED]> wrote: >> Me again - Were you successfull in porting 9vx to OpenBSD? >> If you need some testing help, contact me. > > Speaking of that, does anyone have an idea where NetBSD > would fit into that? Of the bunch, that's the one I've > used most and have deployed in the most places. I > would think there would be some hope that an OpenBSD > port would also work on NetBSD, but they forked long > enough ago that threading could well be completely > different. > NetBSD is closer from OpenBSD than OpenBSD is from FreeBSD. so, you may want to build and test my little changes. iru
