2.7 thoughts: common well-architected object model

2.7 thoughts: common well-architected object model

[asdfd esadd]

With due respect, what 2.7 really needs is a
consistent well architected _single component model.
Why it should be spawned from kernel development -
because coming up with a consistent one from higher
layers has shown to be difficult/futile/impossible. 

Many of the feature ideas listed are great but it's
rather back to architecture at this stage.

A consistent component model is needed on which people
can extend and Linux will lap the other OSs, otherwise
it will be rather difficult to
compete on the application side in the end (argument
will be: Linux is is difficult to program and has
flagrant duplication). There are many good component
models out there but the parallel re-implementation of
everything somewhat lacks cast.

So here is the feature request:

* a unified well architected core component model
which is extensible


- RETU 



__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: 2.7 thoughts: common well-architected object model

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

On Fri, 10 Oct 2003 21:45:14 PDT, asdfd esadd said:

> * a unified well architected core component model
> which is extensible

OK.. now for the terminally dense readers of the list like myself, could
you repeat that in terms that people who have more experience in
slinging C code than buzzwords will understand and rally behind?

Most of the time when I hear "component", somebody's trying to invent
yet another message-passing paradigm.  And although there's certainly
a place where things like CORBA and the dbus stuff solve problems,
you have to remember that this is a Linux kernel, not Mach....

Alternatively, explain to me what this component model will do for us
that updating the docs on the kernel API won't?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.7 thoughts: common well-architected object model

[asdfd esadd]

the other OS has an at this stage highly consistent
object model user along the lines of COM+ from the
kernel up encompassing a single event, thread etc.
model. Things are quite consistently wrapped, user
mode exposed if needed etc. If people were to fully
draw on it and the simpler .net BCL and not ride win32
that would (will be) a killer.  

So let me restate the need:

* a unified well architected core component model
which is extensible from OS services to application
objects

* the object model should be defined from the kernel
layer for process/events/devices etc. up and not
started at the application layer


--- Valdis.Kletnieks@vt.edu wrote:
> On Fri, 10 Oct 2003 21:45:14 PDT, asdfd esadd said:
> 
> > * a unified well architected core component model
> > which is extensible
> 
> OK.. now for the terminally dense readers of the
> list like myself, could
> you repeat that in terms that people who have more
> experience in
> slinging C code than buzzwords will understand and
> rally behind?
> 
> Most of the time when I hear "component", somebody's
> trying to invent
> yet another message-passing paradigm.  And although
> there's certainly
> a place where things like CORBA and the dbus stuff
> solve problems,
> you have to remember that this is a Linux kernel,
> not Mach....
> 
> Alternatively, explain to me what this component
> model will do for us
> that updating the docs on the kernel API won't?
> 

> ATTACHMENT part 2 application/pgp-signature 



__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: 2.7 thoughts: common well-architected object model

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

On Sat, 11 Oct 2003 09:06:21 PDT, you said:
> 
> the other OS has an at this stage highly consistent
> object model user along the lines of COM+ from the
> kernel up encompassing a single event, thread etc.
> model. Things are quite consistently wrapped, user
> mode exposed if needed etc. If people were to fully
> draw on it and the simpler .net BCL and not ride win32
> that would (will be) a killer.  

If all your friends jumped off a cliff, would you do it too?

I submit to you that the reason The Other OS needs the concept of a object
model from the kernel through to user space is because the architects had a
very fuzzy concept of "boundary".  Yes, you need stuff like that if your GUI
and your IIS (yes, really, Win2003 apparently has IIS on the kernel side of the
boundary now).  If you have a syscall interface, the kernel is free to
implement read() in any way it wants, and the userspace calling read() is able
to use it for pretty much anything.

Ask yourself:  (a) Could I implement .NET in userspace using the supplied syscalls?
(b) If .NET was implemented and enforced kernel-side, could I implement CORBA?

Remember - it's quite possible that the user wants some OTHER GUI, or some
OTHER thread model, or some OTHER.....  We're not the operating system run by
jackboots.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.7 thoughts: common well-architected object model

[Scott Robert Ladd]

asdfd esadd wrote:
> So let me restate the need:
> 
> * a unified well architected core component model
> which is extensible from OS services to application
> objects
> 
> * the object model should be defined from the kernel
> layer for process/events/devices etc. up and not
> started at the application layer

A few years ago, I would have agreed with you. But in today's reality, 
an OS-based object model provides a singular target for malicious attack.

The theory of reusable binary components is seductive, yet it leads to 
many of the flaws seen in Windows. All too often, Windows applications 
install components which may be newer or even older than the ones they 
replace; while Microsoft has made strides with component versioning, the 
problem still exists. These days, many Windows applications ship their 
own version of "common" components, to avoid incompatibilities with 
whatever may be installed system-wide.

OS-based object models also suffer from bit rot. New hardware and 
software features require API changes, such that older objects gradually 
become incompatible with newer requirements.

Windows also has the advantage of focusing on a single hardware 
platform, where Linux runs on an incredible variety of systems.

Were Linux to implement an object model, it would need careful and 
considerate design to address security, versioning, extensibility, and 
portability.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: 2.7 thoughts: common well-architected object model

[asdfd esadd]

unfortunately it's rather a jump into elegance. The
other OS component model is quite well architected.
Hence what's needed is _a similar architecture effort
which may _abstract many things in the beginning to be
filled in later. Ther's a dire need for a sound and
similarly elegant (or better) model. 

There can still be many e.g. widget libraries for GUIs
but if new ones were to build on a common model  (or
wrapped) Linux would kill Windows through the by now
larger base of contributors. If that apparent lack of
architecture guidance continues we get another dozen
class libraries for everything for each application
nicely exposing it which then nobody learns/uses. With
a common object model Linux can push the envelope,
without it it's leaving it to others. 


--- Valdis.Kletnieks@vt.edu wrote:
> On Sat, 11 Oct 2003 09:06:21 PDT, you said:
> > 
> > the other OS has an at this stage highly
> consistent
> > object model user along the lines of COM+ from the
> > kernel up encompassing a single event, thread etc.
> > model. Things are quite consistently wrapped, user
> > mode exposed if needed etc. If people were to
> fully
> > draw on it and the simpler .net BCL and not ride
> win32
> > that would (will be) a killer.  
> 
> If all your friends jumped off a cliff, would you do
> it too?
> 
> I submit to you that the reason The Other OS needs
> the concept of a object
> model from the kernel through to user space is
> because the architects had a
> very fuzzy concept of "boundary".  Yes, you need
> stuff like that if your GUI
> and your IIS (yes, really, Win2003 apparently has
> IIS on the kernel side of the
> boundary now).  If you have a syscall interface, the
> kernel is free to
> implement read() in any way it wants, and the
> userspace calling read() is able
> to use it for pretty much anything.
> 
> Ask yourself:  (a) Could I implement .NET in
> userspace using the supplied syscalls?
> (b) If .NET was implemented and enforced
> kernel-side, could I implement CORBA?
> 
> Remember - it's quite possible that the user wants
> some OTHER GUI, or some
> OTHER thread model, or some OTHER.....  We're not
> the operating system run by
> jackboots.
> 
> 

> ATTACHMENT part 2 application/pgp-signature 



__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: 2.7 thoughts: common well-architected object model

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

On Sat, 11 Oct 2003 10:13:55 PDT, you said:
> 
> unfortunately it's rather a jump into elegance. The
> other OS component model is quite well architected.
> Hence what's needed is _a similar architecture effort
> which may _abstract many things in the beginning to be
> filled in later. Ther's a dire need for a sound and
> similarly elegant (or better) model. 

Two words: "syscall interface".

Most of what you're blathering about needs to happen in userspace.

If there's disagreement over what GUI style to use, the kernel is
NOT going to provide any guidance.  KDE versus Gnome versus the
other 23 window managers - that's all userspace.  The reason there's
25 window managers is because 25 sets of people had *different goals*.

The kernel wisely stayed *OUT OF THE WAY*.

With a single common object model, Linux can push the envelope in ONE
direction.  Which is why That Other System scales so incredibly well from
a Zaurus to a 128-CPU NUMA box, handles different GUIs for different goals,
and all the rest of that.....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.7 thoughts: common well-architected object model

[asdfd esadd]

it's exposing many of the syscalls into relevant
user-space objects which makes the other OSs approach
neat. Coming from the kernel an outline of a common
object model should be suggested which is then
actually populated and refined futher by e.g. the GUI
folks. 

The other way around has shown not to work with the
many application-designed component frameworks out
there. In the other OS you'll be able to do things in
I/O, process, GUI, data access etc. in a quite similar
way. The current permutation in Linux for putting
together an application is staggering, which can force
people to use the lowest common denominator - like
libc.a ;) - it's actually not funny.   

A core component model has to be defined by the kernel
group and then trickle upward. That's the only way
where you can sufficiently design in performance and
security(*) considerations which I agree should allow
Linux to scale as well as it does. 

  
(*) good example for the opportunity in leaping the
other OS here: there is another big void in a sound
security component properties right now. COM+ has
quite a bit in it, but there is much more which could
be done and people are keen on it. Another item where
Linux could start to define the envelope. 
 

--- Valdis.Kletnieks@vt.edu wrote:
> On Sat, 11 Oct 2003 10:13:55 PDT, you said:
> > 
> > unfortunately it's rather a jump into elegance.
> The
> > other OS component model is quite well
> architected.
> > Hence what's needed is _a similar architecture
> effort
> > which may _abstract many things in the beginning
> to be
> > filled in later. Ther's a dire need for a sound
> and
> > similarly elegant (or better) model. 
> 
> Two words: "syscall interface".
> 
> Most of what you're blathering about needs to happen
> in userspace.
> 
> If there's disagreement over what GUI style to use,
> the kernel is
> NOT going to provide any guidance.  KDE versus Gnome
> versus the
> other 23 window managers - that's all userspace. 
> The reason there's
> 25 window managers is because 25 sets of people had
> *different goals*.
> 
> The kernel wisely stayed *OUT OF THE WAY*.
> 
> With a single common object model, Linux can push
> the envelope in ONE
> direction.  Which is why That Other System scales so
> incredibly well from
> a Zaurus to a 128-CPU NUMA box, handles different
> GUIs for different goals,
> and all the rest of that.....
> 

> ATTACHMENT part 2 application/pgp-signature 



__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: 2.7 thoughts: common well-architected object model

[Kenn Humborg]

On Sat, Oct 11, 2003 at 09:06:21AM -0700, asdfd esadd wrote:
> 
> the other OS has an at this stage highly consistent
> object model user along the lines of COM+ from the
> kernel up encompassing a single event, thread etc.
> model. Things are quite consistently wrapped, user
> mode exposed if needed etc. If people were to fully
> draw on it and the simpler .net BCL and not ride win32
> that would (will be) a killer.  

I'm a Win32 developer by day, and I'm pretty familiar with
the innards of COM.  But I can't think of a _single_ instance
of anything in COM or COM+ which is dependent on the kernel,
or which lives on the kernel-side of the kernel-mode/usr-mode
boundary.

COM and COM+ (and even .NET) are user-mode libraries and
conventions.

The closest thing _inside_ the WinNT/2K/XP kernel to your
"object model" is the hierarchical directory of refcounted
and ACLed objects inside the kernel (which is basically sysfs
with ACLs).

Can you give me _one_ example of a "consistent object model"
between kernel and user mode in Windows?  Maybe then we'll
have a better understanding of what you're really looking
for.

Later,
Kenn

Re: 2.7 thoughts: common well-architected object model

