Fed up with Linus

Fed up with Linus

Post by Christopher Brow » Sat, 31 Oct 1998 04:00:00




>JD writes:
>> I dont think it is right that Linus has the sole right to decide what is
>> best and what is not.

>He doesn't.  You are free to hack up the kernel any way you wish and
>distribute the result.

At present, Linus does have a goodly degree of "sole control" over what
is best, since a very large proportion of people that work on the Linux
kernel have been willing to subordinate themselves to his choices.

Quote:>> Within thirty seconds I am reminded why I use Free BSD.

>Then why are you concerning yourself about Linux?

Fair.

Quote:>> Nothing personal against Linus, but the development process would be more
>> of a democracy.  There would be a large group of developers, where no one
>> person had all the power.

>There is a large group of developers, and no one has any power at all.  We
>use Linus' kernels because we freely choose to do so.  Nothing is stopping
>you from forking your own version.  Just get together a like minded group
>and start voting.

Putting together a sufficiently large "like minded group" to make a
forked version be viable would be rather a challenge.

At some point, it may well make sense to more widely distribute
authority to make "authoritative" kernel changes.  

No one has found that to be so necessary as to mandate "forking" in the
manner that occurred with the BSD efforts (witness FreeBSD, NetBSD, and
OpenBSD...).  It may eventually happen.

--
"Waving away a cloud of smoke, I look up, and am blinded by a bright,
white light. It's God. No, not Richard Stallman, or Linus Torvalds, but
God. In a booming voice, He says: "THIS IS A SIGN. USE LINUX, THE FREE
UNIX SYSTEM FOR THE 386." -- Matt Welsh

 
 
 

Fed up with Linus

Post by H. Peter Anv » Sat, 31 Oct 1998 04:00:00




In newsgroup: comp.os.linux.development.system

Quote:> Putting together a sufficiently large "like minded group" to make a
> forked version be viable would be rather a challenge.

If it was a big issue for a number of people, it wouldn't be such a
challenge.

Quote:> At some point, it may well make sense to more widely distribute
> authority to make "authoritative" kernel changes.  

It has, in many ways, already happened: Linus will take patches from a
number of people at face value, if those patches fall within their
respective delegated area.  For example, I don't think Linus has ever
rejected a patch I have sent to him for the autofs filesystem, because
I "own" it.  We do, however, have plenty discussion about the VFS.

        -hpa

--
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah' -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misrables

 
 
 

Fed up with Linus

Post by Josef Moeller » Sat, 31 Oct 1998 04:00:00


[ ... ]

Quote:> Putting together a sufficiently large "like minded group" to make a
> forked version be viable would be rather a challenge.

It would not only be "a challenge", it would, IMHO, be rather unwise!
The last thing we need is yet another (incompatible) version of UN*X.

