2.7 thoughts: common well-architected object model
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
Quoted 2 lines · asdfd esadd
* 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?
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
Quoted 21 lines · --- [email protected] wrote:
Quoted 2 lines · asdfd esadd
* a unified well architected core component model
which is extensibleOK.. 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....
Quoted 6 lines
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
Quoted 8 lines · you
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.
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.
Quoted 43 lines · --- [email protected] wrote:
Quoted 2 lines · you
the other OS has an at this stage highly
consistent
Quoted 4 lines
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
Quoted 1 line
draw on it and the simpler .net BCL and not ride
win32
Quoted 1 line
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
implementread()in any way it wants, and the userspace callingread()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.
Quoted 1 line
ATTACHMENT part 2 application/pgp-signature
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Quoted 7 lines · you
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
_abstractmany 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.....
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.
Quoted 39 lines · --- [email protected] wrote:
Quoted 2 lines · you
unfortunately it's rather a jump into elegance.
The
Quoted 1 line
other OS component model is quite well
architected.
Quoted 1 line
Hence what's needed is _a similar architecture
effort
Quoted 1 line
which may
_abstractmany things in the beginningto be
Quoted 1 line
filled in later. Ther's a dire need for a sound
and
Quoted 1 line
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.....
Quoted 1 line
ATTACHMENT part 2 application/pgp-signature
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
On Sat, 11 Oct 2003, asdfd esadd wrote:
yah, right. could you please move this to comp.os.design.masturbation?
thanks!
Quoted 2 lines · On Sat, 11 Oct 2003 [email protected] wrote:
..... We're not the operating system run by
jackboots.
End of thread? ;)
Quoted 6 lines · Zwane Mwaikambo
Quoted 2 lines · On Sat, 11 Oct 2003 [email protected] 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...")
Signature · 4 lines
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))
Quoted 9 lines · asdfd esadd
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.
Signature · 3 lines
Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) Software Invention for High-Performance Computing
Quoted 8 lines · 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.
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
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
Quoted 48 lines · --- Kenn Humborg
Quoted 2 lines · asdfd esadd
the other OS has an at this stage highly
consistent
Quoted 4 lines
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
Quoted 1 line
draw on it and the simpler .net BCL and not ride
win32
Quoted 1 line
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
Quoted 7 lines
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected] 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
Quoted 18 lines · asdfd esadd
pid_tfork(void); vs.the next step in the evolution CreateProcess
BOOL CreateProcess(
LPCTSTR lpApplicationName,
LPTSTR lpCommandLine,
LPSECURITY_ATTRIBUTESlpProcessAttributes,
LPSECURITY_ATTRIBUTESlpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory,
LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATIONlpProcessInformationevolved to .Net Process Class
Quoted 8 lines
System.Object
System.MarshalByRefObject
System.ComponentModel.Component
System.Diagnostics.Process
[C#]
public class Process : Component
[C++]
public__gcclass Process : public Component
Thanks for the example of why it's a bad idea.
Quoted 8 lines · 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_tfork(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.
Quoted 12 lines
BOOL CreateProcess(
LPCTSTR lpApplicationName,
LPTSTR lpCommandLine,
LPSECURITY_ATTRIBUTESlpProcessAttributes,
LPSECURITY_ATTRIBUTESlpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory,
LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATIONlpProcessInformation
Quoted 1 line
evolved to .Net Process Class
"evolved to" is the wrong term - "wrapped by" is more accurate
Quoted 4 lines
System.Object
System.MarshalByRefObject
System.ComponentModel.Component
System.Diagnostics.Process
... which is a _user-land_ wrapper around CreateProcess.
Quoted 5 lines
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.
Quoted 3 lines
* 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
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.
Quoted 7 lines
Quoted 4 lines
System.Object
System.MarshalByRefObject
System.ComponentModel.Component
System.Diagnostics.Process... which is a _user-land_ wrapper around
CreateProcess.
Quoted 73 lines · --- Kenn Humborg
Quoted 3 lines · asdfd esadd
There is a connex,
fork()might be a bad example,it's simple - yes but 20 years have passed as
Solaris
Quoted 5 lines
is finding:
pid_tfork(void); vs.the next step in the evolution CreateProcess
CreateProcess()did _not_ evolve fromfork(). There is nofork()
equivalent in the Windows world. If anything it came more from
$CREPRC in VMS.Quoted 12 lines
BOOL CreateProcess(
LPCTSTR lpApplicationName,
LPTSTR lpCommandLine,
LPSECURITY_ATTRIBUTESlpProcessAttributes,
LPSECURITY_ATTRIBUTESlpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory,
LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATIONlpProcessInformationQuoted 1 line
evolved to .Net Process Class
"evolved to" is the wrong term - "wrapped by" is
more accurateQuoted 4 lines
System.Object
System.MarshalByRefObject
System.ComponentModel.Component
System.Diagnostics.Process... which is a _user-land_ wrapper around
CreateProcess.Quoted 4 lines
So let me restate the need again for a:
* unified well architected core component model
which is extensible from OS services toapplication
Quoted 1 line
objects
Which is a job for userland, in my opinion.
Quoted 1 line
* the object model should be defined from the
kernel
Quoted 2 lines
layer for process/events/devices etc. up and not
started at the application layerI 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
Quoted 7 lines
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected] 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
Quoted 1 line · Kenn Humborg
"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...
Quoted 11 lines · 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_tfork(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.
Quoted 8 lines
System.Object
System.MarshalByRefObject
System.ComponentModel.Component
System.Diagnostics.Process
[C#]
public class Process : Component
[C++]
public__gcclass 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?
Quoted 3 lines
* 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.
Quoted 3 lines
* 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
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
Quoted 81 lines · --- Jamie Lokier
Quoted 3 lines · asdfd esadd
There is a connex,
fork()might be a bad example,it's simple - yes but 20 years have passed as
Solaris
Quoted 7 lines
is finding:
pid_tfork(void); vs.the next step in the evolution CreateProcess
[extraordinarily long-winded way of saying the
same thing as
Quoted 1 line
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 withfork().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.Quoted 8 lines
System.Object
System.MarshalByRefObject
System.ComponentModel.Component
System.Diagnostics.Process
[C#]
public class Process : Component
[C++]
public__gcclass Process : public ComponentThis begins to make more sense. You do understand that unix has this
class too, but it's calledpid_t, not Process?Quoted 2 lines
* unified well architected core component model
which is extensible from OS services toapplication
Quoted 1 line
objects
Yeah, but CreateProcess _isn't_ well architected. It's among the
worst of excreta in Win32.Quoted 1 line
* the object model should be defined from the
kernel
Quoted 2 lines
layer for process/events/devices etc. up and not
started at the application layerUnfortunately 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?
Quoted 8 lines
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected] 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
Quoted 3 lines · retu
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....
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.
Quoted 44 lines · --- [email protected] wrote:
Quoted 1 line · retu
What's the solution out of this - a clean, open
object
Quoted 1 line
model designed by the core folks, extensible and
free
Quoted 1 line
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.
Quoted 7 lines
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
Quoted 9 lines · 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.
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...
Quoted 3 lines · retu
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
Quoted 1 line · asdfd esadd
So let me restate the need again for a:
Again? Again no reason or justification?
0 2 4 6 8 10
/
/
/
/
/
/
/
TROLL-O-METERSignature · 3 lines
"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
Quoted 10 lines · 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_tfork(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
Signature · 4 lines
# James Antill -- [email protected] :0: * ^From: .*james@and\.org /dev/null
// 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.
Quoted 14 lines · --- James Antill
Quoted 3 lines · asdfd esadd
There is a connex,
fork()might be a bad example,it's simple - yes but 20 years have passed as
Solaris
Quoted 7 lines
is finding:
pid_tfork(void); vs.the next step in the evolution CreateProcess
BOOL CreateProcess(...)
Quoted 13 lines
If you _really_ want this on Linux, then you can
look in/usr/include/spawn.hOf course, as with all of these ungeneric
interfaces, it should
really be calledspawn-of-satan.hSignature · 4 lines
# James Antill -- [email protected] :0: * ^From: .*james@and\.org /dev/null
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Quoted 26 lines · 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
_appearfor 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).
Quoted 8 lines
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
// 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.
Quoted 14 lines · --- James Antill
Quoted 3 lines · asdfd esadd
There is a connex,
fork()might be a bad example,it's simple - yes but 20 years have passed as
Solaris
Quoted 7 lines
is finding:
pid_tfork(void); vs.the next step in the evolution CreateProcess
BOOL CreateProcess(...)
Quoted 13 lines
If you _really_ want this on Linux, then you can
look in/usr/include/spawn.hOf course, as with all of these ungeneric
interfaces, it should
really be calledspawn-of-satan.hSignature · 4 lines
# James Antill -- [email protected] :0: * ^From: .*james@and\.org /dev/null
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
I've managed to stay out of this so far, but I can't anymore.
Quoted 3 lines · retu
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.
Quoted 2 lines
They
_appearfor the most part to be consistent wrappers to underlying existing APIs (including some
What is wrong with existing APIs that they need wrapping?
Quoted 2 lines
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?
Quoted 1 line
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.
Quoted 2 lines
levels), broadening some application class library OR architecting something without the kernel in mind is
Right, because EVERYTHING belongs in the kernel.
Quoted 2 lines
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.
Quoted 3 lines
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...
Quoted 3 lines
System
System.CodeDom
System.CodeDom.Compiler
...
Quoted 2 lines
System.Xml.XPath
System.Xml.Xsl
Other than being named 'System', what do they have to do with the kernel?
Quoted 5 lines
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?
Quoted 3 lines · retu
Now here's the competition:
System
[snip the revolting offense against Occam's Razor]
Quoted 8 lines
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.