* Re: 2.7 thoughts: common well-architected object model
2003-10-11 18:34 ` asdfd esadd
@ 2003-10-11 18:46 ` Valdis.Kletnieks
2003-10-11 19:01 ` Kenn Humborg
` (3 subsequent siblings)
4 siblings, 0 replies; 31+ messages in thread
From: Valdis.Kletnieks @ 2003-10-11 18:46 UTC (permalink / raw)
To: asdfd esadd; +Cc: Kenn Humborg, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: 2.7 thoughts: common well-architected object model
2003-10-11 18:34 ` asdfd esadd
2003-10-11 18:46 ` Valdis.Kletnieks
@ 2003-10-11 19:01 ` Kenn Humborg
2003-10-11 19:11 ` retu
2003-10-11 19:25 ` viro
2003-10-12 11:59 ` Jamie Lokier
` (2 subsequent siblings)
4 siblings, 2 replies; 31+ messages in thread
From: Kenn Humborg @ 2003-10-11 19:01 UTC (permalink / raw)
To: asdfd esadd; +Cc: Valdis.Kletnieks, linux-kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: 2.7 thoughts: common well-architected object model
2003-10-11 19:01 ` Kenn Humborg
@ 2003-10-11 19:11 ` retu
2003-10-11 19:25 ` viro
1 sibling, 0 replies; 31+ messages in thread
From: retu @ 2003-10-11 19:11 UTC (permalink / raw)
To: Kenn Humborg; +Cc: Valdis.Kletnieks, linux-kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.7 thoughts: common well-architected object model
2003-10-11 19:01 ` Kenn Humborg
2003-10-11 19:11 ` retu
@ 2003-10-11 19:25 ` viro
1 sibling, 0 replies; 31+ messages in thread
From: viro @ 2003-10-11 19:25 UTC (permalink / raw)
To: Kenn Humborg; +Cc: asdfd esadd, Valdis.Kletnieks, linux-kernel
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...
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.7 thoughts: common well-architected object model
2003-10-11 18:34 ` asdfd esadd
2003-10-11 18:46 ` Valdis.Kletnieks
2003-10-11 19:01 ` Kenn Humborg
@ 2003-10-12 11:59 ` Jamie Lokier
2003-10-12 16:04 ` retu
2003-10-12 20:21 ` Rik van Riel
2003-10-13 20:21 ` James Antill
4 siblings, 1 reply; 31+ messages in thread
From: Jamie Lokier @ 2003-10-12 11:59 UTC (permalink / raw)
To: asdfd esadd; +Cc: Kenn Humborg, Valdis.Kletnieks, linux-kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: 2.7 thoughts: common well-architected object model
2003-10-12 11:59 ` Jamie Lokier
@ 2003-10-12 16:04 ` retu
2003-10-12 16:44 ` Valdis.Kletnieks
2003-10-12 21:52 ` Jamie Lokier
0 siblings, 2 replies; 31+ messages in thread
From: retu @ 2003-10-12 16:04 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Kenn Humborg, Valdis.Kletnieks, linux-kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: 2.7 thoughts: common well-architected object model
2003-10-12 16:04 ` retu
@ 2003-10-12 16:44 ` Valdis.Kletnieks
2003-10-12 16:51 ` retu
2003-10-12 21:52 ` Jamie Lokier
1 sibling, 1 reply; 31+ messages in thread
From: Valdis.Kletnieks @ 2003-10-12 16:44 UTC (permalink / raw)
To: retu; +Cc: Jamie Lokier, Kenn Humborg, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.7 thoughts: common well-architected object model
2003-10-12 16:44 ` Valdis.Kletnieks
@ 2003-10-12 16:51 ` retu
2003-10-12 17:50 ` viro
0 siblings, 1 reply; 31+ messages in thread
From: retu @ 2003-10-12 16:51 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Jamie Lokier, Kenn Humborg, linux-kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.7 thoughts: common well-architected object model
2003-10-12 16:51 ` retu
@ 2003-10-12 17:50 ` viro
0 siblings, 0 replies; 31+ messages in thread
From: viro @ 2003-10-12 17:50 UTC (permalink / raw)
To: retu; +Cc: Valdis.Kletnieks, Jamie Lokier, Kenn Humborg, linux-kernel
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...
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.7 thoughts: common well-architected object model
2003-10-12 16:04 ` retu
2003-10-12 16:44 ` Valdis.Kletnieks
@ 2003-10-12 21:52 ` Jamie Lokier
1 sibling, 0 replies; 31+ messages in thread
From: Jamie Lokier @ 2003-10-12 21:52 UTC (permalink / raw)
To: retu; +Cc: Kenn Humborg, Valdis.Kletnieks, linux-kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.7 thoughts: common well-architected object model
2003-10-11 18:34 ` asdfd esadd
` (2 preceding siblings ...)
2003-10-12 11:59 ` Jamie Lokier
@ 2003-10-12 20:21 ` Rik van Riel
2003-10-13 20:21 ` James Antill
4 siblings, 0 replies; 31+ messages in thread
From: Rik van Riel @ 2003-10-12 20:21 UTC (permalink / raw)
To: asdfd esadd; +Cc: Kenn Humborg, Valdis.Kletnieks, linux-kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: 2.7 thoughts: common well-architected object model
2003-10-11 18:34 ` asdfd esadd
` (3 preceding siblings ...)
2003-10-12 20:21 ` Rik van Riel
@ 2003-10-13 20:21 ` James Antill
2003-10-14 5:01 ` retu
2003-10-14 5:31 ` retu
4 siblings, 2 replies; 31+ messages in thread
From: James Antill @ 2003-10-13 20:21 UTC (permalink / raw)
To: asdfd esadd; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: 2.7 thoughts: common well-architected object model
2003-10-13 20:21 ` James Antill
@ 2003-10-14 5:01 ` retu
2003-10-14 6:00 ` Nick Piggin
2003-10-14 5:31 ` retu
1 sibling, 1 reply; 31+ messages in thread
From: retu @ 2003-10-14 5:01 UTC (permalink / raw)
To: James Antill; +Cc: m.fioretti, linux-kernel
// 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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: 2.7 thoughts: common well-architected object model
2003-10-14 5:01 ` retu
@ 2003-10-14 6:00 ` Nick Piggin
0 siblings, 0 replies; 31+ messages in thread
From: Nick Piggin @ 2003-10-14 6:00 UTC (permalink / raw)
To: retu; +Cc: James Antill, m.fioretti, linux-kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.7 thoughts: common well-architected object model
2003-10-13 20:21 ` James Antill
2003-10-14 5:01 ` retu
@ 2003-10-14 5:31 ` retu
2003-10-14 6:05 ` Tim Hockin
2003-10-14 6:46 ` viro
1 sibling, 2 replies; 31+ messages in thread
From: retu @ 2003-10-14 5:31 UTC (permalink / raw)
To: James Antill; +Cc: m.fioretti, linux-kernel
// 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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: 2.7 thoughts: common well-architected object model
2003-10-14 5:31 ` retu
@ 2003-10-14 6:05 ` Tim Hockin
2003-10-14 6:46 ` viro
1 sibling, 0 replies; 31+ messages in thread
From: Tim Hockin @ 2003-10-14 6:05 UTC (permalink / raw)
To: retu; +Cc: James Antill, m.fioretti, linux-kernel
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?
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.7 thoughts: common well-architected object model
2003-10-14 5:31 ` retu
2003-10-14 6:05 ` Tim Hockin
@ 2003-10-14 6:46 ` viro
1 sibling, 0 replies; 31+ messages in thread
From: viro @ 2003-10-14 6:46 UTC (permalink / raw)
To: retu; +Cc: James Antill, m.fioretti, linux-kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread