Re: [9fans] Pegasus 2.6 is released
On Mon, Feb 2, 2009 at 8:26 PM, wrote: >> maybe we could dispense with the kernel. >> it's complicated anyway. each application could drive >> hardware itself. but to make this easier, we'll used shared >> libraries. the only system service we'd need is a shared library >> loader. um, sadly, this *is* the norm nowadays in HPC. And here you all thought you were joking. ron
Re: [9fans] Sources Gone?
>> I'm not sure how you'd fix this. What if only a portion of the block >> belongs to me and the other happens to be the password file? > > venti just stores whole blocks. Yes, but the content isn't guaranteed to be from a single user. In fact, venti has no clue. Change that and it's not venti anymore. ++L
Re: [9fans] Sources Gone?
> > The one and only fundamental limitation of the current interface > > offered by venti is that I can give it a score to something that > > doesn't belong to me and it gives me the information back. It is > > the limitation of the API, not the way data is managed. > > I'm not sure how you'd fix this. What if only a portion of the block > belongs to me and the other happens to be the password file? venti just stores whole blocks. if it did as you suggest, that would be a neat trick. the arenas would reach a maximum size of 256 bytes. (assuming you stored unique bytes). everything else would be index. but, oh, what an index that'd be. > You need to draw boundaries at different security entities and that makes > compression and especially duplicate suppression much less effective. i'm repeating myself, but that's nothing new. i don't think you do need to draw boundraries. it's turtles all the way UP. given an arbitrarly large tree, a single change to any leaf will propagate all the way up creating a new path to the root. in this respect, libventi trees are very similar to ken's fs. the only assumption i'm making is that eactly this tree has not been stored before. so really, if you don't give out the root score, venti won't give you up. - erik
Re: [9fans] Pegasus 2.6 is released
Or as Mark V. Shaney once said ... "Why can't everyone wake up at 3am, totally confused". I'm not sure of the relevance. brucee On Tue, Feb 3, 2009 at 3:26 PM, wrote: >> maybe we could dispense with the kernel. >> it's complicated anyway. each application could drive >> hardware itself. but to make this easier, we'll used shared >> libraries. the only system service we'd need is a shared library >> loader. > > There's your final word in microkernels. Throw away security and > things get a lot less complicated. The human brain does not have, > that I am aware, security boundaries, why can't we model our personal > computers on that? > > ++L > > PS: In jest, of course, but there's some value... > > >
Re: [9fans] Pegasus 2.6 is released
> maybe we could dispense with the kernel. > it's complicated anyway. each application could drive > hardware itself. but to make this easier, we'll used shared > libraries. the only system service we'd need is a shared library > loader. There's your final word in microkernels. Throw away security and things get a lot less complicated. The human brain does not have, that I am aware, security boundaries, why can't we model our personal computers on that? ++L PS: In jest, of course, but there's some value...
Re: [9fans] Sources Gone?
> The one and only fundamental limitation of the current interface > offered by venti is that I can give it a score to something that > doesn't belong to me and it gives me the information back. It is > the limitation of the API, not the way data is managed. I'm not sure how you'd fix this. What if only a portion of the block belongs to me and the other happens to be the password file? You need to draw boundaries at different security entities and that makes compression and especially duplicate suppression much less effective. You could argue that the security information provides its own boundaries, but making venti aware of them does add a lot of complications that in my opinion should be (and already are) solved elsewhere. I did propose that compression and encryption ought to be concurrent in venti, but that solves only part of the problem and raises new problems such as key management. ++L PS: As for the problem we're trying to solve, I'm afraid I've long ago lost track :-)
Re: [9fans] Sources Gone?
> Depends on how you look at it. From the drive's perspective -- you're > right. Nobody owns blocks. However, if a certain block happens > to be part of a filesystems that uses this particular drive then > the ownership can and will be tracked. the problem comes in the fact that as far as venti is concerned, there is no filesystem. the heirarchy bits are done in libventi, so > The proxy API will have to track the ownership. And it is very likely to > be more hierarchy-oriented, than stand-alone blocks-oriented. protecting your root notes boils down to a matter of protecting your root scores, since we assume that 2^80 is big enough to deter guessing. i don't see how a proxy will add security. could you explain what attack vector you're worried about? i would think that the least secure part of this is the unencrypted transmission. - erik
Re: [9fans] Sources Gone?
On Mon, 2009-02-02 at 17:43 -0500, erik quanstrom wrote: > > I don't think it does. At least not in a way that is obvious to me. > > The one and only fundamental limitation of the current interface > > offered by venti is that I can give it a score to something that > > doesn't belong to me and it gives me the information back. It is > > the limitation of the API, not the way data is managed. IOW, if > > a block that I genuinely own happens to also be referenced from > > a hierarchy that I do NOT have access to -- its ok. > > ownership doesn't mean anything at the venti level. it really > is just a virtual disk drive with lba80 content addressing. > one doesn't "own" blocks on a regular disk drive, either. Depends on how you look at it. From the drive's perspective -- you're right. Nobody owns blocks. However, if a certain block happens to be part of a filesystems that uses this particular drive then the ownership can and will be tracked. > suspending the preceeding logic for a bit, supposing that > you did "track ownership", then No need to suspend the logic and run this thought experiment. I have no interest in assigning ACL to blocks. That's why I said that the API that venti currently has is ill-suited for the kind of public usage I have in mind. That doesn't mean that it should be replaced or mutilated. It simply means firewalling in a spirit of venti/ro The proxy API will have to track the ownership. And it is very likely to be more hierarchy-oriented, than stand-alone blocks-oriented. Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
On Mon, Feb 2, 2009 at 2:30 PM, Anthony Sorace wrote: > erik wrote: > > > it's interesting to compare this with the sleezy not-paths > > that e.g. gnome programs can take, like uris. great as long > > as long as you don't care to use anything but gnome tools. > > i had that debate with a kde-loving linux admin. i had been explaining > why plan 9 was interesting or significant, and he countered with the > kde example. i was marginally impressed by the number of protocols > they handled, but when i asked how you'd use it with cat and friends, > he said "no, just use kate". > > i reeled, stuttered, tried to get out something that sounded like > "layering violation", and ran away. it wasn't even a cost/benefit > argument; there wasn't any recognition of the costs. > > Right but when you consider KDE runs on windows, then it's not as much of a layering violation... no more than Java is I guess anyway. The layering violation that I usually point at is the /dev/tcp created by the bash shell :-).
[9fans] Vac failing
Hi, When running vac from Plan 9 port, against a venti running on Unix, we get these errors: <... lots of vac -v output ...> cache block 501: type 8 score 1f6 iostate 1 addr 502 ref 0 nlock 1 cache block 502: type 8 score 1f7 iostate 1 addr 503 ref 0 nlock 1 cache block 503: type 8 score 1f8 iostate 1 addr 504 ref 0 nlock 1 (output goes up to score 200). vtcachebumpblock: no free blocks in vtCachezsh: IOT instruction ./vac -s -v -h tcp!acm.jhu.edu!17034 /export/home And vac stops. This happens at the same place in /export/home every time we try to run vac. Has anyone ever seen anything like this? -- vs
Re: [9fans] Pegasus 2.6 is released
Can I just say hahahahahahaha. Or maybe welcome to the 80's. brrucee On Tue, Feb 3, 2009 at 9:57 AM, Anthony Sorace wrote: > you, um... never mind. what can i say? > > http://www.gnu.org/manual/gawk/html_node/Special-Network.html#Special-Network > >
Re: [9fans] Pegasus 2.6 is released
you, um... never mind. what can i say? http://www.gnu.org/manual/gawk/html_node/Special-Network.html#Special-Network
Re: [9fans] Sources Gone?
> I don't think it does. At least not in a way that is obvious to me. > The one and only fundamental limitation of the current interface > offered by venti is that I can give it a score to something that > doesn't belong to me and it gives me the information back. It is > the limitation of the API, not the way data is managed. IOW, if > a block that I genuinely own happens to also be referenced from > a hierarchy that I do NOT have access to -- its ok. ownership doesn't mean anything at the venti level. it really is just a virtual disk drive with lba80 content addressing. one doesn't "own" blocks on a regular disk drive, either. suspending the preceeding logic for a bit, supposing that you did "track ownership", then each block could have any number of owners. this would mean that you couldn't store n copies of a block for the cost of one block's storage. you would need to allocate some storage for each time the block is stored to track ownership. - erik
Re: [9fans] Pegasus 2.6 is released
> i had that debate with a kde-loving linux admin. i had been explaining > why plan 9 was interesting or significant, and he countered with the > kde example. i was marginally impressed by the number of protocols > they handled, but when i asked how you'd use it with cat and friends, > he said "no, just use kate". > > i reeled, stuttered, tried to get out something that sounded like > "layering violation", and ran away. it wasn't even a cost/benefit > argument; there wasn't any recognition of the costs. does he also plans to build a tcp/ip stack into his applications? maybe we could dispense with the kernel. it's complicated anyway. each application could drive hardware itself. but to make this easier, we'll used shared libraries. the only system service we'd need is a shared library loader. - erik
Re: [9fans] Pegasus 2.6 is released
> not me. But a depressingly large number of people do, nowadays. i don't drink enough to keep up with modern developments. - erik
Re: [9fans] Pegasus 2.6 is released
On Mon, Feb 2, 2009 at 2:14 PM, erik quanstrom wrote: >> I hate to be the one to bring this up but ... if you are providing >> some extended (e.g.) math functionality to a program with a shared >> library, people are going to be upset with you if you argue that it >> can be done with RPC. > > i thought we were talking about linking c into scripting languages. > you're not using python to actually do the calcuations, are you? > not me. But a depressingly large number of people do, nowadays. ron
Re: [9fans] Sources Gone?
On Fri, 2009-01-30 at 07:18 +0200, lu...@proxima.alt.za wrote: > > Some level of smartness in how block traversal is made needs to > > be there. > > That involves partitioning, which defeats the fundamental mechanics of > venti. I don't think it does. At least not in a way that is obvious to me. The one and only fundamental limitation of the current interface offered by venti is that I can give it a score to something that doesn't belong to me and it gives me the information back. It is the limitation of the API, not the way data is managed. IOW, if a block that I genuinely own happens to also be referenced from a hierarchy that I do NOT have access to -- its ok. > It then becomes preferable to run distinct venti services, > which is the only way in which different backing stores can be used at > this stage. Hm. I guess I need to understand what is the problem you seem to be worried about. Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
erik wrote: > it's interesting to compare this with the sleezy not-paths > that e.g. gnome programs can take, like uris. great as long > as long as you don't care to use anything but gnome tools. i had that debate with a kde-loving linux admin. i had been explaining why plan 9 was interesting or significant, and he countered with the kde example. i was marginally impressed by the number of protocols they handled, but when i asked how you'd use it with cat and friends, he said "no, just use kate". i reeled, stuttered, tried to get out something that sounded like "layering violation", and ran away. it wasn't even a cost/benefit argument; there wasn't any recognition of the costs.
Re: [9fans] Pegasus 2.6 is released
On Mon, 2009-02-02 at 23:22 +0100, Francisco J Ballesteros wrote: > But can't you `script' by calling an external program, sending it your > input, and reading its output? Well, the way I see it: exec'ing is just a way to get to a transient channel. Its no different from that very same channel being present permanently in /srv or /mnt/factotum/rpc. There's *slightly* less overhead with pipes, but that's about it. Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
But can't you `script' by calling an external program, sending it your input, and reading its output? I understand that if you have a language (say limbo) that requires loadable modules then it's another thing. However, if you want, say, to be able to process web pages or whatever just by applying different modules. Why can't them be different processes? You can just pipe your data through them. On Mon, Feb 2, 2009 at 11:18 PM, Roman V. Shaposhnik wrote: > On Mon, 2009-02-02 at 14:12 -0800, ron minnich wrote: >> On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach wrote: >> >> > They solve the same class of problems, if you step back far enough. >> > If your application's mechanism of dealing with processing is to use the >> > namespace, then binding new functionality over old is roughly equivalent to >> > a plugin mechanism. >> >> >> I hate to be the one to bring this up but ... if you are providing >> some extended (e.g.) math functionality to a program with a shared >> library, people are going to be upset with you if you argue that it >> can be done with RPC. >> >> I hope the reason is obvious :-) > > It is. It is a trivial case, after all. In non-trivial ones, the > same kind of discussion used to be quite popular in OpenMP vs. > MPI circles. And I shouldn't be the one to tell you where it > is going, right? > > Thanks, > Roman. > > >
Re: [9fans] Pegasus 2.6 is released
On Mon, 2009-02-02 at 14:12 -0800, ron minnich wrote: > On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach wrote: > > > They solve the same class of problems, if you step back far enough. > > If your application's mechanism of dealing with processing is to use the > > namespace, then binding new functionality over old is roughly equivalent to > > a plugin mechanism. > > > I hate to be the one to bring this up but ... if you are providing > some extended (e.g.) math functionality to a program with a shared > library, people are going to be upset with you if you argue that it > can be done with RPC. > > I hope the reason is obvious :-) It is. It is a trivial case, after all. In non-trivial ones, the same kind of discussion used to be quite popular in OpenMP vs. MPI circles. And I shouldn't be the one to tell you where it is going, right? Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
> Right. That plus the fact that the "plugin" is now generally available > over the network makes it much more interesting. > > In fact, these current trend towards REST in web services seems > to be a validation of 9P view of the world. it's interesting to compare this with the sleezy not-paths that e.g. gnome programs can take, like uris. great as long as long as you don't care to use anything but gnome tools. i suppose you could link sed &c against gnome. but that's crass, even by linux standards. - erik
Re: [9fans] Pegasus 2.6 is released
> I hate to be the one to bring this up but ... if you are providing > some extended (e.g.) math functionality to a program with a shared > library, people are going to be upset with you if you argue that it > can be done with RPC. i thought we were talking about linking c into scripting languages. you're not using python to actually do the calcuations, are you? - erik
Re: [9fans] Pegasus 2.6 is released
On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach wrote: > They solve the same class of problems, if you step back far enough. > If your application's mechanism of dealing with processing is to use the > namespace, then binding new functionality over old is roughly equivalent to > a plugin mechanism. I hate to be the one to bring this up but ... if you are providing some extended (e.g.) math functionality to a program with a shared library, people are going to be upset with you if you argue that it can be done with RPC. I hope the reason is obvious :-) ron
Re: [9fans] Pegasus 2.6 is released
On Mon, 2009-02-02 at 13:32 -0800, David Leimbach wrote: > I mean sure you could use FTP to transfer files, but the old shell > based tools are automagically plugged in with network capabilities > when they deal with a FTP backed namespace right? So without any > binary loader capabilities "cp" "mv" and other existing "small > programs" are now "plugged in". Right. That plus the fact that the "plugin" is now generally available over the network makes it much more interesting. In fact, these current trend towards REST in web services seems to be a validation of 9P view of the world. Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
On Mon, 2009-02-02 at 13:22 -0800, John Barham wrote: > > You're missing the beauty of 9p. Who needs dynload() when you have > mount()? > > Mount allows me to add new names to the process namespace. Dynload > allows me to call functions or access data in a library that is not > known to the process (e.g., scripting language interpreter) until > runtime. They solve different problems. Depends on your point of view. Except for accessing data directly in the same address space, dynload() is just a way of doing fast RPC. In that line of thought, 9P offers you a very similar mechanism. I think the most obvious example of how 9P can be used to provide the kind of extensibility that folks usually associate with dynload() is factotum. Especially if you compare it with things like PAM. Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
On Mon, Feb 2, 2009 at 1:22 PM, John Barham wrote: > > You're missing the beauty of 9p. Who needs dynload() when you have > mount()? > > Mount allows me to add new names to the process namespace. Dynload > allows me to call functions or access data in a library that is not > known to the process (e.g., scripting language interpreter) until > runtime. They solve different problems. They solve the same class of problems, if you step back far enough. If your application's mechanism of dealing with processing is to use the namespace, then binding new functionality over old is roughly equivalent to a plugin mechanism. I mean sure you could use FTP to transfer files, but the old shell based tools are automagically plugged in with network capabilities when they deal with a FTP backed namespace right? So without any binary loader capabilities "cp" "mv" and other existing "small programs" are now "plugged in". Dave > > > John > >
Re: [9fans] Pegasus 2.6 is released
>> You're missing the beauty of 9p. Who needs dynload() when you have mount()? > > Mount allows me to add new names to the process namespace. Dynload > allows me to call functions or access data in a library that is not > known to the process (e.g., scripting language interpreter) until > runtime. They solve different problems. there is no fundamental reason they could not solve the same problem. why are you so keen to remove the rpc? - erik
Re: [9fans] Pegasus 2.6 is released
> You're missing the beauty of 9p. Who needs dynload() when you have mount()? Mount allows me to add new names to the process namespace. Dynload allows me to call functions or access data in a library that is not known to the process (e.g., scripting language interpreter) until runtime. They solve different problems. John
Re: [9fans] Pegasus 2.6 is released
> On Sun, Feb 1, 2009 at 4:27 PM, John Barham wrote: >> Dynamic loading allows scripting languages to load arbitrary binary >> extensions at run-time. Without dynamic loading in Plan 9... > > You're missing the beauty of 9p. Who needs dynload() when you have mount()? this thinking goes back to the beginning with pipes and the shell. to use object-oriented language out of place, any program that produces or consumes a byte stream can be extended by another program that produces or consumes a byte stream. with a thread library program that passes messages on channels, one could do similar extensions by replacing one end of the channel in a similar manner to replacing a program in a regular pipe. though message typing would limit the generality of the arrangement. - erik
Re: [9fans] Pegasus 2.6 is released
On Tue, 2009-02-03 at 04:25 +0900, sqweek wrote: > On Sun, Feb 1, 2009 at 4:27 PM, John Barham wrote: > > Dynamic loading allows scripting languages to load arbitrary binary > > extensions at run-time. Without dynamic loading in Plan 9... > > You're missing the beauty of 9p. Who needs dynload() when you have mount()? I was going to say exactly that! dynload() is really not very well suited for a highly distributed age. I have come to realize that it is nothing but an unfortunate optimization of R out of RPC. Now, making 'R' fast (if your caller-callee is on the same node, etc) is very much desired. Trying to get rid of it, or pretend that it is not needed -- is doomed. Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
On Sun, Feb 1, 2009 at 4:27 PM, John Barham wrote: > Dynamic loading allows scripting languages to load arbitrary binary > extensions at run-time. Without dynamic loading in Plan 9... You're missing the beauty of 9p. Who needs dynload() when you have mount()? -sqweek
Re: [9fans] 9vx as a cpu server?
>why hasn't that old unix restriction been removed yet? the old ones are best. there's nothing like a really good candle. it couldn't be prised from their cold dead hands. think of the expense! i came across it recently, and couldn't quite believe it myself.
Re: [9fans] Pegasus 2.6 is released
On Mon, Feb 2, 2009 at 9:38 AM, John Barham wrote: >> using a variant of something we developed and then >> re-developed for Inferno, you can dynamically load >> C modules at run time, and unusually, with type checking, >> with support in the compilers and loaders. > > Is the code to do this available for public consumption? > > I think we're going in circles again. IIRC my discussion of dynload for python should point at what Charles et. al. enabled and what I subsequently used to do dynload for python, which is usable in general, esp. if your code is type-safe (unlike Python). ron
Re: [9fans] Pegasus 2.6 is released
> using a variant of something we developed and then > re-developed for Inferno, you can dynamically load > C modules at run time, and unusually, with type checking, > with support in the compilers and loaders. Is the code to do this available for public consumption?
Re: [9fans] 9vx as a cpu server?
> They depend on it now more than ever. Don't believe me? Just look at > what port many people use for NFS nowadays. > > Lots of bad things have never been fixed, and this is one of them. I > guess it's more fun to lard GUI software over top and hope nobody > notices. too bad that there seems to be more willingness to break perfectly okay interfaces that there is to fix broken interfaces. the compatability argument seems to run counter common sense in both cases. - erik
Re: [9fans] 9vx as a cpu server?
On Mon, Feb 2, 2009 at 8:54 AM, roger peppe wrote: > why hasn't that old unix restriction been removed yet? > is there any point to it at all any more? They depend on it now more than ever. Don't believe me? Just look at what port many people use for NFS nowadays. Lots of bad things have never been fixed, and this is one of them. I guess it's more fun to lard GUI software over top and hope nobody notices. ron
Re: [9fans] 9vx as a cpu server?
why hasn't that old unix restriction been removed yet? is there any point to it at all any more? localhost-only announcing i suppose. 2009/2/2 Roman V. Shaposhnik : > On Sun, 2009-02-01 at 20:27 -0800, Russ Cox wrote: >> as for listening, 9vx by default uses the host ip stack, >> and plan 9 services tend to use their own port numbers, > > And sometimes these port # tend to be < 1024 which means that > you have to run 9vx as root. > > Thanks, > Roman. > > >
Re: [9fans] 9vx as a cpu server?
On Sun, 2009-02-01 at 20:27 -0800, Russ Cox wrote: > as for listening, 9vx by default uses the host ip stack, > and plan 9 services tend to use their own port numbers, And sometimes these port # tend to be < 1024 which means that you have to run 9vx as root. Thanks, Roman.
Re: [9fans] Flash Video
2009/2/2 Akshat Kumar : > 2009/2/2 Skip Tavakkolian <9...@9netics.com>: >> it might require a c-section. >> might want to start with VLC or ffmpeg. >> > > My aim was just to get 9fans talking about it. > Hence, the pushing. > > But yes, what information can you provide > about either of those, with regards to porting > or creating natively? The Flash file format is an open standard (http://www.adobe.com/devnet/swf/). To be useful for encoded video, you'd need a VP6 codec (which seems lolno) and x264. It would probably be possible to do at least the x264 stuff via ffmpeg, which is probably not too difficult to port -- it's pretty simple code and the codecs are easily portable. To be useful for anything else, you'd also need a bytecode interpreter that understood the compiled actionscript -- it's just a bytecode-compiled ECMAScript, and I believe its details are also found in that PDF. The rest is being able to display JPG/PNG raster images and antialiased TTF and vectors. (Flash allows you to embed fonts into the generated SWF output as well). --dho > ak > >
Re: [9fans] Flash Video
2009/2/2 Skip Tavakkolian <9...@9netics.com>: > it might require a c-section. > might want to start with VLC or ffmpeg. > My aim was just to get 9fans talking about it. Hence, the pushing. But yes, what information can you provide about either of those, with regards to porting or creating natively? ak
Re: [9fans] Flash Video
> if I push hard enough, > I just might give birth to a monster it might require a c-section. might want to start with VLC or ffmpeg.