When discussing UN*X and UN*X-like OSes (Linux, FreeBSD), I have found
that this is the biggest complaint of most poeple: They say "UNIX" and
expect a single, coherent OS just like the M$ stuff: a program that runs
on one instance of W'98 will also run on every other instance of W'98. A
program written for one instance of UNIX (e.g. Linux) will not run on
another instance of UNIX (e.g. FreeBSD, agreed there is a Linux
emulation package, but that's not the point). Imagine what would happen
if LINUX != LINUX. Already RedHat looks and feels slightly different
than SuSE which looks and feels slightly different than OpenLinux.

Quote:> At some point, it may well make sense to more widely distribute
> authority to make "authoritative" kernel changes.



Quote:

> No one has found that to be so necessary as to mandate "forking" in the
> manner that occurred with the BSD efforts (witness FreeBSD, NetBSD, and
> OpenBSD...).  It may eventually happen.

Please, don't!

--

        UNIX - Live free or die!
PS Dieser Artikel enthaelt einzig und allein meine persoenlichen
Ansichten!
PS This article contains my own, personal opinion only!

 
 
 

Fed up with Linus

Post by M Sweg » Sat, 31 Oct 1998 04:00:00



: It has, in many ways, already happened: Linus will take patches from a
: number of people at face value, if those patches fall within their
: respective delegated area.  For example, I don't think Linus has ever
: rejected a patch I have sent to him for the autofs filesystem, because
: I "own" it.  We do, however, have plenty discussion about the VFS.

:       -hpa

Will the new VFS system have the functionality as Volume Manager
under the Solaris 2.5.x and now Solaris 7.x (64 bit) OS?

--
        Mike,

 
 
 

Fed up with Linus

Post by M Sweg » Sat, 31 Oct 1998 04:00:00


: The last thing we need is yet another (incompatible) version of UN*X.

: When discussing UN*X and UN*X-like OSes (Linux, FreeBSD), I have found
: that this is the biggest complaint of most poeple: They say "UNIX" and
: expect a single, coherent OS just like the M$ stuff: a program that runs
: on one instance of W'98 will also run on every other instance of W'98. A
: program written for one instance of UNIX (e.g. Linux) will not run on
: another instance of UNIX (e.g. FreeBSD, agreed there is a Linux
: emulation package, but that's not the point). Imagine what would happen
: if LINUX != LINUX. Already RedHat looks and feels slightly different
: than SuSE which looks and feels slightly different than OpenLinux.

That's not the only thing. We also need one coherent set of utilities
that all the Unixes need. There are so many packages that provide
the same set of utilities such as df/du/ls/pg/more etc with the
associated man pages that I don't know what I have in terms of
the latest and greatest. It's a configuration management nightmare.
I can understand the need for multiple versions of a utility or
app written by different people, but then take the best of all and
make one unified one that can serve as the baseline for distribution
to the masses.

As for the different flavors of Unix, I see a need whereby all
kernel functionality is written as modules: similar to the hardware
driver modules used by the insmod, lsmod utilities. Thus, one is
then able to create a particular flavor of Linux or BSD by mixing
and matching the best features of each one by loading via insmod
the *core* kernel functionality on a module by module basis. What
I mean here is that the scheduler would be loaded as a module.
This would allow me to use the best scheduler of all the Unixes,
to load an expermental one (a newer version), or from an academic
standpoint a research one. This can also be done for SMP thread
support (whether one wants threads or not), and to load other
areas of the kernel on the fly that I'm not familar with. This
would mean we can tailor the OS kernel to a specific application
such as realtime or non-realtime, instrumentation and scientific
measurement, user accounts etc etc on the fly and thus become
pretty close to an adaptive and dynamic OS!! Perhaps one can
then apply the Corba concept for Unix whereby the OS is objects
consisting of modules riding on a minimal Corba model. I realize
that SUN had the Spring project back in the the early 90's.

Just my .02 cents.

--
        Mike,

 
 
 

Fed up with Linus

Post by Alexander Vi » Sat, 31 Oct 1998 04:00:00




>[ ... ]

>> Putting together a sufficiently large "like minded group" to make a
>> forked version be viable would be rather a challenge.

>It would not only be "a challenge", it would, IMHO, be rather unwise!
>The last thing we need is yet another (incompatible) version of UN*X.
>When discussing UN*X and UN*X-like OSes (Linux, FreeBSD), I have found
>that this is the biggest complaint of most poeple: They say "UNIX" and
>expect a single, coherent OS just like the M$ stuff: a program that runs

                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        Duh. Many ridiculous things I've heard here, but that...

--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

 
 
 

Fed up with Linus

Post by Josef Moeller » Sat, 31 Oct 1998 04:00:00


[ ... ]

Quote:> That's not the only thing. We also need one coherent set of utilities
> that all the Unixes need. There are so many packages that provide
> the same set of utilities such as df/du/ls/pg/more etc with the
> associated man pages that I don't know what I have in terms of
> the latest and greatest. It's a configuration management nightmare.
> I can understand the need for multiple versions of a utility or
> app written by different people, but then take the best of all and
> make one unified one that can serve as the baseline for distribution
> to the masses.

Well said.

Quote:> As for the different flavors of Unix, I see a need whereby all
> kernel functionality is written as modules: similar to the hardware
> driver modules used by the insmod, lsmod utilities. Thus, one is
> then able to create a particular flavor of Linux or BSD by mixing
> and matching the best features of each one by loading via insmod
> the *core* kernel functionality on a module by module basis. What
> I mean here is that the scheduler would be loaded as a module.
> This would allow me to use the best scheduler of all the Unixes,
> to load an expermental one (a newer version), or from an academic
> standpoint a research one. This can also be done for SMP thread
> support (whether one wants threads or not), and to load other
> areas of the kernel on the fly that I'm not familar with. This
> would mean we can tailor the OS kernel to a specific application
> such as realtime or non-realtime, instrumentation and scientific
> measurement, user accounts etc etc on the fly and thus become
> pretty close to an adaptive and dynamic OS!! Perhaps one can
> then apply the Corba concept for Unix whereby the OS is objects
> consisting of modules riding on a minimal Corba model. I realize
> that SUN had the Spring project back in the the early 90's.

No, please not!
I agree with this wrt certain deeply buried kernel modules (see next
paragraph), but the system call interface and the utilities should be
coherent.
Already porting software from a SYSV-compatible system to BSD, LINUX, or
Solaris is difficult. It would be next to impossible to write any
software for a system where the ioctl-systemcall is Linux-like and the
stat-systemcall is BSD-like or vice-versa or perhaps both or nothing.

Having certain kernel modules interchangeable would be a gread idea
indeed. Imagine a system which could be tailored towards the very
specific use of the machine: interactive systems would use one scheduler
and batch systems another while networked systems use yet another.
Just tuning won't cut it.
OTOH the various schedulers (just to stay with this example) need
different sets of information. So switching from one scheduler to
another would require to load different versions of other kernel
components just to make the necessary information available to the
current scheduler.

Trying to stay on-topic: We already have several (rivalling?)
UN*X-factions and LINUX seems to be one of the stronger ones (imagine
this from a die-hard BSD fan). Let's not make things worse by striving
to let every single user have his individual flavor.

Quote:> Just my .02 cents.

... and my 2 Pfennigs.

--

        UNIX - Live free or die!
PS Dieser Artikel enthaelt einzig und allein meine persoenlichen
Ansichten!
PS This article contains my own, personal opinion only!

 
 
 

Fed up with Linus

Post by Josef Moeller » Sat, 31 Oct 1998 04:00:00



> IMHO, the minor differences (and I mean _minor_) between various
> flavours of Unix is one of its strengths. It means that innovation is
> occurring and (as everybody can see) we get a better product in the end.

But we must be careful not to change too much. Innovation is good and a
moving target is difficult to aim at, but what good is an OS where you
can't run last year's software on. In my company, a lot of money is
spent on ensuring _binary_ compatibility between various versions and
releases of an OS that

- runs on single and multiple CPUs
- has 32 and 64 bit variants
- gets new features added every other day.

If I buy a word processor and shell out $100, I don't want to go and buy
a new one next year, just because the OS has drastically changed
underneath. There have to be VERY GOOD reasons for that.

UN*X does have the strength in that the OS kernel is quite nicely
separated from user land and a number of features are introduced so that
user lever programs, even thos that come with the OS, are pretty much
independent of the OS internals. I can still remember when ls had to
read() directory contents and ps had to seek() and read() in /dev/kmem.

But look at /proc: There are different versions in SVR4, Linux and
(Free)BSD. When I recently saw Linux' /proc for the first time, I was
impressed! When I write a program to use /proc/cpus, will it run on
FreeBSD? No! Will it run on next year's Linux? Who knows?

What you call "minor differences" look enormous when you have to write
software for these systems and maintain it over a long period of time:
First there are n versions for the basic OS flavors (Linux, FreeBSD,
OpenBSD, NetBSD, Solaris, AIX, UnixWare, ...). Next year there'll be two
different versions needed for the XYZ OS, because they have decided to
use the very new networking code and my software wants to communicate
over the net. I'll drown in maintenance in a few years' time.

[ W'98 is binary compatible to W'98 ]

Quote:> This is a lie. Not yours, Microsoft's. They encourage the opinion that
> Windows is a single system (and their inability to differentiate between
> a GUI and an OS helps this). Ignoring the issue of compatibility
> between 9x and NT, there's also the DLL issue. Installation of
> Microsoft patches, software and (I have heard) non-Microsoft software
> replaces various DLLs, sometimes with back-level and incompatible
> sets.

I agree that it is a problem, in theory and everyone of us has had
various versions of the same DLL being incompatible. However, I think
that in practice, this is much less of a problem.

[ ... ]

Quote:> >A
> >program written for one instance of UNIX (e.g. Linux) will not run on
> >another instance of UNIX (e.g. FreeBSD, agreed there is a Linux
> >emulation package, but that's not the point).

> Unix programs run on the widest variety of unrelated hardware and
> kernels known to Mankind.

You're right here. But who owns a Cray X-MP?
When we discuss Linux, we usually talk about PC hardware.

Quote:> You're talking about binary compatibility which is a very restricted
> notion of portability. Unix in general has source compatibility -
> for example gcc is a non-trivial program which compiles and runs on
> a wide variety of hardware and kernels.

Uh, please don't start this ... I hope Scott Nudds doesn't hear this
B-{)

Quote:> Most people don't need binary portability - most people don't own
> several machines of differing architecture. What they need (if
> they're not into compiling the code themselves) is a binary of
> the program for their system. Creating that binary is really the
> developer's job. And it's not all that difficult. For example
> gimp or netscape have binaries for several Unix systems online.
> Just choose the one which matches your OS.

I strongly disagree!
Although it is a strength of software when it compiles and runs on the
most diverse systems (a lot of bugs are found when porting SW from a
little-endian machine to a big-endian machine or from one with 32 bit
integers to one with 64 bit integers), maintaining such a beast is
difficult. Validating the software and getting it distributed is next to
impossible.
Take x programs and y hardware platforms (and z operating system
versions). That makes x*y*z combinations. Add another OS version and
you'll have to do x*y validations.

"Most people" want binary portability because they want to go into a
shop and pick up the latest version of their favorite game or text
processor and they want to run it on the hardware they have, which is
usually a PC. The shopkeeper, on the other hand, doesn't want to stock
ump* different versions of the latest game, text processor whatnot,
especially if (s)he can get away with one version only. A good example
for this is the fate of BetaMax: When I wanted to have a BetaMax version
of a video, the shopkeeper told me that "Fortunately I don't stock
BetaMax any more". I can't even get blank tapes! Yet everyone agrees
that BetaMax _is_ the better system.

You can also see this from the fact that M$ has dropped almost every
non-Intel-based hardware platform for WinNT and from the fact that M$
draws up PC-standards that will "guarantee" to run future versions of
their software.

Quote:> Agreed that it is undesirable for "alternate" versions of a system
> to break binary compatibility. I think that given a strong base
> the laws of evolution are going to work to limit incompatibility
> unless the "alternate" system has strong survival factors (you
> can see this in the wider scope of Windows vs Unix also).

But in the marketplace, this adds to the confusion of the end-users.
Some, if not most, will think that a hard rock is better to sit on than
a drifting armchair. And a multi-million dollar marketing campaign will
do the rest.

Please, don't get the impression that I am
a) favoring M$ product which I absolutely don't
b) opposing multiple UN*X-like OSes.
I just see that UN*X-like OSes suffer from incompatibilities between
them and adding yet another incompatible branch which needs manpower to
support will weaken its position.

--

        UNIX - Live free or die!
PS Dieser Artikel enthaelt einzig und allein meine persoenlichen
Ansichten!
PS This article contains my own, personal opinion only!

 
 
 

Fed up with Linus

Post by hel.. » Sat, 31 Oct 1998 04:00:00



Quote:> When discussing UN*X and UN*X-like OSes (Linux, FreeBSD), I have found
> that this is the biggest complaint of most poeple: They say "UNIX" and
> expect a single, coherent OS just like the M$ stuff: a program that runs
> on one instance of W'98 will also run on every other instance of W'98.

If you really believe this you are saddly mistaken. There are a
million and half factors that may prevent one Win9x program from
running on different systems. . .

** Martin

 
 
 

Fed up with Linus

Post by John Burto » Sat, 31 Oct 1998 04:00:00




> >JD writes:
> >> I don?t think it is right that Linus has the sole right to decide what is
> >> best and what is not.

> >He doesn't.  You are free to hack up the kernel any way you wish and
> >distribute the result.

> At present, Linus does have a goodly degree of "sole control" over what
> is best, since a very large proportion of people that work on the Linux
> kernel have been willing to subordinate themselves to his choices.

Linus has alot of influence over the Linux O/S, after all he *did*
develop it (at least the kernel). The primary thing Linus controls is
the base kernel. If you want changes made to that, well, you'll have to
send them to Linus for evaluation. If you want to spin-off your own
version, go for it...

Quote:> >> Nothing personal against Linus, but the development process would be more
> >> of a democracy.  There would be a large group of developers, where no one
> >> person had all the power.

No one person *has* all the power. There are several Gurus who wield
considerable influence in various areas (compilers, system libraries,
kernel, drivers, etc). In software development, there are several models
to go by. One that has shown the best results is the Lead/Chief
Programmer model. For each development project you have a "gifted"
programmer that does the design, planning, a significant chunk of the
coding, and coordinates the efforts of  others. With Linux, you have a
network of gifted programmers working together, each leading efforts in
their own area(s) of expertise.

True democracy doesn't really work in software development.

Quote:

> >There is a large group of developers, and no one has any power at all.  We
> >use Linus' kernels because we freely choose to do so.  Nothing is stopping
> >you from forking your own version.  Just get together a like minded group
> >and start voting.

> Putting together a sufficiently large "like minded group" to make a
> forked version be viable would be rather a challenge.

So, start the coding yourself. If you're good, and people like what you
do, you'll attract a crowd. If no one is interested, you might
reconsider...

Quote:

> At some point, it may well make sense to more widely distribute
> authority to make "authoritative" kernel changes.

Why?

John

 
 
 

Fed up with Linus

Post by Larry Blanchar » Sat, 31 Oct 1998 04:00:00



> That's not the only thing. We also need one coherent set of utilities
> that all the Unixes need. There are so many packages that provide
> the same set of utilities such as df/du/ls/pg/more etc with the
> associated man pages that I don't know what I have in terms of
> the latest and greatest. It's a configuration management nightmare.
> I can understand the need for multiple versions of a utility or
> app written by different people, but then take the best of all and
> make one unified one that can serve as the baseline for distribution
> to the masses.

But who decides what is "best"?  You still need some sort of governing
body, whether this be a person or a committee.  Other than that quibble,
I agree.

Quote:> As for the different flavors of Unix, I see a need whereby all
> kernel functionality is written as modules: similar to the hardware
> driver modules used by the insmod, lsmod utilities. Thus, one is
> then able to create a particular flavor of Linux or BSD by mixing
> and matching the best features of each one by loading via insmod
> the *core* kernel functionality on a module by module basis. What

I like this idea, but care needs to be exersized to ensure that the
basic set of system calls remains unchanged.  There should be an added
call that allows a program to ask "is the module I need present?".  Or
does that one already exist?
--
Larry Blanchard - Old roses, old motorcycles, and old trains
Homo Sapiens is a goal, not a description.
 
 
 

Fed up with Linus

Post by Pete Zaitc » Sat, 31 Oct 1998 04:00:00



>Will the new VFS system have the functionality as Volume Manager
>under the Solaris 2.5.x and now Solaris 7.x (64 bit) OS?

Mike, please separate flyes from buns, e.g. VFS from Volume Manager
(which is a userland program) and from Veritas (which is an add-on
to kernel, BTW, how about talking Veritas into a rease for Linux?).

And thank you for letting us know that Solaris 7 achieved what Linux
(and OSF/1) had on Alpha a long time ago. I am sure you are aware
that Ultralinux was the second 64-bit system on SPARC. The first was
HAL's SunOS-64. Solaris formerly known as 2.7 is the third. Sun
hardly demonstrate innovation leadership (and this does not affect
the company's success, just like that of Microsoft :).

--Pete

 
 
 

Fed up with Linus

Post by Paul Schmi » Sat, 31 Oct 1998 04:00:00





>[ ... ]

>> Putting together a sufficiently large "like minded group" to make a
>> forked version be viable would be rather a challenge.

>It would not only be "a challenge", it would, IMHO, be rather unwise!
>The last thing we need is yet another (incompatible) version of UN*X.

>When discussing UN*X and UN*X-like OSes (Linux, FreeBSD), I have found
>that this is the biggest complaint of most poeple: They say "UNIX" and
>expect a single, coherent OS just like the M$ stuff: a program that runs
>on one instance of W'98 will also run on every other instance of W'98. A
>program written for one instance of UNIX (e.g. Linux) will not run on
>another instance of UNIX (e.g. FreeBSD, agreed there is a Linux
>emulation package, but that's not the point). Imagine what would happen
>if LINUX != LINUX. Already RedHat looks and feels slightly different
>than SuSE which looks and feels slightly different than OpenLinux.

Linux consists of much more then the kernel, there are specific sets of
utilities and programs that get added on to the kernel to make a
distribution and this is where the different look and feel aspects come
in.  However each component needs to have some one in charge, in order to
keep us from getting chaos.  Linus wrote the original kernel, so he paid
for the right to continue directing it's development.  Those who disagree,
are free to write their own kernel, and build an OS around their new
kernel, but they can't call it Linux.

Quote:>> At some point, it may well make sense to more widely distribute
>> authority to make "authoritative" kernel changes.

I think you will find, that most kernels have someone in charge of
development, there has to be someone with the final word, even in a big
organizations like Microsoft, Sun and HP someone has the final word on
what does and does not go into a kernel.

--
Paul Schmidt
Your Computer is our Business

web  : www.interlog.com/~pschmidt

 
 
 

Fed up with Linus

Post by matthew gauthie » Sat, 31 Oct 1998 04:00:00



Quote:> This is a lie. Not yours, Microsoft's. They encourage the opinion that
> Windows is a single system (and their inability to differentiate between
> a GUI and an OS helps this). Ignoring the issue of compatibility
> between 9x and NT, there's also the DLL issue. Installation of
> Microsoft patches, software and (I have heard) non-Microsoft software
> replaces various DLLs, sometimes with back-level and incompatible
> sets.

[...]

Quote:> Most people don't need binary portability - most people don't own
> several machines of differing architecture. What they need (if
> they're not into compiling the code themselves) is a binary of
> the program for their system. Creating that binary is really the
> developer's job. And it's not all that difficult. For example
> gimp or netscape have binaries for several Unix systems online.
> Just choose the one which matches your OS.

I, for one, feel very uncomfortable pointing fingers at MS's dll
problems while the state of the Linux libraries is so much worse.

Most people don't NEED binary portability. But, almost everyone I
know WANTS it. Almost every new Linux user I've ever met, and everyone
I know that's considered using it look at the fact that you have to
build anything you install yourself as a major setback.

In fact, gimp and netscape, as well as the now-infamous jdk port,
have to have several versions of binaries for several Linux systems
on line. Among others, there is usually a staticly linked version, a
libc5 version, a glibc version, static and dynamic motif versions,
tarballs, rpms, etc. (Yes, the last two are packaging formats, but that's
also a problem.)

To make things even worse, 99% of the time, the correct binary still
won't run on your machine because the developer used a different
version of libc. So, most of the time, the behavior exhibited by a
binary from the developer is a seg fault on starting. Contrast this to
windows, where  most programs work out of the box.

IMHO, the "box issue" is the most important issue concerning Linux
today. Until the pace of releases slows down to make targeting a
specific distribution (such as: this is the binary release for RedHat 5.1)
to make sense, noone in their right mind would consider commercial
or closed-source software for Linux (although, I do applaud the brave
souls currently selling it.)

As a potential solution, which I predict many people will hate, I
suggest pairing the libraries with the kernel. That is, for every
stable kernel version, there should be a corresponding stable minor
version of the libary. This would make statements such as, "requires
Linux 2.0" meaningful. It would also avoid the current problem where
distributions change library versions faster than underwear.

On a tanget flame, I'd like to state once, for the record, that
altering the patchlevel of a shared library should not cause programs
linked against the same minor version to mysteriously cease to work.
While this is sometimes the program's own fault, a large portion of
it comes from the libc developers, too. After all of this time,
can't we have a stable libc yet?

Just my $.04,
-Matt

 
 
 

Fed up with Linus

Post by Renzo Zanell » Sat, 31 Oct 1998 04:00:00





> > >JD writes:
> > >> I don?t think it is right that Linus has the sole right to decide what is
> > >> best and what is not.

> > >He doesn't.  You are free to hack up the kernel any way you wish and
> > >distribute the result.

> > At present, Linus does have a goodly degree of "sole control" over what
> > is best, since a very large proportion of people that work on the Linux
> > kernel have been willing to subordinate themselves to his choices.

> Linus has alot of influence over the Linux O/S, after all he *did*
> develop it (at least the kernel). The primary thing Linus controls is
> the base kernel. If you want changes made to that, well, you'll have to
> send them to Linus for evaluation. If you want to spin-off your own
> version, go for it...

If you ask me, I don't have a problem with Linus having control of the Linux
kernel.  If I were a religious person I would worship him for the great product
that is Linux.  I think Linus had a vision and I believe that Linux is still (7
years later) a revolutionary and evolutionary product.  I think most people
involved with Linux have a great respect for Linus and accept his leadership as
far as Linux goes.  Personally, I kind of dread what will happen if Linus should
die tomorrow .. them's mighty big shoes to fill!  :)

- Show quoted text -

Quote:

> > >> Nothing personal against Linus, but the development process would be more
> > >> of a democracy.  There would be a large group of developers, where no one
> > >> person had all the power.

> No one person *has* all the power. There are several Gurus who wield
> considerable influence in various areas (compilers, system libraries,
> kernel, drivers, etc). In software development, there are several models
> to go by. One that has shown the best results is the Lead/Chief
> Programmer model. For each development project you have a "gifted"
> programmer that does the design, planning, a significant chunk of the
> coding, and coordinates the efforts of  others. With Linux, you have a
> network of gifted programmers working together, each leading efforts in
> their own area(s) of expertise.

> True democracy doesn't really work in software development.

> > >There is a large group of developers, and no one has any power at all.  We
> > >use Linus' kernels because we freely choose to do so.  Nothing is stopping
> > >you from forking your own version.  Just get together a like minded group
> > >and start voting.

> > Putting together a sufficiently large "like minded group" to make a
> > forked version be viable would be rather a challenge.

> So, start the coding yourself. If you're good, and people like what you
> do, you'll attract a crowd. If no one is interested, you might
> reconsider...

> > At some point, it may well make sense to more widely distribute
> > authority to make "authoritative" kernel changes.

> Why?

> John

--
Renzo Zanelli     Systems Programmer
Time Warner Communications - Roadrunner division


http://www.tampabay.rr.com

** Remove the underscores for valid e-mail address **

 
 
 

1. Fed up with Linus

Am I the only one fed up with Linus Torvalds? Yes, the man deserves a lot of
credit for his EARLY work with Linux, but I do not believe he works any
harder than any of the other couple hundred thousand or so developers
working on the project. The fact that he is treated like a God and it makes
me sick. Everyone makes it sound like he personally wrote every bit of code
for every program there is.

I am sitting down enjoying the latest edition of LWN when I flip to the
kernel section. Within thirty seconds I am reminded why I use Free BSD. And
I quote:

At that point, it has to go (again) to Linus, who will then decide whether
it goes out as is or whether changes need to be made.

I dont think it is right that Linus has the sole right to decide what is
best and what is not. It should be left up to the group developing the
kernel. Yes, Linus should have his vote, but his vote should not count more
than the next developer that spent long hours writing code for the kernel.
Think about it, if Linus died tomorrow, the OS would live on, and in my
opinion be a lot better off. Nothing personal against Linus, but the
development process would be more of a democracy. There would be a large
group of developers, where no one person had all the power.

2. Have you installed Linux on an IBM 300GL ?

3. Shape Ups,Men's Shape Ups,Men's Skechers Shape Ups - new styles!

4. curious file ?

5. Tell Linus/Contact Linus

6. Best way to use ufsdump?

7. diff -rcN ups-2.45.2/Makefile ups/Makefile

8. Anyone use a HardCard XL II hardrive w/ Linux?

9. APC USB ups, Back-UPS ES series, 2.5.68

10. UPS - software driver for the APC Smart UPS - 600 (Please HELP )

11. UPS Woes (APC Back-UPS Pro)

12. APC Back-UPS 400, updated howto for UPS?

13. APC UPS Smart-Ups 1000XL & SCO