Dear all,
I would like to know that how i will get a notifiocation in my network cs
driver while I am using the service "service pcmcia stop" or a card removal.
If I could get the notification is it calls before the exit_module.
Thanks in advance
Santhosh K
I'd like most of you to answer the following question, that includes even
Linus.
I love C programming at low level (ie kernel, embedded, etc) and i'm seriously
good at it. But don't know whether I should persue it as my main Career or
just as an Interest. My question is, is there, yet, any area at this low
level to be discovered and developed on ? or as most ppl say, are the
interesting parts over and it's just now into patches, bugs and slight
enhancements/optimizations/securities ?
I'm starting a Post-Graduate studies at April, and need to know, whether it's
worth going into Computer Architecture Group as my main career, or shall I
stir towards a another area like networking which is still in developement,
and plenty of jobs (but not as interssting as kernel/OS programming) ?????
please reply, and if in favor of kernel developement, try to name some areas
where there yet relies hope.
Thanks,
Shane
> My question is, is there, yet, any area at this low
> level to be discovered and developed on ? or as most
> ppl say, are the interesting parts over and it's just
> now into patches, bugs and slight
> enhancements/optimizations/securities ?
Ha ha ha. Kernel development over. That's rich. I can't speak for the
Linux kernel developers; they're a vindictive group (and the "to-do"
list of their vision for future kernel development is no where to be
found).
However, I know Mach and GNU Hurd, which are both microkernels, have
plenty of room for low-level pioneers.
Personally, I think the most interesting aspects of kernel development
and research are taking place on microkernels.
> need to know, whether it's worth going into Computer
> Architecture Group as my main career, or shall I stir
> towards a another area like networking which is still
> in developement, and plenty of jobs (but not as
> interssting as kernel/OS programming) ?????
Do both. Or, ask yourself this: Would I rather do something I love and
risk being unemployed, or have plenty of job security with only
moderately entertaining tasks? It's up to you, and maybe the job market
for kernel development isn't that bad.
Another aspect of computer science you might want to consider is
compilers; that's always low level, and they may need those people for
all those hand- held devices.
Joseph Wagner
Hope you are wearing flame retardant underwear today ;)
On Wed, 2002-12-04 at 13:38, Alan Cox wrote:
> On Wed, 2002-12-04 at 17:01, Joseph D. Wagner wrote:
> > However, I know Mach and GNU Hurd, which are both microkernels, have
> > plenty of room for low-level pioneers.
> >
> > Personally, I think the most interesting aspects of kernel development
> > and research are taking place on microkernels.
>
> Oh dear. Maybe people should do useful research instead 8)
>
> <runs>
>
On Wed, 2002-12-04 at 17:01, Joseph D. Wagner wrote:
> However, I know Mach and GNU Hurd, which are both microkernels, have
> plenty of room for low-level pioneers.
>
> Personally, I think the most interesting aspects of kernel development
> and research are taking place on microkernels.
Oh dear. Maybe people should do useful research instead 8)
<runs>
On 4 Dec 2002, Richard B. Tilley (Brad) wrote:
> Hope you are wearing flame retardant underwear today ;)
In 1898, the United States Congress planned to close
the US Patent Office because; "Everything that could be
invented has already been invented...."
Deja` vu
>
> On Wed, 2002-12-04 at 13:38, Alan Cox wrote:
> > On Wed, 2002-12-04 at 17:01, Joseph D. Wagner wrote:
> > > However, I know Mach and GNU Hurd, which are both microkernels, have
> > > plenty of room for low-level pioneers.
> > >
> > > Personally, I think the most interesting aspects of kernel development
> > > and research are taking place on microkernels.
> >
> > Oh dear. Maybe people should do useful research instead 8)
> >
> > <runs>
> >
>
>
> -
> 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/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
On Wed Dec 04, 2002 at 01:21:04PM -0500, Richard B. Johnson wrote:
> On 4 Dec 2002, Richard B. Tilley (Brad) wrote:
>
> > Hope you are wearing flame retardant underwear today ;)
>
> In 1898, the United States Congress planned to close
> the US Patent Office because; "Everything that could be
> invented has already been invented...."
Too bad they didn't follow through and actually close it. :)
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
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?
If you want to stay with programming close to the hardware, think about
pulling the essential elements of I/O drivers and some parts of applications
into VHDL and programmable hardware (FPGA's)...then hook those into the
kernel effectively and in an open architecture sort of way.
jeff
----- Original Message -----
From: "Shane Helms" <[email protected]>
To: <[email protected]>
Sent: Wednesday, December 04, 2002 10:26 AM
Subject: is KERNEL developement finished, yet ???
> I'd like most of you to answer the following question, that includes even
> Linus.
>
> I love C programming at low level (ie kernel, embedded, etc) and i'm
seriously
> good at it. But don't know whether I should persue it as my main Career or
> just as an Interest. My question is, is there, yet, any area at this low
> level to be discovered and developed on ? or as most ppl say, are the
> interesting parts over and it's just now into patches, bugs and slight
> enhancements/optimizations/securities ?
>
> I'm starting a Post-Graduate studies at April, and need to know, whether
it's
> worth going into Computer Architecture Group as my main career, or shall I
> stir towards a another area like networking which is still in
developement,
> and plenty of jobs (but not as interssting as kernel/OS programming) ?????
>
> please reply, and if in favor of kernel developement, try to name some
areas
> where there yet relies hope.
>
> Thanks,
>
> Shane
> -
> 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/
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
----------------------------------------------------------------
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
> 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
http://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.
"Joseph D. Wagner" <[email protected]> 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, [email protected]
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."
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
>>> "Joseph D. Wagner" <[email protected]> 12/05/02 07:54AM >>>
> 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.
Er, 16-year-old maybe?
> Er, 16-year-old maybe?
Wow! I thought I really knew what I was talking about, but you've really
convinced me to see things you're way!
I would prefer that this discussion contain factual information and educated
opinions, and if those facts turn out to be wrong or opinions based on
erroneous information, I would like to see them corrected with sources and
citations.
But if you're just going to call names, you're just wasting space on the
archive server.
On Thu, Dec 05, 2002 at 09:17:04AM -0600, Joseph D. Wagner wrote:
> > Er, 16-year-old maybe?
>
> Wow! I thought I really knew what I was talking about, but you've really
> convinced me to see things you're way!
>
> I would prefer that this discussion contain factual information and educated
> opinions, and if those facts turn out to be wrong or opinions based on
> erroneous information, I would like to see them corrected with sources and
> citations.
http://www.pasc.org/#POSIX
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
>>>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.
>>Er, 16-year-old maybe?
>Wow! I thought I really knew what I was talking about, but you've really
>convinced me to see things you're way!
>[snip]
"In early 1985, the /usr/group committee was merged with the newly formed
IEEE POSIX Working Group (POSIX stands for Portable Operating Systems
for Computing Environments) and the /usr/group standard was adopted as a
first draft."
UN*Xen were around for 15 years before anybody was brave (or stupid :)
enough to really standardize. The first drafts of these standards are only
16-18 years old.
http://www.acm.org/crossroads/xrds1-3/unix-standards.html
--
------------------------------------------------------------
Eric H. Weigle -- http://public.lanl.gov/ehw/
"They that can give up essential liberty to obtain a little
temporary safety deserve neither" -- Benjamin Franklin
------------------------------------------------------------
Sorry about my trigger finger. I just get so many flames; I just assumed
you were insulting me.
BTW, you could have been a little clear that you were referring to the age
of POSIX, not my age.
Joseph Wagner
On Wed, 4 Dec 2002, Richard B. Johnson wrote:
> On 4 Dec 2002, Richard B. Tilley (Brad) wrote:
>
> > Hope you are wearing flame retardant underwear today ;)
>
> In 1898, the United States Congress planned to close
> the US Patent Office because; "Everything that could be
> invented has already been invented...."
Clearly not... someone invented the "software patent," didn't they?
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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.
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 [email protected]
> 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.
http://www.fsmlabs.com http://www.rtlinux.com
1+ 505 838 9109
In article <000901c29c5d$6d194760$2e833841@joe>,
Joseph D. Wagner <[email protected]> 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
> > 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.
On Thursday 05 December 2002 18:07, Linus Torvalds wrote:
> In article <000901c29c5d$6d194760$2e833841@joe>,
>
> Joseph D. Wagner <[email protected]> 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
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
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
On Wed, Dec 04, 2002 at 07:27:40PM -0500, 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.
no
Everytime once in a while someone thinks that everything which can
be invented has been invented. Books like "The end of science". It's
pure hubris.
Around 1930 it was proven that is was impossible to travel to the
moon. Then mankind discovered multi stage rockets and nuclear energy
(not even needed for that).
It's incredible how narrow-minded established science sometimes is today
(and often has been past centuries). There is too much conservatism and
a general lack of imagination (though I must admit that no SF writer
could come up with something as bizarre as quantum mechanics, QED,
string theory and a few other things).
Software and more specific kernel development has quite a short history
compared to all of that. So, let's be humble and accept that what we
do today will most likely be considered a trivial joke when the next
century arrives.
You don't know what you do now know today.
--
Frank
On Thursday 05 December 2002 23:55, Frank van Maarseveen wrote:
> It's incredible how narrow-minded established science sometimes is today
> (and often has been past centuries). There is too much conservatism and
> a general lack of imagination (though I must admit that no SF writer
> could come up with something as bizarre as quantum mechanics, QED,
> string theory and a few other things).
>
> Software and more specific kernel development has quite a short history
> compared to all of that. So, let's be humble and accept that what we
> do today will most likely be considered a trivial joke when the next
> century arrives.
>
> You don't know what you do now know today.
>
> Frank
Hey Frank,
Must admit, you really cracked me up buddy.
FYI, I sent this mail around originally to get an idea of what are the open
fields yet to be explored at kernel level for my post grad studies.
My post grad studies start next year april, and i have to submit a project
proposal by then.
Unfortunately I don't think I'd be alive until next century either, but i'm
sure many changes are to happen till then.
Shane
Harnessing energy (rockets, nukes, etc) is fundamentally an unlimited
engineering opportunity. But kernel development is mostly an attempt to
reduce overhead to zero. If a kernel runs 90% efficient now, then there's
only 10% additional improvement possible.
On the other hand application software is fundamentally unlimited.
So if you want to work on reliability, portability, maintainability, and
adaptation to new hardware then kernels make a good career. But if you want
to break new ground, then it's either application space or hardware.
jeff
----- Original Message -----
From: "Frank van Maarseveen" <[email protected]>
To: <[email protected]>
Sent: Thursday, December 05, 2002 6:55 PM
Subject: Re: is KERNEL developement finished, yet ???
> On Wed, Dec 04, 2002 at 07:27:40PM -0500, 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.
>
> no
>
> Everytime once in a while someone thinks that everything which can
> be invented has been invented. Books like "The end of science". It's
> pure hubris.
>
> Around 1930 it was proven that is was impossible to travel to the
> moon. Then mankind discovered multi stage rockets and nuclear energy
> (not even needed for that).
>
> It's incredible how narrow-minded established science sometimes is today
> (and often has been past centuries). There is too much conservatism and
> a general lack of imagination (though I must admit that no SF writer
> could come up with something as bizarre as quantum mechanics, QED,
> string theory and a few other things).
>
> Software and more specific kernel development has quite a short history
> compared to all of that. So, let's be humble and accept that what we
> do today will most likely be considered a trivial joke when the next
> century arrives.
>
> You don't know what you do now know today.
>
> --
> Frank
> -
> 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/
On Thu, 2002-12-05 at 11:36, Joseph D. Wagner wrote:
> Sorry about my trigger finger. I just get so many flames; I just assumed
> you were insulting me.
>
> BTW, you could have been a little clear that you were referring to the age
> of POSIX, not my age.
>
> Joseph Wagner
Gee ... I wish someone would call me 16-years-old. Said by an old man
who just turned 50 and can remember Unix when we both were young.
"jeff millar" <[email protected]> writes:
> If a kernel runs 90% efficient now, then there's only 10% additional
> improvement possible. If you want to break new ground, then it's
> either application space or hardware.
YEah, but then the guys taking advantage of the opportunity to break
new ground in hardware turn the world on it's head -- and suddenly your
highly tuned kernel is is only 1% efficient...
-Miles
--
Yo mama's so fat when she gets on an elevator it HAS to go down.
>> 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
On Fri, 6 Dec 2002 00:15:15 -0600, "Joseph D. Wagner"
<[email protected]> 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
jeff millar wrote:
>
> Harnessing energy (rockets, nukes, etc) is fundamentally an unlimited
> engineering opportunity. But kernel development is mostly an attempt to
> reduce overhead to zero. If a kernel runs 90% efficient now, then there's
> only 10% additional improvement possible.
>
It isn't merely reducing overhead. You can, for example,
develop better caching/readahead/swap algorithms and sometimes
get fantastic improvement.
> On the other hand application software is fundamentally unlimited.
>
> So if you want to work on reliability, portability, maintainability, and
> adaptation to new hardware then kernels make a good career. But if you want
> to break new ground, then it's either application space or hardware.
>
You can break new ground with kernels too - whenever you find
new ways to use the hardware. Kernels for massively parallel
machines aren't standardized yet, for example.
And that's the way hardware may have to go for further improvement
when it hits the final size limits.
Helge Hafting
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
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.
--
................................................................
: [email protected] : 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}...............:
[email protected] (Alvaro Lopes) wrote on 06.12.02 in <[email protected]>:
> 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
[email protected] (Alan Cox) wrote on 05.12.02 in <[email protected]>:
> 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
[email protected] (Linus Torvalds) wrote on 05.12.02 in <[email protected]>:
> In article <000901c29c5d$6d194760$2e833841@joe>,
> Joseph D. Wagner <[email protected]> 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
On Saturday 07 December 2002 02:39 pm, Kai Henningsen wrote:
> [email protected] (Alan Cox) wrote on 05.12.02 in
<[email protected]>:
> > 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: [email protected]
Any opinions expressed are solely my own.
Followup to: <[email protected]>
By author: Jesse Pollard <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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