lkml.org 
[lkml]   [2003]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.7 thoughts: common well-architected object model
I've managed to stay out of this so far, but I can't anymore.

On Mon, Oct 13, 2003 at 10:31:55PM -0700, retu wrote:
> NameYourClassLibrary_empty. Below a list pasted from
> the .net namespace with many dozens of classes
> covering everything from io to drawing.

What is it about .net that gets your rocks off so well? Let me try to make
this clear - W H Y. Why? Why do we need any of this crap? why do you feel
that WE the kernel people should be the ones doing it? Why are YOU not
doing it? Why are you not funding someone who has a REAL clue to do it?
For enough money, I'll be happy to architect any piece of crap you want.
Maybe.

> They _appear for the most part to be consistent
> wrappers to underlying existing APIs (including some

What is wrong with existing APIs that they need wrapping?

> Hence, what would be needed is in the first place a
> component model (well architected - thin - efficient)

ok, I'll play along. What components do you envision? Files? How about we
abstract that to a generic IO type. Sockets? How about we make them the
same as files at the lowest level, and if you want, you can get the higher
level IO type. What else...Credentials? How about a type for process IDs,
one for group IDs, and one for user IDs.

What do you want from us?

> efficiency reasons (Linux ought to scale to HPC

Are you implying it doesn't? Because I know a lot of HPC sites that might
want to argue. Ask SGI if linux scales for HPC.

> levels), broadening some application class library OR
> architecting something without the kernel in mind is

Right, because EVERYTHING belongs in the kernel.

> If there are multiple sets of classes for e.g. 2D
> drawing then so what as long as they use the same

oh, you mean drawing in an 80x25 console, or an SVGA high-res console? Or
maybe you mean a serial port. Or perhaps you mean X, or some other
windowing system. How about we just integrate a GUI into the kernel, so
people don't have to have all those pesky choices. To pick from the list
below: Drawing, XML, Web have NOTHING to do with the kernel or it's
development. I'd like to remind you that WE ARE NOT WINDOWS. WE DO NOT
WANT TO BE WINDOWS. This is the linux-kernel list. You apparently do not
understand what we do here.

> Linux component model (which has yet to be defined or
> even a grain of consens found that it is necessary in
> the first place).

You keep telling us it is needed. We keep asking why. You keep telling us
we need it. We keep asking why. You keep...

> System
> System.CodeDom
> System.CodeDom.Compiler
...
> System.Xml.XPath
> System.Xml.Xsl

Other than being named 'System', what do they have to do with the kernel?

> with a very decent component model and design
> philosphy on what to put in and what not it would
> enable people to quickly fill in the blanks (plus
> maybe some rapid abstracting/wrapping) which would do
> a very lot for the OS.

Please, answer me this: Who are you? What is your background? What do you
do? How old are you? Why do you keep bothering us? Can you please just
put up or shut up already?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.115 / U:0.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site