> 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.
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 nativel
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 servic
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 b
> 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?
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 avail
>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.
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()
> 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
> 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 so
>> 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
> runtim
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 proces
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 proc
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" "
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 thought we were talking about linking c into scripting languages
> 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
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 func
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 applyin
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 bei
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
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
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 th
> not me. But a depressingly large number of people do, nowadays.
i don't drink enough to keep up with modern developments.
- erik
> 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
> 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,
> 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,
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
you, um... never mind. what can i say?
http://www.gnu.org/manual/gawk/html_node/Special-Network.html#Special-Network
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
>
>
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
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.
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-lov
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
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
> 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
> 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
> 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 secu
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
> > 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
>> 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 vent
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,
42 matches
Mail list logo
