On Tue, Dec 19, 2000 at 09:42:05AM +0100, Mikulas Patocka wrote:
> Failing getblk would likely introduce filesystem corruption. Look at
> getblk in 2.0 - when allocating new page fails it tries to reuse existing
> clean buffers or wakes up bdflush and waits until it writes them. This is
> the righ
On Tue, 19 Dec 2000, Andrea Arcangeli wrote:
> On Mon, Dec 18, 2000 at 10:57:44PM +0100, Mikulas Patocka wrote:
> > You have small posibility that interrupt will eat up memory - interrupt in
> > process that has PF_MEMALLOC. Patch:
>
> this is not the point of getblk, to fix the getblk deadlock
On Mon, Dec 18, 2000 at 10:57:44PM +0100, Mikulas Patocka wrote:
> You have small posibility that interrupt will eat up memory - interrupt in
> process that has PF_MEMALLOC. Patch:
this is not the point of getblk, to fix the getblk deadlock the only way is to
implement a fail path in each caller
> > Imagine that kpiod is slow. try_to_swap_out returns 1 and pretends it
> > freed something but it didn't. It just passed request to kpiod. There are
> > no pages to be freed by shrink_mmap. do_try_to_swap_out calls swap_out
> > several times, then returns. And this repeats again and again.
>
>
> Imagine that kpiod is slow. try_to_swap_out returns 1 and pretends it
> freed something but it didn't. It just passed request to kpiod. There are
> no pages to be freed by shrink_mmap. do_try_to_swap_out calls swap_out
> several times, then returns. And this repeats again and again.
kpiod cease
On Mon, 18 Dec 2000, Rik van Riel wrote:
> On Mon, 18 Dec 2000, Andrea Arcangeli wrote:
> > On Mon, Dec 18, 2000 at 06:29:24PM -0200, Rik van Riel wrote:
> > > Wrong. Getblk won't deadlock, it will just sleep and another
> >
> > getblk will deadlock.
>
> OUCH. The only protection we have agains
On Mon, 18 Dec 2000, Rik van Riel wrote:
> On Sat, 16 Dec 2000, Mikulas Patocka wrote:
>
> > > Not unless your driver is broken.
> >
> > ok_to_allocate:
> > *** INTERRUPT
> > spin_lock_irqsave(&page_alloc_lock, flags);
> > /* if it's not a dma request, t
On Mon, 18 Dec 2000, Andrea Arcangeli wrote:
> On Mon, Dec 18, 2000 at 06:29:24PM -0200, Rik van Riel wrote:
> > Wrong. Getblk won't deadlock, it will just sleep and another
>
> getblk will deadlock.
OUCH. The only protection we have against this is the fact
that atomic allocations are not allow
On Mon, Dec 18, 2000 at 06:29:24PM -0200, Rik van Riel wrote:
> Wrong. Getblk won't deadlock, it will just sleep and another
getblk will deadlock.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
> > cat /mnt/www/www.kernel.org/index.html
>
> can you do ls /mnt/www/www.kernel.org/ as well? I'm interested, I came
> to conclusion that web filesystem is not possible... (If you can't do
Yes, if the server supports webDAV or something similar.
> listings, it is not really filesystem; you c
On Sat, 16 Dec 2000, Mikulas Patocka wrote:
> > Not unless your driver is broken.
>
> ok_to_allocate:
> *** INTERRUPT
> spin_lock_irqsave(&page_alloc_lock, flags);
> /* if it's not a dma request, try non-dma first */
> if (!(gfp_mask & __GFP_DMA
Hi!
> The cool thing is that the CorbaFS userspace server can implement any
> kind of filesystem you want, as long as it follows the CorbaFS
> interface! The current implementation exports the filesystem on the
> host machine that it is running on, similar to NFS. But we also have
> ideas for F
Mikulas Patocka wrote:
> > Oh, and try to eat atomic memory by ping -f kORBit-ized box.
>
> When linux is out of atomic memory, it will die anyway.
Only if you subscribe to the "we don't need to handle exceptions or check return
values" programmers guild...i.e. lazy error prone coders.
I tend t
> > I guess that when you mmap large files over nfs and write to them, you get
> > similar problems.
> >
> > > Oh, and try to eat atomic memory by ping -f kORBit-ized box.
> >
> > When linux is out of atomic memory, it will die anyway.
>
> Not unless your driver is broken.
ok_to_allocate:
> I guess that when you mmap large files over nfs and write to them, you get
> similar problems.
>
> > Oh, and try to eat atomic memory by ping -f kORBit-ized box.
>
> When linux is out of atomic memory, it will die anyway.
Not unless your driver is broken.
Alan
-
To unsubscribe from this lis
> > > > For one of our demos, we ran a file server on a remote linux box (that we
> > > > just had a user account on), mounted it on a kORBit'ized box, and ran
> > > > programs on SPARC Solaris that accessed the kORBit'ized linux box's file
> > > > syscalls. If nothing else, it's pretty nifty wh
Hi!
> > > For one of our demos, we ran a file server on a remote linux box (that we
> > > just had a user account on), mounted it on a kORBit'ized box, and ran
> > > programs on SPARC Solaris that accessed the kORBit'ized linux box's file
> > > syscalls. If nothing else, it's pretty nifty what
Hi.
> > For one of our demos, we ran a file server on a remote linux box (that we
> > just had a user account on), mounted it on a kORBit'ized box, and ran
> > programs on SPARC Solaris that accessed the kORBit'ized linux box's file
> > syscalls. If nothing else, it's pretty nifty what you can
> > For one of our demos, we ran a file server on a remote linux box (that we
> > just had a user account on), mounted it on a kORBit'ized box, and ran
> > programs on SPARC Solaris that accessed the kORBit'ized linux box's file
> > syscalls. If nothing else, it's pretty nifty what you can do in
Hi!
> > It was just an example. Basically, you'd be able to do in with just
> > about any language that has ORBit bindings.
> >
> > Ben Ford wrote:
> > > Why would you *ever* want to write a device driver in perl???
> >
>
> Precisely... but also, there could be a case where perl would make
> s
Pavel Machek wrote:
> Hi!
>
> > For one of our demos, we ran a file server on a remote linux box (that we
> > just had a user account on), mounted it on a kORBit'ized box, and ran
> > programs on SPARC Solaris that accessed the kORBit'ized linux box's file
> > syscalls. If nothing else, it's pre
Hi!
> For one of our demos, we ran a file server on a remote linux box (that we
> just had a user account on), mounted it on a kORBit'ized box, and ran
> programs on SPARC Solaris that accessed the kORBit'ized linux box's file
> syscalls. If nothing else, it's pretty nifty what you can do in li
Alexander Viro <[EMAIL PROTECTED]> writes:
> ioctl() is avoidable. Proof: Plan 9. They don't _have_ that system call.
> It doesn't mean that we should (or could) remove it. It _does_ mean that
> new APIs do not need it.
*I* sure wish we could. From the standpoint of trying to trace system calls,
On Thu, 14 Dec 2000, Chris Lattner wrote:
> > Yes, I did. What I don't understand is how kernel mechanism for marshalling
> > would make your life easier wrt changes.
>
> I gave a very simple example of how an interface could be designed and
> then later extended without breaking any user spac
> But alan, that's the beautiful thing. Given a CORBA object, you can
> understand its structure without knowing exactly what the contents
> are. You can effectively derive it's prototype just by inspecting it.
Oh dear this isnt going in is it.
Look I know the prototype of every single lisp t
> > > Oh, great. So we don't have to care about formatting changes. We just
> > > have to care about the data changes. IOW, we are shielded from the
> > > results of changes that should never happen in the first place. And the
> > > benefit being...?
> >
> > What the hell are you talking about?
> > > There is a large perception of CORBA being slow, but for the most part it
> > > is unjustified.
>
> Really? I have that same perception but I can't claim that I've measured it.
> On the other hand, I have measured the overhead of straight UDP, TCP, and
> Sun RPC ping/pong tests and you
> > Of course. Which is why CORBA is about putting STRUCTURE in that stream
> > of random bytes coming over the wire. Why should I have to rewrite my
> > marshalling and demarshalling code every time I want to write a
> > server. read and write are fine. But sometimes I want a
> > structure.
Fredrik Vraalsen wrote:
> The cool thing is that the CorbaFS userspace server can implement any
> kind of filesystem you want, as long as it follows the CorbaFS
> interface!
Sorry, it's yet another one. Or does it do something different?
(YAO hasn't stopped me working on userspace filesystems ei
> > There is a large perception of CORBA being slow, but for the most part it
> > is unjustified. I believe that the act of _designing_ a completely new
> CORBA is slow compared to some of the other solutions. The question I was
> trying to ask is whether you should put something smaller and f
On 14 Dec 2000, Michael Livshin wrote:
> this might be because the Bell Labs folks don't like RPC in general
> when network latencies become involved? I'm guessing.
>
> 'cause CORBA is still pretty much objectified RPC, as far as I know.
> I don't think you want to abstract the network out just
* Rik van Riel
|
| On Wed, 13 Dec 2000, Chris Lattner wrote:
|
| > 1. kORBit adds about 150k of code to the 2.4t10 kernel.
| > 2. kNFS adds about 100k of code to the 2.4t10 kernel.
| > 3. kORBit can do everything kNFS does, plus a WHOLE lot more: For example
| >implement an NFS like server th
> >that is not transparently hidden to the user. Why can't I just open
> >/dev/net0 and get the first network device? Because we have so many
> >inconsistent, poorly design, inextensible interfaces laying around, thats
> >why.
> This is a bad example, but a (perhaps?) good point. It seems it
> > 1. kORBit adds about 150k of code to the 2.4t10 kernel.
> > 2. kNFS adds about 100k of code to the 2.4t10 kernel.
> So can you implement a kNFS server in kORBit that takes
> less than 50kB of RAM? Otherwise it's still a contributor
> to bloat and this argument won't work ;)
Actually the kOR
On Wed, 13 Dec 2000, Chris Lattner wrote:
> 1. kORBit adds about 150k of code to the 2.4t10 kernel.
> 2. kNFS adds about 100k of code to the 2.4t10 kernel.
> 3. kORBit can do everything kNFS does, plus a WHOLE lot more: For example
>implement an NFS like server that uses SSL to send files and
Alexander Viro wrote:
> > Err... how about this: Give me two or three kORBit syscalls and I can get
> > rid of all the other 100+ syscalls! :)
>
> Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity
> of the API is. Technically, kernel has 1 (_o_n_e_) entry point as fa
I surely hope that this thread wont end here. It's extremely important to look
at this since we're heading towards distributed resources, where humans dont
work on a server but towards other people through servers.
/josef
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Chris Lattner <[EMAIL PROTECTED]> writes:
> > p9fs exists. I didn't see these patches since August, but probably I can poke
> > Roman into porting it to the current tree. 9P is quite simple and unlike
> > CORBA it had been designed for taking kernel stuff to userland. Besides,
> > authors defi
[Alan DID not say this:]
> > There is a large perception of CORBA being slow, but for the most part it
> > is unjustified.
Really? I have that same perception but I can't claim that I've measured it.
On the other hand, I have measured the overhead of straight UDP, TCP, and
Sun RPC ping/pong te
> There is a large perception of CORBA being slow, but for the most part it
> is unjustified. I believe that the act of _designing_ a completely new
> protocol, standardizing it, and making it actually work would be a huge
> process that would basically reinvent CORBA (obviously some of the desig
On Thu, Dec 14, 2000 at 10:23:15AM +0100, josef höök wrote:
> Plan9 aint unix/posix though it has its Ape environment.
> What we do need to look at is a good implementation for distributed resources.
> The ideal would bee getting 9P and IL into linux. Think of having thousand of small
>
> linux b
Alexander Viro spake thus:
> Maybe... I definitely agree that 14 is below the limit, but 30... Hell knows,
> from what I see on the box I'm using right now it seems to fall into several
> cathegories:
> * Very-Long-And-Verbose-Named-HOWTO.html
> * manpages for X and Tcl functions wit
Chris Lattner wrote:
> > > Err shame on you, don't forget about lcall and exceptions, and interrupts,
> > > and... That is technically more than _o_n_e_ "entry point". :) Oh wait,
> > > what about sysenter/exit too? :)
> > OK, you got me on lcall (however, that's iBCS-only, IIRC), but the rest.
On Thu, 14 Dec 2000, josef [iso-8859-1] höök wrote:
> Chip Salzenberg wrote:
>
> > According to Alexander Viro:
> > > 9P is quite simple and unlike CORBA it had been designed for taking
> > > kernel stuff to userland. Besides, authors definitely understand
> > > UNIX...
> >
> > As nice as 9P
Chip Salzenberg wrote:
> According to Alexander Viro:
> > 9P is quite simple and unlike CORBA it had been designed for taking
> > kernel stuff to userland. Besides, authors definitely understand
> > UNIX...
>
> As nice as 9P is, it'll need some tweaks to work with Linux.
> For example, it limits
On Thu, 14 Dec 2000, Chris Lattner wrote:
> > Oh, great. So we don't have to care about formatting changes. We just
> > have to care about the data changes. IOW, we are shielded from the
> > results of changes that should never happen in the first place. And the
> > benefit being...?
>
> What
> > NO. You want leagacy program to "just get" rounded ints, and new programs
> > to get the "full precision" of the floating point #'s.
> What rounded ints? Rounded to zero? To nearest integer? To plus or minus
> infinity? Does program have something to say here?
The exact same thing that old
On Wed, 13 Dec 2000, Chris Lattner wrote:
> > OK, now I'm completely confused.
> > * which complex data structures do you want to export from the kernel
> > in non-opaque way?
> > * which of those structures are guaranteed to remain unchanged?
> > * if you have userland-to-userlan
At 12:15 AM 12/14/2000 -0500, you wrote:
>Hmm... Cutoff seems to sit somewhere around 45 - above that there are only
>apt-get droppings and they definitely are over the top. Dunno, you may be
>right, but looks like I never had a need to create anything that long.
It's always good to be able to in
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> As long as names are to be created, or at least understood, by humans,
> there will be some limit on *usable* length. In my experience, 255 is
> above that limit, but 30 is below it. And I cut my teeth on a system
> that had exactly that length li
> OK, now I'm completely confused.
> * which complex data structures do you want to export from the kernel
> in non-opaque way?
> * which of those structures are guaranteed to remain unchanged?
> * if you have userland-to-userland RPC in mind - why put anything
> marshalling-r
According to Alexander Viro:
> On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> > According to Alexander Viro:
> > > On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> > > > According to Alexander Viro:
> > > > > 9P is quite simple and unlike CORBA it had been designed for taking
> > > > > kernel stuff to
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> According to Alexander Viro:
> > On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> > > According to Alexander Viro:
> > > > 9P is quite simple and unlike CORBA it had been designed for taking
> > > > kernel stuff to userland. Besides, authors definitel
According to Alexander Viro:
> On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> > According to Alexander Viro:
> > > 9P is quite simple and unlike CORBA it had been designed for taking
> > > kernel stuff to userland. Besides, authors definitely understand
> > > UNIX...
> >
> > As nice as 9P is, it'
On Wed, 13 Dec 2000, Chris Lattner wrote:
> Which is exactly why it doesn't work well for many applications. The
> problem is this: how do you get from a byte stream to a structured data
> stream? There are many answers:
>
> 1. Keep your data structures so simple, that it's obvious. Not a g
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> According to Alexander Viro:
> > 9P is quite simple and unlike CORBA it had been designed for taking
> > kernel stuff to userland. Besides, authors definitely understand
> > UNIX...
>
> As nice as 9P is, it'll need some tweaks to work with Linux.
On Wed, 13 Dec 2000, Chris Lattner wrote:
>
> > > either. Oops, wasn't interoperability an important part of the Linux
> > > kernel design? Didn't we want to use and follow and define _real_
> > > standards?
> > Erm... 9P stub exists for Linux. It exists for FreeBSD. I suspect that
> > it e
According to Alexander Viro:
> 9P is quite simple and unlike CORBA it had been designed for taking
> kernel stuff to userland. Besides, authors definitely understand
> UNIX...
As nice as 9P is, it'll need some tweaks to work with Linux.
For example, it limits filenames to 30 characters; that's n
> > > plan-9.bell-labs.com/sys/man/
> Arrgh. s/plan-9/plan9/. My apologies.
Cool, thanks, will read. :)
> IDGI. What 9P gives is an RPC mechanism that uses normal (as in "named streams
> of characters") representation on the client side and very light-weight
> library on the server side. It loo
On Wed, 13 Dec 2000, Chris Lattner wrote:
> > plan-9.bell-labs.com/sys/man/
Arrgh. s/plan-9/plan9/. My apologies.
> Err... yeah, so you're effectively mapping UNIX/POSIX across 9P. That's
> not very creative, and you could do the same thing with CORBA. I ask
> again, "How much development i
> > either. Oops, wasn't interoperability an important part of the Linux
> > kernel design? Didn't we want to use and follow and define _real_
> > standards?
> Erm... 9P stub exists for Linux. It exists for FreeBSD. I suspect that
> it exists for other *BSD too - never checked that.
Okay, so
> > Err shame on you, don't forget about lcall and exceptions, and interrupts,
> > and... That is technically more than _o_n_e_ "entry point". :) Oh wait,
> > what about sysenter/exit too? :)
> OK, you got me on lcall (however, that's iBCS-only, IIRC), but the rest...
> what the hell does userl
On Wed, 13 Dec 2000, Chris Lattner wrote:
>
> /me trims down CC list...
>
> > Local? Funny. It lives atop of TCP or IL quite fine. What's
> > even funnier, I can use it to export /proc from CPU server to workstation
> > and use _that_ for remote debugging. Ditto for window system. Ditto f
> Also, 9P is a general communications framework only in the context of
> Plan9 itself. In reality it only applys directly/well to filesystem
> related issues... the reason it works well in Plan9 is that _everything_
> is a file (part of the beauty of plan9).
So... in a 9P-enabled system, you w
On Wed, 13 Dec 2000, Chris Lattner wrote:
> > > Err... how about this: Give me two or three kORBit syscalls and I can get
> > > rid of all the other 100+ syscalls! :)
>
> > Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity
> > of the API is. Technically, kernel ha
/me trims down CC list...
> Local? Funny. It lives atop of TCP or IL quite fine. What's
> even funnier, I can use it to export /proc from CPU server to workstation
> and use _that_ for remote debugging. Ditto for window system. Ditto for
> DNS. Ditto for plumber. No, not on Linux...
No no
> > I do have one sensible question. Given that corba is while flexible a
> > relatively expensive encoding system, wouldn't it be better to keep corba
> > out of kernel space and talk something which is a simple and cleaner encoding
> p9fs exists. I didn't see these patches since August, but
On Wed, 13 Dec 2000, Chris Lattner wrote:
> CORBA, today, gives us superior interoperability (through IIOP), with
> extensibility for the future. As Alexander Viro mentions, 9P may be a
> better protocol for local communications...
Local? Funny. It lives atop of TCP or IL quite fine.
Alexander Viro wrote:
> p9fs exists. I didn't see these patches since August, but probably I can poke
> Roman into porting it to the current tree. 9P is quite simple and unlike
> CORBA it had been designed for taking kernel stuff to userland. Besides,
> authors definitely understand UNIX...
I
> > Err... how about this: Give me two or three kORBit syscalls and I can get
> > rid of all the other 100+ syscalls! :)
> Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity
> of the API is. Technically, kernel has 1 (_o_n_e_) entry point as far as
> userland is conc
> > Don't worry about kORBit. Like most open source projects, it will simply
> > die out after a while, because people don't find it interesting and there
> > is really no place for it. If it becomes useful, mature, and refined,
> > however, it could be a very powerful tool for a large class of
On Wed, 13 Dec 2000, Chris Lattner wrote:
> Err... how about this: Give me two or three kORBit syscalls and I can get
> rid of all the other 100+ syscalls! :)
Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity
of the API is. Technically, kernel has 1 (_o_n_e_) entr
On Thu, 14 Dec 2000, Alan Cox wrote:
> > Don't worry about kORBit. Like most open source projects, it will simply
> > die out after a while, because people don't find it interesting and there
> > is really no place for it. If it becomes useful, mature, and refined,
> > however, it could be a
> Don't worry about kORBit. Like most open source projects, it will simply
> die out after a while, because people don't find it interesting and there
> is really no place for it. If it becomes useful, mature, and refined,
> however, it could be a very powerful tool for a large class of problems
> > > It was just an example. Basically, you'd be able to do in with just
> > > about any language that has ORBit bindings.
> Agree. I remember a big complaint about Windows was the huge APIs,
> compared with Unix' tiny list of syscalls. And then I saw the GNOME
> docs... ew!
Err... how about
[EMAIL PROTECTED] said:
> 1. Boot kernel
> 2. Install corbafs module for example
You misspelled 'codafs' :)
> 3. Start test filesystem in user space
> 4. mount test user space filesystem
> 5. test it, oh crap, it segfaulted.
> 6. CorbaFS gets exceptions trying to communicate to server, which it
On Sat, 9 Dec 2000, Mohammad A. Haque wrote:
> It was just an example. Basically, you'd be able to do in with just
> about any language that has ORBit bindings.
>
> Ben Ford wrote:
> > Why would you *ever* want to write a device driver in perl???
>
Precisely... but also, there could be a case
josef höök wrote:
>
> What about implementing 9P instead
That would rock. Plan9 is unix done the right way -- i.e., the fully
consistent way. I'd love to see 9p in Linux. We're heading that
direction anyway, with procfs, devfs, etc.
-
To unsubscribe from this list: send the line "unsubscribe li
What about implementing 9P instead
/joh
Michael Rothwell wrote:
> Ben Ford wrote:
>
> > Why would you *ever* want to write a device driver in perl???
>
> Well, Perl, I don't know. But the USB 'driver' for my Canon PowerShot
> S20 runs in userspace. Seems a safer place to do things.
>
> -M
> -
Ben Ford wrote:
> Why would you *ever* want to write a device driver in perl???
Well, Perl, I don't know. But the USB 'driver' for my Canon PowerShot
S20 runs in userspace. Seems a safer place to do things.
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Hi!
> > This email is here to announce the availability of a port of ORBit (the
> > GNOME ORB) to the Linux kernel. This ORB, named kORBit, is available from
> > our sourceforge web site (http://korbit.sourceforge.net/). A kernel ORB
> > allows you to write kernel extensions in CORBA and have t
On Mon, 11 Dec 2000, Dietmar Kling wrote:
> > You do realize what "evolution" means? I'm not talking about the bugs
> > in implementation. I'm talking about botched design. _That_ never gets
> > fixed. Show me one example when that would happen and I might consider
> > taking such possibility s
> You do realize what "evolution" means? I'm not talking about the bugs
> in implementation. I'm talking about botched design. _That_ never gets
> fixed. Show me one example when that would happen and I might consider
> taking such possibility seriously.
That's what I am talking about in my "mean
On Mon, 11 Dec 2000, Dietmar Kling wrote:
> I do not understand this
> "i saw it - yuck! - and now i want to kill it "
s/want to kill it/do not want to touch it/
> point of view.
> As I tried to point out. Things evolve. And
> the evolution has the right do things wrong.
> Next evolution ste
Alexander Viro wrote:
>
> On Mon, 11 Dec 2000, Martin Dalecki wrote:
>
> > Please don't put KDE into the same bunch as gnome or
> > windows. KDE is in fact *well designed*! In esp. 2.0
>
> 'Tis funny, you know, because ISTR that the bloody thing
> got the same problems with the program sizes,
- Original Message -
From: J . A . Magallon <[EMAIL PROTECTED]>
To: Martin Dalecki <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, December 11, 2000 8:47 AM
Subject: Re: ANNOUNCE: Linux Kernel ORB: kORBit
>
> On Mon, 11 Dec 2000 14:38:52 Martin Dalec
On Mon, 11 Dec 2000, Martin Dalecki wrote:
> Please don't put KDE into the same bunch as gnome or
> windows. KDE is in fact *well designed*! In esp. 2.0
'Tis funny, you know, because ISTR that the bloody thing
got the same problems with the program sizes, API bloat and lack of
orthogonality.
On Mon, 11 Dec 2000 14:38:52 Martin Dalecki wrote:
>
> Please don't put KDE into the same bunch as gnome or
> windows. KDE is in fact *well designed*! In esp. 2.0
>
That is why you need a supercomputer to run KDE at acceptable interactive
speeds...
--
Juan Antonio Magallon Lacarta
Dietmar Kling wrote:
>
> Ok guys i take your arguments...
> (i really loved to hear them)
>
> and i'd like to continue them in a
> private discussion( but i am
> tired now ... :) )
>
> but a last one i cannot resist...
>
>
> but why are your ideas not widespread and
> so successful like kde,g
In article <[EMAIL PROTECTED]> you wrote:
> Why would you *ever* want to write a device driver in perl???
Actually there is kind of device driver in perl, and besides it's
performance I think it proofed that a High-Level Language can do good for
rapid prototyping.
http://www.inter-mezzo.org - a
> but a last one i cannot resist...
>
>
> but why are your ideas not widespread and
> so successful like kde,gnome,windows?
> maybe because they suck at some point?
>
>
> Regards (and please flame me private ... :))
Last time I checked you needed a kernel...
-d
begin:vcard
n:Ford;David
x-m
Ok guys i take your arguments...
(i really loved to hear them)
and i'd like to continue them in a
private discussion( but i am
tired now ... :) )
but a last one i cannot resist...
but why are your ideas not widespread and
so successful like kde,gnome,windows?
maybe because they suck at some
On Sat, 9 Dec 2000, Alan Cox wrote:
> > > From what I've seen in GNOME it's mostly about avoiding pipes
> > > religiously and putting everything and a kitchen sink into the same
> > > process. I'm not saying that it has no valid uses, but it definitely
> > > had contributed to the bloat in cas
> > From what I've seen in GNOME it's mostly about avoiding pipes
> > religiously and putting everything and a kitchen sink into the same
> > process. I'm not saying that it has no valid uses, but it definitely
> > had contributed to the bloat in case of GNOME.
> >
>
> Please consider to read t
>
> From what I've seen in GNOME it's mostly about avoiding pipes
> religiously and putting everything and a kitchen sink into the same
> process. I'm not saying that it has no valid uses, but it definitely
> had contributed to the bloat in case of GNOME.
>
Please consider to read this articl
I wrote:
> Yeah... "Infinitely extendable API" and all such. Roughly translated
> as "we can't live without API bloat". Frankly, judging by the GNOME
> codebase people who designed the thing are culturally incompatible with
> UNIX.
Hrrm. After rereading... I suspect that I wasn't clear en
On Sat, 9 Dec 2000, Alan Cox wrote:
> > Yeah... "Infinitely extendable API" and all such. Roughly translated
> > as "we can't live without API bloat". Frankly, judging by the GNOME
> > codebase people who designed the thing
> Yeah... "Infinitely extendable API" and all such. Roughly translated
> as "we can't live without API bloat". Frankly, judging by the GNOME
> codebase people who designed the thing are culturally incompatible with
> UNIX.
Oh they are definitely unix people, but ORBit is about solving a very
dif
Alexander Viro wrote:
> > It was just an example. Basically, you'd be able to do in with just
> > about any language that has ORBit bindings.
>
> Yeah... "Infinitely extendable API" and all such. Roughly translated
> as "we can't live without API bloat". Frankly, judging by the GNOME
> codebase p
> > * We can now write device drivers in perl, and let them run on the iMAC
> > across the hall from you. :)
>
> Why would you *ever* want to write a device driver in perl???
So you can easily facilitate opportunities for viruses ;)
-d
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
url:www.b
1 - 100 of 105 matches
Mail list logo