[Zwane Mwaikambo]

On Sat, 11 Oct 2003 Valdis.Kletnieks@vt.edu wrote:

> .....  We're not the operating system run by
> jackboots.

End of thread? ;)

Re: 2.7 thoughts: common well-architected object model

[Mark Hahn]

On Sat, 11 Oct 2003, asdfd esadd wrote:

yah, right.  could you please move this to comp.os.design.masturbation?

thanks!

Re: 2.7 thoughts: common well-architected object model

[asdfd esadd]

There is a connex, fork() might be a bad example,

it's simple - yes but 20 years have passed as Solaris
is finding:

pid_t fork(void); vs. 

the next step in the evolution CreateProcess

BOOL CreateProcess(
  LPCTSTR lpApplicationName,
  LPTSTR lpCommandLine,
  LPSECURITY_ATTRIBUTES lpProcessAttributes,
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  BOOL bInheritHandles,
  DWORD dwCreationFlags,
  LPVOID lpEnvironment,
  LPCTSTR lpCurrentDirectory,
  LPSTARTUPINFO lpStartupInfo,
  LPPROCESS_INFORMATION lpProcessInformation

evolved to .Net Process Class

System.Object
   System.MarshalByRefObject
      System.ComponentModel.Component
         System.Diagnostics.Process
[C#]
public class Process : Component
[C++]
public __gc class Process : public Component


with a full list of members mapping to the overall
model per se (link to hell, but they've got a point) 

http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemdiagnosticsprocessmemberstopic.asp


So let me restate the need again for a:

* unified well architected core component model
which is extensible from OS services to application
objects

* the object model should be defined from the kernel
layer for process/events/devices etc. up and not
started at the application layer



--- Kenn Humborg <kenn@linux.ie> wrote:
> On Sat, Oct 11, 2003 at 09:06:21AM -0700, asdfd
> esadd wrote:
> > 
> > the other OS has an at this stage highly
> consistent
> > object model user along the lines of COM+ from the
> > kernel up encompassing a single event, thread etc.
> > model. Things are quite consistently wrapped, user
> > mode exposed if needed etc. If people were to
> fully
> > draw on it and the simpler .net BCL and not ride
> win32
> > that would (will be) a killer.  
> 
> I'm a Win32 developer by day, and I'm pretty
> familiar with
> the innards of COM.  But I can't think of a _single_
> instance
> of anything in COM or COM+ which is dependent on the
> kernel,
> or which lives on the kernel-side of the
> kernel-mode/usr-mode
> boundary.
> 
> COM and COM+ (and even .NET) are user-mode libraries
> and
> conventions.
> 
> The closest thing _inside_ the WinNT/2K/XP kernel to
> your
> "object model" is the hierarchical directory of
> refcounted
> and ACLed objects inside the kernel (which is
> basically sysfs
> with ACLs).
> 
> Can you give me _one_ example of a "consistent
> object model"
> between kernel and user mode in Windows?  Maybe then
> we'll
> have a better understanding of what you're really
> looking
> for.
> 
> Later,
> Kenn
> 
> 
> -
> 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/


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: 2.7 thoughts: common well-architected object model

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

On Sat, 11 Oct 2003 11:34:05 PDT, asdfd esadd said:

> pid_t fork(void); vs. 
> 
> the next step in the evolution CreateProcess
> 
> BOOL CreateProcess(
>   LPCTSTR lpApplicationName,
>   LPTSTR lpCommandLine,
>   LPSECURITY_ATTRIBUTES lpProcessAttributes,
>   LPSECURITY_ATTRIBUTES lpThreadAttributes,
>   BOOL bInheritHandles,
>   DWORD dwCreationFlags,
>   LPVOID lpEnvironment,
>   LPCTSTR lpCurrentDirectory,
>   LPSTARTUPINFO lpStartupInfo,
>   LPPROCESS_INFORMATION lpProcessInformation
> 
> evolved to .Net Process Class
> 
> System.Object
>    System.MarshalByRefObject
>       System.ComponentModel.Component
>          System.Diagnostics.Process
> [C#]
> public class Process : Component
> [C++]
> public __gc class Process : public Component

Thanks for the example of why it's a bad idea.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.7 thoughts: common well-architected object model

[Kenn Humborg]

On Sat, Oct 11, 2003 at 11:34:05AM -0700, asdfd esadd wrote:
> There is a connex, fork() might be a bad example,
> 
> it's simple - yes but 20 years have passed as Solaris
> is finding:
> 
> pid_t fork(void); vs. 
> 
> the next step in the evolution CreateProcess

CreateProcess() did _not_ evolve from fork().  There is no fork() 
equivalent in the Windows world.  If anything it came more from 
$CREPRC in VMS.

> BOOL CreateProcess(
>   LPCTSTR lpApplicationName,
>   LPTSTR lpCommandLine,
>   LPSECURITY_ATTRIBUTES lpProcessAttributes,
>   LPSECURITY_ATTRIBUTES lpThreadAttributes,
>   BOOL bInheritHandles,
>   DWORD dwCreationFlags,
>   LPVOID lpEnvironment,
>   LPCTSTR lpCurrentDirectory,
>   LPSTARTUPINFO lpStartupInfo,
>   LPPROCESS_INFORMATION lpProcessInformation
> 
> evolved to .Net Process Class

"evolved to" is the wrong term - "wrapped by" is more accurate

> System.Object
>    System.MarshalByRefObject
>       System.ComponentModel.Component
>          System.Diagnostics.Process

... which is a _user-land_ wrapper around CreateProcess.

> So let me restate the need again for a:
> 
> * unified well architected core component model
> which is extensible from OS services to application
> objects

Which is a job for userland, in my opinion.

> * the object model should be defined from the kernel
> layer for process/events/devices etc. up and not
> started at the application layer

I still don't see why this needs to be in the kernel.
Give a concrete example of something that cannot be done
with the existing syscall interface and user-mode wrappers.
Or something significant that can be done easier with what
you are asking for.

Of course, your name "asdfd esadd" does look a bit troll-like...

Later,
Kenn

Re: 2.7 thoughts: common well-architected object model

[retu]

you are right on - user-mode wrappers, a consistent
namespace is what's needed. Sun 'forgot' about that
for many many years and is now left with an OS that's
essentially the same as 20 years ago. 

Data access etc. classes could derive from a well
defined model framework. If someone defines a base
framework (not on the trivial side considering
simplicity/elegance, performance, security,
extensibility needs) then this could get going.    

> > System.Object
> >    System.MarshalByRefObject
> >       System.ComponentModel.Component
> >          System.Diagnostics.Process
>
> ... which is a _user-land_ wrapper around 
> CreateProcess.




--- Kenn Humborg <kenn@linux.ie> wrote:
> On Sat, Oct 11, 2003 at 11:34:05AM -0700, asdfd
> esadd wrote:
> > There is a connex, fork() might be a bad example,
> > 
> > it's simple - yes but 20 years have passed as
> Solaris
> > is finding:
> > 
> > pid_t fork(void); vs. 
> > 
> > the next step in the evolution CreateProcess
> 
> CreateProcess() did _not_ evolve from fork().  There
> is no fork() 
> equivalent in the Windows world.  If anything it
> came more from 
> $CREPRC in VMS.
> 
> > BOOL CreateProcess(
> >   LPCTSTR lpApplicationName,
> >   LPTSTR lpCommandLine,
> >   LPSECURITY_ATTRIBUTES lpProcessAttributes,
> >   LPSECURITY_ATTRIBUTES lpThreadAttributes,
> >   BOOL bInheritHandles,
> >   DWORD dwCreationFlags,
> >   LPVOID lpEnvironment,
> >   LPCTSTR lpCurrentDirectory,
> >   LPSTARTUPINFO lpStartupInfo,
> >   LPPROCESS_INFORMATION lpProcessInformation
> > 
> > evolved to .Net Process Class
> 
> "evolved to" is the wrong term - "wrapped by" is
> more accurate
> 
> > System.Object
> >    System.MarshalByRefObject
> >       System.ComponentModel.Component
> >          System.Diagnostics.Process
> 
> ... which is a _user-land_ wrapper around
> CreateProcess.
> 
> > So let me restate the need again for a:
> > 
> > * unified well architected core component model
> > which is extensible from OS services to
> application
> > objects
> 
> Which is a job for userland, in my opinion.
> 
> > * the object model should be defined from the
> kernel
> > layer for process/events/devices etc. up and not
> > started at the application layer
> 
> I still don't see why this needs to be in the
> kernel.
> Give a concrete example of something that cannot be
> done
> with the existing syscall interface and user-mode
> wrappers.
> Or something significant that can be done easier
> with what
> you are asking for.
> 
> Of course, your name "asdfd esadd" does look a bit
> troll-like...
> 
> Later,
> Kenn
> 
> -
> 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/


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: 2.7 thoughts: common well-architected object model

[viro]

On Sat, Oct 11, 2003 at 08:01:02PM +0100, Kenn Humborg wrote:
> "evolved to" is the wrong term - "wrapped by" is more accurate

No, it's perfectly accurate - as mushrooms left in a fridge for too long
evolve into a large collection of other mushroom species...

Re: 2.7 thoughts: common well-architected object model

[J.A. Magallon]

On 10.11, Zwane Mwaikambo wrote:
> On Sat, 11 Oct 2003 Valdis.Kletnieks@vt.edu wrote:
> 
> > .....  We're not the operating system run by
> > jackboots.
> 
> End of thread? ;)

No, I really like it. It is always funny to see how people try to relate
to kernel a ton of userspace things...;)

Even in OSX (mach ;)) there is a clear task separation.
Don't feed  the trolls....

(BTW: any pointer to that nice graphic that Rik uses ? "Don't feed...")

-- 
J.A. Magallon <jamagallon()able!es>     \                 Software is like sex:
werewolf!able!es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.23-pre7-jam1 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk))

Re: 2.7 thoughts: common well-architected object model

[Jamie Lokier]

asdfd esadd wrote:
> There is a connex, fork() might be a bad example,
> 
> it's simple - yes but 20 years have passed as Solaris
> is finding:
> 
> pid_t fork(void); vs. 
> 
> the next step in the evolution CreateProcess
>
> [extraordinarily long-winded way of saying the same thing as
>  if ((pid = fork()) == 0) { set_things(); go(); } ]

Dear asdfd,

How can you possibly think the CreateProcess monstrosity superior to
fork in any way?  You seem to have picked the canonical example of
just what is awful about the Win32 AI and why it's so much work to use.

I cannot think of a single example where CreateProcess is simpler to
use - and it's worse than that: it comes with a bunch of assumptions
and limitations, exactly the kind of thing that presumably you expect
"a component model" to _not_ have.

What do you do when you want to create a process with a property that
_isn't_ listed in the arguments to CreateProcess?  Yes: you have to
set those in the child process, just like with fork().

So what's the point in having some of the properties listed in
CreateProcess?  Answer: none.  Not from an API cleanliness point of
view anyway.

> System.Object
>    System.MarshalByRefObject
>       System.ComponentModel.Component
>          System.Diagnostics.Process
> [C#]
> public class Process : Component
> [C++]
> public __gc class Process : public Component

This begins to make more sense.  You do understand that unix has this
class too, but it's called pid_t, not Process?

> * unified well architected core component model
> which is extensible from OS services to application
> objects

Yeah, but CreateProcess _isn't_ well architected.  It's among the
worst of excreta in Win32.

> * the object model should be defined from the kernel
> layer for process/events/devices etc. up and not
> started at the application layer

Unfortunately you just state this, without giving any reasons for it.

If this were implemented in userspace (i.e. the Mono project),
can you give a single reason why it needs to be extended into the kernel?

-- Jamie

Re: 2.7 thoughts: common well-architected object model

[retu]

CreateProcess was to emphasize the linkage between
kernelmode and usermode and the need for the
kernelmode folks to architect the framework of the
higher layers as well. CreateProcess and its wrappers
might have been not the best choice to highlight the
point of kernspace to userspace linkage. But its set
of properties, how to set them blends with the rest of
this OO framework. 

Why not Mono or DotGNU - they pushed through a subset
of the system namespace through ECMA (a
standardization organization with little to no
discoure prior to standardization) and now believe it
or not its on ISO track. So far so good, but the rest
of the framework is closely tied to windows AND is an
IP (intellectual property) minefield. 

What's the solution out of this - a clean, open object
model designed by the core folks, extensible and free
of licensing issues - and that in the next months.  

RETU
--- Jamie Lokier <jamie@shareable.org> wrote:
> asdfd esadd wrote:
> > There is a connex, fork() might be a bad example,
> > 
> > it's simple - yes but 20 years have passed as
> Solaris
> > is finding:
> > 
> > pid_t fork(void); vs. 
> > 
> > the next step in the evolution CreateProcess
> >
> > [extraordinarily long-winded way of saying the
> same thing as
> >  if ((pid = fork()) == 0) { set_things(); go(); }
> ]
> 
> Dear asdfd,
> 
> How can you possibly think the CreateProcess
> monstrosity superior to
> fork in any way?  You seem to have picked the
> canonical example of
> just what is awful about the Win32 AI and why it's
> so much work to use.
> 
> I cannot think of a single example where
> CreateProcess is simpler to
> use - and it's worse than that: it comes with a
> bunch of assumptions
> and limitations, exactly the kind of thing that
> presumably you expect
> "a component model" to _not_ have.
> 
> What do you do when you want to create a process
> with a property that
> _isn't_ listed in the arguments to CreateProcess? 
> Yes: you have to
> set those in the child process, just like with
> fork().
> 
> So what's the point in having some of the properties
> listed in
> CreateProcess?  Answer: none.  Not from an API
> cleanliness point of
> view anyway.
> 
> > System.Object
> >    System.MarshalByRefObject
> >       System.ComponentModel.Component
> >          System.Diagnostics.Process
> > [C#]
> > public class Process : Component
> > [C++]
> > public __gc class Process : public Component
> 
> This begins to make more sense.  You do understand
> that unix has this
> class too, but it's called pid_t, not Process?
> 
> > * unified well architected core component model
> > which is extensible from OS services to
> application
> > objects
> 
> Yeah, but CreateProcess _isn't_ well architected. 
> It's among the
> worst of excreta in Win32.
> 
> > * the object model should be defined from the
> kernel
> > layer for process/events/devices etc. up and not
> > started at the application layer
> 
> Unfortunately you just state this, without giving
> any reasons for it.
> 
> If this were implemented in userspace (i.e. the Mono
> project),
> can you give a single reason why it needs to be
> extended into the kernel?
> 
> -- Jamie
> -
> 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/


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: 2.7 thoughts: common well-architected object model

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]

On Sun, 12 Oct 2003 09:04:19 PDT, retu said:

> What's the solution out of this - a clean, open object
> model designed by the core folks, extensible and free
> of licensing issues - and that in the next months.  

The point that seems to be continually missed is that although
it may be a *fine* concept for userspace, it doesn't belong in the
kernel.  There's a syscall barrier for multiple reasons, some technical
and some political/legal.

If anything, we collectively DON'T want to go there because a clever lawyer
could argue that doing a "all the way from kernel to userspace" object-oriented
scheme would make essentially all userspace code a derived work, since it would
be so tightly entwined with the kernel implementation (basically, you'd be
subjecting all of userspace to the same "derived work" limbo that closed-source
kernel modules currently live in).  This could render totally irrelevant this
text from /usr/src/linux/COPYING:

   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the Linux
 kernel) is copyrighted by me and others who actually wrote it.

Yes, this would mean that userspace would be GPL'ed as well, and
you'll never see Oracle on a Linux box again for a VERY long time....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.7 thoughts: common well-architected object model

[retu]

nobody says that it belongs into the kernel rather
designed by core=kernel folks core-up, that is e.g.
not being a derivative of a set of all-encompassing
classes developed for an application. 

I think the issue is serious and brushing it aside as
being non-kernel at first will come back biting.
What's going on could be described as being cornered. 


--- Valdis.Kletnieks@vt.edu wrote:
> On Sun, 12 Oct 2003 09:04:19 PDT, retu said:
> 
> > What's the solution out of this - a clean, open
> object
> > model designed by the core folks, extensible and
> free
> > of licensing issues - and that in the next months.
>  
> 
> The point that seems to be continually missed is
> that although
> it may be a *fine* concept for userspace, it doesn't
> belong in the
> kernel.  There's a syscall barrier for multiple
> reasons, some technical
> and some political/legal.
> 
> If anything, we collectively DON'T want to go there
> because a clever lawyer
> could argue that doing a "all the way from kernel to
> userspace" object-oriented
> scheme would make essentially all userspace code a
> derived work, since it would
> be so tightly entwined with the kernel
> implementation (basically, you'd be
> subjecting all of userspace to the same "derived
> work" limbo that closed-source
> kernel modules currently live in).  This could
> render totally irrelevant this
> text from /usr/src/linux/COPYING:
> 
>    NOTE! This copyright does *not* cover user
> programs that use kernel
>  services by normal system calls - this is merely
> considered normal use
>  of the kernel, and does *not* fall under the
> heading of "derived work".
>  Also note that the GPL below is copyrighted by the
> Free Software
>  Foundation, but the instance of code that it refers
> to (the Linux
>  kernel) is copyrighted by me and others who
> actually wrote it.
> 
> Yes, this would mean that userspace would be GPL'ed
> as well, and
> you'll never see Oracle on a Linux box again for a
> VERY long time....
> 

> ATTACHMENT part 2 application/pgp-signature 



__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: 2.7 thoughts: common well-architected object model

[viro]

On Sun, Oct 12, 2003 at 09:51:19AM -0700, retu wrote:
> 
> nobody says that it belongs into the kernel rather
> designed by core=kernel folks core-up, that is e.g.
> not being a derivative of a set of all-encompassing
> classes developed for an application. 
> 
> I think the issue is serious and brushing it aside as
> being non-kernel at first will come back biting.
> What's going on could be described as being cornered. 

With all due respect, whether you are cornered or not is none of our
problems.  Neither is whatever passes for your thought process.  So far
you have failed to produce anything except handwaving and some remarkably
ugly function prototypes.  Not interesting...

Re: 2.7 thoughts: common well-architected object model

[Rik van Riel]

On Sat, 11 Oct 2003, asdfd esadd wrote:

> So let me restate the need again for a:

Again?  Again no reason or justification?

       0   2   4   6   8   10
  
                        /
                       /
                      /
                     /
                    /
                   /
                  /
           TROLL-O-METER


-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: 2.7 thoughts: common well-architected object model

[Jamie Lokier]

retu wrote:
> What's the solution out of this - a clean, open object
> model designed by the core folks, extensible and free
> of licensing issues - and that in the next months.  

You still haven't said a single word about why this is good.
You haven't explained a _single_ advantage.

If you want anyone to take you seriously, you have to do this.  Give
real, convincing examples of what could be done, and why it's much
better, to justify the work of creating the model.

Perhaps you think your idea is self-evidently great, so you don't need
to explain why it is?  Well, it isn't.  I've seen startups fail due to not
grasping this basic point.

Almost everyone here does not think this is a good idea.  But we're
all old and prejudiced around here.  Perhaps we are mistaken, but if
so it's up to you to explain _why_.  Just saying "we need an object
model" will not convince anyone.

If you look into the kernel right now, you see that it's one of the
most object oriented C programs you will find.  There's even a type
called "kobject".  Another well known polymorphic object is called
"fd".  "pid_t" really is an object.  Filesystems, buses, devices,
network cards, protocols, timers and many other things have
hierarchies of object types inside the kernel.

It seems to me we _already_ have an object model in the kernel, and
it's a pretty good one because people figure out how to use it very
easily.  So what is wrong with the object model we already have?
Convince us, because what we have seems to be working quite well.

-- Jamie

Re: 2.7 thoughts: common well-architected object model

[James Antill]

asdfd esadd <retu834@yahoo.com> writes:

> There is a connex, fork() might be a bad example,
> 
> it's simple - yes but 20 years have passed as Solaris
> is finding:
> 
> pid_t fork(void); vs. 
> 
> the next step in the evolution CreateProcess
> 
> BOOL CreateProcess(...)

 If you _really_ want this on Linux, then you can look in
/usr/include/spawn.h

 Of course, as with all of these ungeneric interfaces, it should
really be called spawn-of-satan.h

-- 
# James Antill -- james@and.org
:0:
* ^From: .*james@and\.org
/dev/null

Re: 2.7 thoughts: common well-architected object model

[retu]

// these ungeneric interfaces will kill. Right now
it's a
{/usr/local/,/usr/bin/,/usr/..}NameYourClassLibrary_empty.
Below a list pasted from the .net namespace with many
dozens of classes covering everything from io to
drawing. 

They _appear for the most part to be consistent
wrappers to underlying existing APIs (including some
for >kernelspace< to userspace), are quite well done
although a little on the heavy side. I've not seen
Nextstep for years but this was a very good design
along the same lines and much thinner (implemented to
fly on 20MHz+ 68040s).

Hence, what would be needed is in the first place a
component model (well architected - thin - efficient)
that would allow folks to populate the other areas
successively. Replicating .net for licensing and
efficiency reasons (Linux ought to scale to HPC
levels), broadening some application class library OR
architecting something without the kernel in mind is
not it I believe. It's gotta come from the core, have
the ingenuity that leads others to build on it and not
start with a disconnect (to the kernelspace that is). 

If there are multiple sets of classes for e.g. 2D
drawing then so what as long as they use the same
Linux component model (which has yet to be defined or
even a grain of consens found that it is necessary in
the first place). 
 
Now here's the competition:

System 
System.CodeDom 
System.CodeDom.Compiler 
System.Collections 
System.Collections.Specialized 
System.ComponentModel 
System.ComponentModel.Design 
System.ComponentModel.Design.Serialization 
System.Configuration 
System.Configuration.Assemblies 
System.Configuration.Install 
System.Data 
System.Data.Common 
System.Data.Odbc 
System.Data.OleDb 
System.Data.OracleClient 
System.Data.SqlClient 
System.Data.SqlServerCE 
System.Data.SqlTypes 
System.Diagnostics 
System.Diagnostics.SymbolStore 
System.DirectoryServices 
System.Drawing 
System.Drawing.Drawing2D, System.Drawing.Imaging, and
System.Drawing.Text namespaces. 
System.Drawing.Design 
System.Drawing.Drawing2D 
System.Drawing.Imaging 
System.Drawing.Printing 
System.EnterpriseServices
System.Globalization 
System.IO 
System.IO.IsolatedStorage 
System.Management 
System.Net 
System.Net.Sockets 
System.Reflection 
System.Resources 
System.Runtime.CompilerServices 
System.Runtime.InteropServices 
System.Runtime.InteropServices.CustomMarshalers 
System.Runtime.InteropServices.Expando 
System.Runtime.Remoting 
System.Runtime.Remoting.Activation 
System.Runtime.Remoting.Channels 
System.Runtime.Remoting.Channels.Http 
System.Runtime.Remoting.Channels.Tcp 
System.Runtime.Remoting.Contexts 
System.Runtime.Remoting.Lifetime 
System.Runtime.Remoting.Messaging 
System.Runtime.Remoting.Metadata 
System.Runtime.Remoting.Metadata.W3cXsd2001 
System.Runtime.Remoting.MetadataServices 
System.Runtime.Remoting.Proxies 
System.Runtime.Remoting.Services 
System.Runtime.Serialization 
System.Runtime.Serialization.Formatters 
System.Runtime.Serialization.Formatters.Binary 
System.Runtime.Serialization.Formatters.Soap 
System.Security 
System.Security.Cryptography 
System.Security.Cryptography.X509Certificates 
System.Security.Cryptography.Xml 
System.Security.Permissions 
System.Security.Policy 
System.Security.Principal 
System.ServiceProcess 
System.Text 
System.Text.RegularExpressions 
System.Threading 
System.Timers 
System.Web 
System.Web.Caching 
System.Web.Hosting 
System.Web.Mail 
System.Web.Mobile 
System.Web.Security 
System.Web.Services 
System.Web.Services.Configuration 
System.Web.Services.Description 
System.Web.Services.Discovery 
System.Web.Services.Protocols 
System.Web.SessionState 
System.Web.UI 
System.Web.UI.Design 
System.Web.UI.Design.WebControls 
System.Web.UI.HtmlControls 
System.Web.UI.MobileControls 
System.Web.UI.MobileControls.Adapters 
System.Web.UI.WebControls 
System.Windows.Forms 
System.Windows.Forms.Design 
System.Xml 
System.Xml.Schema 
System.Xml.Serialization 
System.Xml.XPath 
System.Xml.Xsl 

These are massive and can't be built in a day. But
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.  


--- James Antill <james@and.org> wrote:
> asdfd esadd <retu834@yahoo.com> writes:
> 
> > There is a connex, fork() might be a bad example,
> > 
> > it's simple - yes but 20 years have passed as
> Solaris
> > is finding:
> > 
> > pid_t fork(void); vs. 
> > 
> > the next step in the evolution CreateProcess
> > 
> > BOOL CreateProcess(...)
> 
>  If you _really_ want this on Linux, then you can
> look in
> /usr/include/spawn.h
> 
>  Of course, as with all of these ungeneric
> interfaces, it should
> really be called spawn-of-satan.h
> 
> -- 
> # James Antill -- james@and.org
> :0:
> * ^From: .*james@and\.org
> /dev/null


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: 2.7 thoughts: common well-architected object model

[retu]

// these ungeneric interfaces will kill. Right now
it's a {/usr/local/,/usr/bin/,/usr/..}
NameYourClassLibrary_empty. Below a list pasted from
the .net namespace with many dozens of classes
covering everything from io to drawing. 

They _appear for the most part to be consistent
wrappers to underlying existing APIs (including some
for >kernelspace< to userspace), are quite well done
although a little on the heavy side. I've not seen
Nextstep for years but this was a very good design
along the same lines and much thinner (implemented to
fly on 20MHz+ 68040s).

Hence, what would be needed is in the first place a
component model (well architected - thin - efficient)
that would allow folks to populate the other areas
successively. Replicating .net for licensing and
efficiency reasons (Linux ought to scale to HPC
levels), broadening some application class library OR
architecting something without the kernel in mind is
not it I believe. It's gotta come from the core, have
the ingenuity that leads others to build on it and not
start with a disconnect (to the kernelspace that is). 

If there are multiple sets of classes for e.g. 2D
drawing then so what as long as they use the same
Linux component model (which has yet to be defined or
even a grain of consens found that it is necessary in
the first place). 
 
Now here's the competition:

System 
System.CodeDom 
System.CodeDom.Compiler 
System.Collections 
System.Collections.Specialized 
System.ComponentModel 
System.ComponentModel.Design 
System.ComponentModel.Design.Serialization 
System.Configuration 
System.Configuration.Assemblies 
System.Configuration.Install 
System.Data 
System.Data.Common 
System.Data.Odbc 
System.Data.OleDb 
System.Data.OracleClient 
System.Data.SqlClient 
System.Data.SqlServerCE 
System.Data.SqlTypes 
System.Diagnostics 
System.Diagnostics.SymbolStore 
System.DirectoryServices 
System.Drawing 
System.Drawing.Drawing2D, System.Drawing.Imaging, and
System.Drawing.Text namespaces. 
System.Drawing.Design 
System.Drawing.Drawing2D 
System.Drawing.Imaging 
System.Drawing.Printing 
System.EnterpriseServices
System.Globalization 
System.IO 
System.IO.IsolatedStorage 
System.Management 
System.Net 
System.Net.Sockets 
System.Reflection 
System.Resources 
System.Runtime.CompilerServices 
System.Runtime.InteropServices 
System.Runtime.InteropServices.CustomMarshalers 
System.Runtime.InteropServices.Expando 
System.Runtime.Remoting 
System.Runtime.Remoting.Activation 
System.Runtime.Remoting.Channels 
System.Runtime.Remoting.Channels.Http 
System.Runtime.Remoting.Channels.Tcp 
System.Runtime.Remoting.Contexts 
System.Runtime.Remoting.Lifetime 
System.Runtime.Remoting.Messaging 
System.Runtime.Remoting.Metadata 
System.Runtime.Remoting.Metadata.W3cXsd2001 
System.Runtime.Remoting.MetadataServices 
System.Runtime.Remoting.Proxies 
System.Runtime.Remoting.Services 
System.Runtime.Serialization 
System.Runtime.Serialization.Formatters 
System.Runtime.Serialization.Formatters.Binary 
System.Runtime.Serialization.Formatters.Soap 
System.Security 
System.Security.Cryptography 
System.Security.Cryptography.X509Certificates 
System.Security.Cryptography.Xml 
System.Security.Permissions 
System.Security.Policy 
System.Security.Principal 
System.ServiceProcess 
System.Text 
System.Text.RegularExpressions 
System.Threading 
System.Timers 
System.Web 
System.Web.Caching 
System.Web.Hosting 
System.Web.Mail 
System.Web.Mobile 
System.Web.Security 
System.Web.Services 
System.Web.Services.Configuration 
System.Web.Services.Description 
System.Web.Services.Discovery 
System.Web.Services.Protocols 
System.Web.SessionState 
System.Web.UI 
System.Web.UI.Design 
System.Web.UI.Design.WebControls 
System.Web.UI.HtmlControls 
System.Web.UI.MobileControls 
System.Web.UI.MobileControls.Adapters 
System.Web.UI.WebControls 
System.Windows.Forms 
System.Windows.Forms.Design 
System.Xml 
System.Xml.Schema 
System.Xml.Serialization 
System.Xml.XPath 
System.Xml.Xsl 

These are massive and can't be built in a day. But
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.  


--- James Antill <james@and.org> wrote:
> asdfd esadd <retu834@yahoo.com> writes:
> 
> > There is a connex, fork() might be a bad example,
> > 
> > it's simple - yes but 20 years have passed as
> Solaris
> > is finding:
> > 
> > pid_t fork(void); vs. 
> > 
> > the next step in the evolution CreateProcess
> > 
> > BOOL CreateProcess(...)
> 
>  If you _really_ want this on Linux, then you can
> look in
> /usr/include/spawn.h
> 
>  Of course, as with all of these ungeneric
> interfaces, it should
> really be called spawn-of-satan.h
> 
> -- 
> # James Antill -- james@and.org
> :0:
> * ^From: .*james@and\.org
> /dev/null



__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: 2.7 thoughts: common well-architected object model

[Nick Piggin]

retu wrote:

>// these ungeneric interfaces will kill. Right now
>it's a
>{/usr/local/,/usr/bin/,/usr/..}NameYourClassLibrary_empty.
>Below a list pasted from the .net namespace with many
>dozens of classes covering everything from io to
>drawing. 
>
>They _appear for the most part to be consistent
>wrappers to underlying existing APIs (including some
>for >kernelspace< to userspace), are quite well done
>although a little on the heavy side. I've not seen
>Nextstep for years but this was a very good design
>along the same lines and much thinner (implemented to
>fly on 20MHz+ 68040s).
>
>Hence, what would be needed is in the first place a
>component model (well architected - thin - efficient)
>that would allow folks to populate the other areas
>successively. Replicating .net for licensing and
>efficiency reasons (Linux ought to scale to HPC
>levels), broadening some application class library OR
>architecting something without the kernel in mind is
>not it I believe. It's gotta come from the core, have
>the ingenuity that leads others to build on it and not
>start with a disconnect (to the kernelspace that is). 
>
>If there are multiple sets of classes for e.g. 2D
>drawing then so what as long as they use the same
>Linux component model (which has yet to be defined or
>even a grain of consens found that it is necessary in
>the first place). 
> 
>Now here's the competition:
>

Retu,
I don't mean to sound rude, but you're mail is somewhat incoherent. 
Also, you
have not addressed some people's questions. This really frustrates 
people and
that can cause a potentially useful discussion to go nowhere.

What you need to do is raise or elaborate on _one_ idea per paragraph, have
some sort of introduction or overview and logically structure your argument
from there, stop using parentheses, stop using marketing buzzwords and most
of all, explain specifically WHY your ideas are better than what is already
available in Linux. Don't keep repeating how other operating systems do 
things
unless you back it up with an analysis of WHY it is better than what Linux
has.

Best Regards,
Nick Piggin

Re: 2.7 thoughts: common well-architected object model

[Tim Hockin]

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?

Re: 2.7 thoughts: common well-architected object model

[viro]

On Mon, Oct 13, 2003 at 10:31:55PM -0700, retu wrote:
> Now here's the competition:
> 
> System 
[snip the revolting offense against Occam's Razor]
> System.Xml.Xsl 
> 
> These are massive and can't be built in a day. But
> 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, take your cargo-cult education somewhere else.  You are yet to
show that you understand what does "component model" mean, let alone
to demonstrate that you are capable of discussing benefits of such
beasts.  "It had been mentioned in lecture notes" doesn't cut it.

Re: 2.7 thoughts: common well-architected object model

[Ihar 'Philips' Filipau]

asdfd esadd wrote:
> the other OS has an at this stage highly consistent
> object model user along the lines of COM+ from the
> kernel up encompassing a single event, thread etc.
> model. Things are quite consistently wrapped, user
> mode exposed if needed etc. If people were to fully
> draw on it and the simpler .net BCL and not ride win32
> that would (will be) a killer.  
> 
> So let me restate the need:
> 
> * a unified well architected core component model
> which is extensible from OS services to application
> objects
> 
> * the object model should be defined from the kernel
> layer for process/events/devices etc. up and not
> started at the application layer
> 

   Hm.

   Any real world application for which POSIX is not enough?
   Any real world application which can benefit /enourmosly/ from this?

   State, please, problem first - do not put the requirements ahead of 
problem.

   Since as of event system I would say POSIX (and Linux in particular) 
far ahead of permanently inconsistent Win32.
   [ Win32 is a very bad example, since you have there a "spawn one more 
thread" solution/workaround for any problem. Try to read MSDN by yourself. ]

P.S. <kidding> Probably Java is what you are looking for? (java.* after 
all some kind of kernel for Java, and jvm is some kind of cpu ;-)))) 
</kidding>

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
   "... and for $64000 question, could you get yourself vaguely
      familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML