RE: is KERNEL developement finished, yet ???

RE: is KERNEL developement finished, yet ???

[Ed Vance]

On Wed, December 04, 2002 at 4:28 PM, jeff millar wrote:
> My opinion...
> 
> Kernels are getting mature in the sense the there's not that 
> many ways to do tasking and hardware interface.  It no 
> longer a game of invention but a game of polishing.  The 
> amount of total work available probably continues to go
> up because kernels are becoming as common as screws.
> 
> It's like the guy who invented interchangable hardware in the
> 1700's...really cool and creates plenty of work but it's no 
> longer bleeding edge to design the next screw thread in the 
> next material.
> 
> So, do you want to push the edge and discover new principles 
> and go where no one has gone before?  Or do you want to make 
> the existing implementations better than anyone else ever has 
> before?
> 
> [ ... VHDL ... FPGA ]

Oh, ye of little imagination. 

It's only polishing because the new work must merge into the 
framework imposed by the old work (un*x legacy environment). 

If you assume nothing about OS architecture, there are still 
huge vistas of unexplored solution space, where no one has gone
before. It's just really hard for engineers to let go of the 
stuff that works and start climbing from the bottom of the 
mountain. 

cheers,

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

Re: is KERNEL developement finished, yet ???

[Shane Helms]

On Thursday 05 December 2002 02:00, Ed Vance wrote:
>
> Oh, ye of little imagination.
>
> It's only polishing because the new work must merge into the
> framework imposed by the old work (un*x legacy environment).
>
> If you assume nothing about OS architecture, there are still
> huge vistas of unexplored solution space, where no one has gone
> before. It's just really hard for engineers to let go of the
> stuff that works and start climbing from the bottom of the
> mountain.
>
> cheers,

I can agree that target based OSes are becoming popular these days, and 
leading companies try to build an optimized, task specific OS for their 
particular hardware and need.

But, if you're implying that we can start once again from bottom, and come up 
with something better that unix (which has been opensource, around for long 
while, tested and developed by many as well) I _HIGHLY_ doubt, and disagree. 
This is unless main kernel developers *confess* that some incorrect design 
decisions were made at the start (at a major section or so), which now 
they're forced to comply with, and let such bugs traverse through kernel 
versions, and there is no way to remove them, unless start from scratch 
again.

I doubt there be any such errors (mistakes) if ANY. but then, i'm not a kernel 
developer, and new to this whole mailing list !!

Shane

RE: is KERNEL developement finished, yet ???

[Joseph D. Wagner]

> if you're implying that we can start once
> again from bottom, and come up with something
> better that unix (which has been opensource,
> around for long while, tested and developed
> by many as well) I _HIGHLY_ doubt, and disagree.

Yes and no.

Unix (and Linux) developers are far too concerned with clinging to the
30-year-old outdated POSIX standard, which creates numerous problems when
trying to advance new features.  For example, the POSIX standard is the
reason we have the three-by-three secure permissions on files (three users:
owner, group, everyone; three permissions: read, write, execute) instead of
Access Control Lists (ACL's).

This is not a design flaw per say, but let's face it: Unix would be a lot
more secure (and more flexible in it's security) with ACL's.

Microsoft Windows has had ACL's since 1991 (Windows NT 3.5?); that was 11
years ago.  Linux is just now developing ACL's in some of the beta kernels.
(By "Linux" I mean the official Linux kernel as distributed by
www.kernel.org not these stupid add-on's and patches released by
third-parties)

> I doubt there be any such errors (mistakes) if ANY

I don't know of any mistakes per say, but if I had to do it over again,
there's about a thousands things I'd do differently (preference in design
choices, not mistakes) especially not to cling so religiously to POSIX
compliance.

Re: is KERNEL developement finished, yet ???

[Andreas Schwab]

"Joseph D. Wagner" <wagnerjd@prodigy.net> writes:

|> > if you're implying that we can start once
|> > again from bottom, and come up with something
|> > better that unix (which has been opensource,
|> > around for long while, tested and developed
|> > by many as well) I _HIGHLY_ doubt, and disagree.
|> 
|> Yes and no.
|> 
|> Unix (and Linux) developers are far too concerned with clinging to the
|> 30-year-old outdated POSIX standard, which creates numerous problems when
|> trying to advance new features.  For example, the POSIX standard is the
|> reason we have the three-by-three secure permissions on files (three users:
|> owner, group, everyone; three permissions: read, write, execute) instead of
|> Access Control Lists (ACL's).

POSIX is only codifying existing practice.  Would there have been a decent
and agreed-upon ACL API in Unix 10 years ago, POSIX would surely have
standardized it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: is KERNEL developement finished, yet ???

[Linus Torvalds]

In article <000901c29c5d$6d194760$2e833841@joe>,
Joseph D. Wagner <wagnerjd@prodigy.net> wrote:
>
>Unix (and Linux) developers are far too concerned with clinging to the
>30-year-old outdated POSIX standard, which creates numerous problems when
>trying to advance new features.

No.

Only stupid people think they should throw away old proven concepts. 
What happens quite often in academia in particular is that you find a
problem you want to fix, and you re-design the whole system around your
fix. 

This is how we get crap like microkernels.  They have "an agenda", and
that's the _worst_ thing you can have when designing software.  You
fixate on some perceived problem, and the end result is that yes, maybe
you fixed _that_ problem, but in the meantime you also generated a whole
new of issues - usually things that were solved by the original
approach. 

The UNIX/Linux approach is a very pragmatic thing - leave the things
that work well alone.  There's no point in re-inventing the whole system
just because of some small perceived flaws. 

>This is not a design flaw per say, but let's face it: Unix would be a lot
>more secure (and more flexible in it's security) with ACL's.
>
>Microsoft Windows has had ACL's since 1991 (Windows NT 3.5?); that was 11
>years ago.

Yeah, and look how much more secure it is than UNIX.

		Linus

Re: is KERNEL developement finished, yet ???

[Shane Helms]

On Thursday 05 December 2002 18:07, Linus Torvalds wrote:
> In article <000901c29c5d$6d194760$2e833841@joe>,
>
> Joseph D. Wagner <wagnerjd@prodigy.net> wrote:
> >Unix (and Linux) developers are far too concerned with clinging to the
> >30-year-old outdated POSIX standard, which creates numerous problems when
> >trying to advance new features.
>
> No.
>
> Only stupid people think they should throw away old proven concepts.
> What happens quite often in academia in particular is that you find a
> problem you want to fix, and you re-design the whole system around your
> fix.

Being curious, I was wondering, since we're not changing much in kernel core, 
and developement implies adding additional code and layers for security, 
enhancements and support for further hardware and etc.
Does this not slow down the kernel ? or is the execution code still the same 
??
How does kernel optimization take place ? does it take place at all ??

I can hardly see optimization taking place, if one doesn't modify the old 
code, and chunks of kernel.

Shane

Re: is KERNEL developement finished, yet ???

[Linus Torvalds]

On Thu, 5 Dec 2002, Shane Helms wrote:
>
> Being curious, I was wondering, since we're not changing much in kernel core,
> and developement implies adding additional code and layers for security,
> enhancements and support for further hardware and etc.
> Does this not slow down the kernel ? or is the execution code still the same
> ??

Oh, some things do get slower. We try to avoid hitting the critical paths,
and supporting new hardware for example (which tends to be a large portion
of kernel development, even if it isn't as sexy as new features) doesn't
impact the rest of the kernel negatively at all.

What we'll probably see in 2.6.x for example, is that many microbenchmarks
show slight deprovement (fork() and execve() have become noticeably slower
due to the rmap patches), but to at least somewhat offset that we get much
nicer worst-case behaviour and better scalability.

And many things _can_ be done without throwing out old designs.
Implementation improvements are quite possible without trying to make
something totally new to the outside. That's how things like the dcache
come about, for example - keeping the standard old boring UNIX filesystem
approach, while internally caching it in new ways, improving performance
tremendously.

Not throwing out the baby with the bath-water doesn't mean that you cannot
improve the system. I'm only arguing against stupid people who think they
need a revolution to improve - most real improvements are evolutionary.

		Linus

Re: is KERNEL developement finished, yet ??? (ACLs)

[Tupshin Harper]

Linus Torvalds wrote:

> Only stupid people think they should throw away old proven concepts. 
> What happens quite often in academia in particular is that you find a
> problem you want to fix, and you re-design the whole system around your
> fix. 
Agreed...
> 
> The UNIX/Linux approach is a very pragmatic thing - leave the things
> that work well alone.  There's no point in re-inventing the whole system
> just because of some small perceived flaws. 
> 
Agreed...
> 
>>This is not a design flaw per say, but let's face it: Unix would be a lot
>>more secure (and more flexible in it's security) with ACL's.
>>
>>Microsoft Windows has had ACL's since 1991 (Windows NT 3.5?); that was 11
>>years ago.
> 
> 
> Yeah, and look how much more secure it is than UNIX.
> 
> 		Linus
An unfortunately inflamatory argument that avoids the real issue.  I'm 
not going to argue the security of NT (heaven forbid), but you do 
completely ignore the benefits of ACLs, including things that 
capabilities don't provide.

The fundamental problem is that while there is a many-to-many 
relationship between users and groups, there is only a one-to-many 
relationship between files and groups. This inequity breeds kludgy 
solutions to problems that would be easy with the many-to-many 
group/file relationships that ACLs provide

A simple example would be four non-root users of a system where user A 
would like to provide read and write access to a file with users B and C 
but not D and access to another file with C and D, but not B. Without 
ACLs this is jut not possible without root setting up one group that 
encompasses B and C, and another for C and D. Obviously not a scalable 
or convenient solution.

This trivial example get's magnified when trying to delegate 
administration tasks on a large system. In these cases, groups could 
feasibly be set up to encompass every permutation, but can quickly get 
unwieldy.

I'm not at all opposed to capabilities, but I don't believe they come 
close to obviating ACLs. It also doesn't seem ACLs and capabilities are 
in any kind of conflict. Why could we not have both?

-Tupshin

Re: is KERNEL developement finished, yet ??? (ACLs)

[Jakob Oestergaard]

On Thu, Dec 05, 2002 at 12:09:25PM -0800, Tupshin Harper wrote:
...
> >Yeah, and look how much more secure it is than UNIX.
> >
> >		Linus
> An unfortunately inflamatory argument that avoids the real issue.  I'm 
> not going to argue the security of NT (heaven forbid), but you do 
> completely ignore the benefits of ACLs, including things that 
> capabilities don't provide.
[snip - big argument, ACLs, seen 100 times on lkml before]

DAC (ACLs) add flexibility to security configurations, no argument
there.  Flexibility != security.

DAC without MAC is insane.

Read "The Inevitability of Failure":
   http://www.nsa.gov/selinux/inevit-abs.html

Yes, the current owner/group/other system is DAC too. Adding more
"flexible" (read: disaster-prone) features before MAC (eg. SELinux) is a
standard part of the kernel, is ludicrous.

And no, NT doesn't have MAC. Nor are they likely to get it. Guess why
any local user absolutely 0wnZ an NT box...

If you want to argue with me on these statements, please take it off
list.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: is KERNEL developement finished, yet ??? (ACLs)

[Tracy R Reed]

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

On Thu, Dec 05, 2002 at 12:09:25PM -0800, Tupshin Harper spake thusly:
> I'm not at all opposed to capabilities, but I don't believe they come 
> close to obviating ACLs. It also doesn't seem ACLs and capabilities are 
> in any kind of conflict. Why could we not have both?

SE Linux seems to give you both.

-- 
Tracy Reed      http://www.ultraviolet.org

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

Re: is KERNEL developement finished, yet ???

[Kai Henningsen]

torvalds@transmeta.com (Linus Torvalds)  wrote on 05.12.02 in <aso4kq$2ka$1@penguin.transmeta.com>:

> In article <000901c29c5d$6d194760$2e833841@joe>,
> Joseph D. Wagner <wagnerjd@prodigy.net> wrote:
> >
> >Unix (and Linux) developers are far too concerned with clinging to the
> >30-year-old outdated POSIX standard, which creates numerous problems when
> >trying to advance new features.
>
> No.
>
> Only stupid people think they should throw away old proven concepts.
> What happens quite often in academia in particular is that you find a
> problem you want to fix, and you re-design the whole system around your
> fix.

Well, yes and no.

Yes, it's usually a bad idea to do that and expect to get a production- 
level kernel out of it.

But on the other hand, there's a lot that *could* be done with OS kernels  
that has never been tried (even though I certainly couldn't give a list).  
Until someone implements one of those ideas, and experiments with the  
results for a while, it's impossible to know what it would be worth in  
practice. (I certainly wouldn't want to trust a theoretical evaluation!)

Then, *if* it looks good in an experimental OS, people still need to  
figure out how to make use of it in a more traditional kernel. Sometimes  
that's where it breaks. Sometimes not.

If you just remember that academic OSes are *research*, not production  
material, then they are fine. Unfortunately, too many people (including  
many academics) forget that.

There's a reason we have both science and engineering, and they're not the  
same discipline.

MfG Kai

RE: is KERNEL developement finished, yet ???

[Alan Cox]

On Thu, 2002-12-05 at 12:54, Joseph D. Wagner wrote:
> trying to advance new features.  For example, the POSIX standard is the
> reason we have the three-by-three secure permissions on files (three users:
> owner, group, everyone; three permissions: read, write, execute) instead of
> Access Control Lists (ACL's).

POSIX allows ACLS and MAC.


> I don't know of any mistakes per say, but if I had to do it over again,
> there's about a thousands things I'd do differently (preference in design
> choices, not mistakes) especially not to cling so religiously to POSIX
> compliance.

And then you'd have no applications.

Re: is KERNEL developement finished, yet ???

[yodaiken]

On Thu, Dec 05, 2002 at 06:09:56PM +0000, Alan Cox wrote:
> > I don't know of any mistakes per say, but if I had to do it over again,
> > there's about a thousands things I'd do differently (preference in design
> > choices, not mistakes) especially not to cling so religiously to POSIX
> > compliance.
> 
> And then you'd have no applications.

The advantage of POSIX is that it allows you to work on interesting app and OS problems
instead of API, which is not interesting.
> 
> -
> 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/

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com  www.rtlinux.com
1+ 505 838 9109

Re: is KERNEL developement finished, yet ???

[John Bradford]

> > I don't know of any mistakes per say, but if I had to do it over again,
> > there's about a thousands things I'd do differently (preference in design
> > choices, not mistakes) especially not to cling so religiously to POSIX
> > compliance.
> 
> And then you'd have no applications.

You can always design a new operating system, but include POSIX
compliance, to make porting applications easier.  Atheos,
(http://atheos.cx), does just this - that's why you can easily run
Apache, EMACS, etc, etc, on it - but it's not really a *nix based OS.

John.

RE: is KERNEL developement finished, yet ???

[Joseph D. Wagner]

>> I don't know of any mistakes per say, but if I had
>> to do it over again, there's about a thousands things
>> I'd do differently (preference in design choices, not
>> mistakes) especially not to cling so religiously to
>> POSIX compliance.

> And then you'd have no applications.

I AM NOT AN IDIOT! DON'T YOU THINK I KNOW THAT?

It's MY PREFERENCE in operating system design choices.  I don't have to make
it compatible with anyone else's.

Joseph Wagner

Re: is KERNEL developement finished, yet ???

[John Alvord]

On Fri, 6 Dec 2002 00:15:15 -0600, "Joseph D. Wagner"
<wagnerjd@prodigy.net> wrote:

>>> I don't know of any mistakes per say, but if I had
>>> to do it over again, there's about a thousands things
>>> I'd do differently (preference in design choices, not
>>> mistakes) especially not to cling so religiously to
>>> POSIX compliance.
>
>> And then you'd have no applications.
>
>I AM NOT AN IDIOT! DON'T YOU THINK I KNOW THAT?
>
>It's MY PREFERENCE in operating system design choices.  I don't have to make
>it compatible with anyone else's.
>
>Joseph Wagner

Indeed... go forth and prosper... but not perhaps on the linux-kernel
list where polishing the particular jewel "Linux" is in progress.

john alvord

Re: is KERNEL developement finished, yet ???

[Alvaro Lopes]

Joseph D. Wagner wrote:

>I AM NOT AN IDIOT! DON'T YOU THINK I KNOW THAT?
>
>It's MY PREFERENCE in operating system design choices.  I don't have to make
>it compatible with anyone else's.
>  
>
Ok, and you'll end up like OS/2. Dead.
Even Apple gave up on MacOS. Now they're using a UNIX variant, everybody 
is lots happier. They can run The Gimp.


Álvaro

Re: is KERNEL developement finished, yet ???

[Kai Henningsen]

alvieboy@alvie.com (Alvaro Lopes)  wrote on 06.12.02 in <3DF07251.7020109@alvie.com>:

> Even Apple gave up on MacOS. Now they're using a UNIX variant, everybody
> is lots happier. They can run The Gimp.

Well, it *is* cheap.

But whenever I hear from anybody who regularly does nontrivial stuff in  
that area and knows more software than just The Gimp, what they have to  
say about The Gimp isn't particularly flattering.

It seems The Gimp isn't quite at the same level in its area as, say, the  
Linux kernel is in its.

MfG Kai

Re: is KERNEL developement finished, yet ???

[Kai Henningsen]

alan@lxorguk.ukuu.org.uk (Alan Cox)  wrote on 05.12.02 in <1039111796.19636.27.camel@irongate.swansea.linux.org.uk>:

> On Thu, 2002-12-05 at 12:54, Joseph D. Wagner wrote:

> > I don't know of any mistakes per say, but if I had to do it over again,
> > there's about a thousands things I'd do differently (preference in design
> > choices, not mistakes) especially not to cling so religiously to POSIX
> > compliance.
>
> And then you'd have no applications.

And this is why every existing OS is POSIX compliant.

What do you mean, it isn't?

People actually started new, incompatible OSes from time to time, for  
which there were no applications, and some of those actually succeeded?

And in fact Unix was one of those?

MfG Kai

Re: is KERNEL developement finished, yet ???

[Jesse Pollard]

On Saturday 07 December 2002 02:39 pm, Kai Henningsen wrote:
> alan@lxorguk.ukuu.org.uk (Alan Cox)  wrote on 05.12.02 in 
<1039111796.19636.27.camel@irongate.swansea.linux.org.uk>:
> > On Thu, 2002-12-05 at 12:54, Joseph D. Wagner wrote:
> > > I don't know of any mistakes per say, but if I had to do it over again,
> > > there's about a thousands things I'd do differently (preference in
> > > design choices, not mistakes) especially not to cling so religiously to
> > > POSIX compliance.
> >
> > And then you'd have no applications.
>
> And this is why every existing OS is POSIX compliant.
>
> What do you mean, it isn't?
>
> People actually started new, incompatible OSes from time to time, for
> which there were no applications, and some of those actually succeeded?

No - they have pretty much all failed except M$, and that one is showing 
cracks.

> And in fact Unix was one of those?

Unix DEFINED the standard. Before that, there were many "standards", a minimum
of one for each vendor, and frequently, several for each vendor. IBM almost
had one for every product line, DEC had one for each major product line, and
three different major OSs (though related) for the PDP11 (RSX 11, IAS, RSTS)
and one minor (RT-11). Each had it's own runtime, compilers/assemblers,
utilities, and system calls.

The POSIX definitions were adaped from the AT&T "System V Interface
Definition" issued in 1984/1985, which standardized AT&T Unix from about 1982
through 1985 (the existing commands/utilities/libraries definitions were
included).

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: is KERNEL developement finished, yet ???

[H. Peter Anvin]

Followup to:  <200212090808.34598.pollard@admin.navo.hpc.mil>
By author:    Jesse Pollard <pollard@admin.navo.hpc.mil>
In newsgroup: linux.dev.kernel
> >
> > People actually started new, incompatible OSes from time to time, for
> > which there were no applications, and some of those actually succeeded?
> 
> No - they have pretty much all failed except M$, and that one is showing 
> cracks.
> 

M$ started by buying an OS called QDOS (Quick and Dirty Operating
System -- I kid you not), which was a quick-hack clone of CP/M
intended to get a chance to test ports of hardware and software from
CP/M-80 before CP/M-86 came out.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: is KERNEL developement finished, yet ???

[Mikael Pettersson]

Shane Helms writes:
 > But, if you're implying that we can start once again from bottom, and come up 
 > with something better that unix (which has been opensource, around for long 
 > while, tested and developed by many as well) I _HIGHLY_ doubt, and disagree. 
 >...
 > I doubt there be any such errors (mistakes) if ANY. but then, i'm not a kernel 
 > developer, and new to this whole mailing list !!

Signal delivery on the current stack as opposed to a process-global
or per-signal sigaltstack is broken as hell. It messes up user-space
code that uses customised stack management methods.

sigaction() with SA_ONSTACK is unreliable because in reality applications
have linked-in libraries, and those libraries have no standard way of
knowing whether the main application wants SA_ONSTACK or not.

LD_PRELOAD:ing your own sigaction() is also unreliable, because C libs
tend to have internal calls that bypass the external name and go directly
to the internal __libc_sigaction() or whatever it happens to be called.

/Mikael