OSNews

Let's not start this argument again. By many definitions, an OS == kernel. By many others, the kernel is only a small part. It just depends on how you want to look at it, so I think it is perfectly fine if someone chooses to call the kernel an OS.

Your humble opinion is wrong. A kernel is an operating system as it operates a piece of hardware and provides an interface. Allbeit, the user of a kernel is not Joe Sixpack, but an application software developer.

WordNet (r) 2.0 [wn]

operating system
n : (computer science) software that controls the execution of computer programs and may provide various services [syn: OS]

Jargon File (4.3.1, 29 Jun 2001) [jargon]

operating system n. [techspeak] (Often abbreviated `OS') The foundation software of a machine; that which schedules tasks, allocates storage, and presents a default interface to the user between applications.

[Jargon definition was abbreviated]


The next issue is that anything Linux builds on, GNU should build on as well: Simply because Linux is built, almost always, with Gcc and so are gnu's utilities. How many GNU utilities are using asm these days?

How do you operate the computer with just a kernel?

The fact is it is a system of many parts, from the kernel for abstracting hardware access to the shell for allowing user-access to the kernel in order to control the hardware.

If you think about it for a moment kernel+shell=a single grain. It's a metaphor that's got lost as the terms became accepted in their own right.

The jargon file is more accurate (unsurprisingly), Linux is not an operating system on its own: it is an operating system kernel that can be used with other user-space utilities to create a full-featured operating system. At present, the only user-space utilities that work with Linux are those supplied by the GNU project, and even the BSDs use GNU tools (notably GCC).

Thus Linux is not an operating system. This also negates Greg's comment about plug'n'play. A lot of users using the standard graphical shell on their machine (Gnome, KDE), cannot plug a device into a system and be certain that it works. Ubuntu, for example, won't mount my USB hard-disk without low-level intervention from me: Windows will. The whole system does not yet work together seemlessly, as the person from Novell indicated.

The problem with your definition is that it is a constantly changing one. Is DOS an OS? How can you operate a computer without a desktop? In another 10 years will the systems of 2005 count as an OS?

When I was in school, we were told an OS was an interface to the hardware and a scheduler, nothing more. App programmers tend to include all the libraries, etc. on top of that, since they are pretty much linked and they use higher level functions that a kernel doesn't directly provide. I see both sides of the argument, it just depends on your perspective.

Nearly every CS program taught in universities around the world teach that Unix Operating Systems, including Linux, are comprised of three parts:

1. the kernel
2. the file system
3. the shell

With its API, the same way the programs built on the kernel operate the kernel.

The Linux kernel, by itself, meets none of these definitions. You don't think so, then do the following: set up a linux distro on a spare partition. get it working nicely. then cd / and remove everything except the kernel. You can even keep grub, if you'd like.

Now reboot. . .

That's not an OS. That's a kernel.

How many GNU utilities are using asm these days?

Well, the C library is, and there are machines for which there are kernel ports and no full ANSI C, which means a lot of stuff won't compile for them.

Let's look at those definitions again:

software that controls the execution of computer programs and may provide various services
In other words, a scheduler. Which is part of the kernel.

The foundation software of a machine; that which schedules tasks, allocates storage, and presents a default interface to the user between applications
In other words, a scheduler, memory manager, file system, and some sort of shell. The kernel satisfies 3 out of 4, but not the last part.

Both have some merit.

then cd / and remove everything except the kernel. You can even keep grub, if you'd like.

Now reboot. . .

That's not an OS. That's a kernel.

That is an OS by some definitions, it just won't do anything because you've deleted all the user applications that run on top of it.

That's not an OS. That's a kernel.

That is an OS by some definitions, it just won't do anything because you've deleted all the user applications that run on top of it.


It's not just user applications. kernel's no good without init...

and a definition of OS that allows "it's a brick" is a very useless definition of OS.

Edited 2006-07-27 03:37

It will boot fine, and stop at init.

And honestly, if you think it doesn't mean the wordnet definition you really need to read up on something:

operating system
n : (computer science) software that controls the execution of computer programs and may provide various services [syn: OS]

The Jargon file definition is honestly a little harder to push, since it's supposed to have a user interface, however since a developer is a type of user and the kernel provides an API, the kernel provides a user interface.

It will boot fine, and stop at init.

It won't find init. It'll then fall over.

Which is why the kernel devs maintain their own drivers.

That said, the article does read a little bit like an advertisement. It's not that it got anything wrong, just that it feels a bit... self-promotional, or something.

Edited 2006-07-26 18:36

> Which is why the kernel devs maintain their own drivers.

Then they might not have the latest and greatest stuff.

3D video drivers - this might not be related to linux kernel

latest WiFi enhancement - MIMO, SuperG, G+ etc

Agreed; Linux needs to look at the what the 'others' are doing, if they want their, tongue 'n cheek 'world domination'; OpenSolaris already has a desktop operating system being based upon it (Nexenta), which has a stable driver API and lots of other goods; on the FreeBSD front there is PC-BSD.

And the myth, 'oh, it'll remain static if we have a stable API' - take another fellow opensource project, FreeBSD, and the fact that, yes, they have broken compatibility on occasions with driver API, but they've always given timely advance notice, the reason behind it, and warn that in the release, compatibility has been broken, and a recompile of drivers will be required.

OpenSolaris, for example, has had MAJOR overhauls in its internal structures to improve the speed of memory read and writes, cleaning up the source code etc. and yet, has maintained driver API compatibility - what it tells me is that the issue with Linux isn't about, 'its impossible to maintain compatibility without losing flexibility' but rather the developers choosing not to maintain compatibility.

Now, if they wish to go down that route, then they're quite entitled to it, but at the same time, however, lets not try to spread misinformation about the real reasons why a stable API isn't provided.

Yet of all the OSes you mentioned with "stable" APIs, Linux, the OS without a "stable" API, still supports the most hardware and architectures out of the box compared to any OS known to man. All of a sudden, the stable_api_nonsense.txt begins to make sense.

"Yet of all the OSes you mentioned with "stable" APIs, Linux, the OS without a "stable" API, still supports the most hardware and architectures out of the box compared to any OS known to man. All of a sudden, the stable_api_nonsense.txt begins to make sense."

Having support for nonsense old hardware really doesn't matter.

example: Windows doesn't support CGA, MDA video cards, is that really a matter?

It is the lastest, greatest hardware that matters.

I think newer hardware is important too, although I'm not as dismissive of the old stuff as you are.

However, you didn't respond to what he said. You praise Solaris, etc. for having a stable API and say that will provide more drivers. Yet, those OSs actually have less support than Linux does. This seems to suggest that having a stable API doesn't matter, and that only by gaining market share will companies be forced to create Linux drivers.

Like USB 2.0, Wireless USB, SATA, etc? Linux supported these things out of the box much sooner than Windows did.

Also, the "latest, greatest" in what area? Linux is usually behind in the area of graphics cards, but in the embedded world, theres lots of cutting-edge hardware that Linux supports and Windows doesn't.

Basically, your complaint comes down to "waahh, Linux doesn't support my X1900+ XT Platinum XXL so I can't play World of Warcraft, waahh".

If one person needs it, it matters.

Having support for nonsense old hardware really doesn't matter.

example: Windows doesn't support CGA, MDA video cards, is that really a matter?

It is the lastest, greatest hardware that matters.

Legacy is what x86 is all about. You can run 8086 software on a Core 2 Duo. Keeping support built-in is what allows old hardware to remain useful. Have you ever tried to dig up a Windows driver for some old piece of hardware? Plenty of sites are willing to take your money for what you should be able to run without installing anything. And if you get it, it'll work with 9x systems.

Linux maintaining all its own drivers and Macs being end-to-end gave Windows something to be jealous of, besides the greater stability, which I think is why they finally got around to including their own drivers for most common things. I think Microsoft's nVidia driver is better than nVidia's, though mostly because I value compatibility.

Somewhere I got away from this being a reply specifically to you, but I think I've made my points. Third party support may not be the best way to get it done, and support for legacy hardware can save a lot of headaches.

His main point is, you can innovate while maintain the API stability, and if some API needs to go, some OSs have taken a more cautious and user/vendor-friendly way by giving advanced notices.

This is a burden, but if Linux chooses to not take that burden, just be frank about it, don't come up with excuse like stable-api prevents innovation.

There're reasons why Linux has more device drivers and supports more architectures, "unstable_api" certainly _isn't_ one of them, would you agree?

And how long has Solaris been opened?
Is that so surprising Solaris has less number of drivers than Linux? Or you think it's because Solaris has a stable API?

Unfortunately cheap shots get mod up.

The argument is that it stiffles evolution. Guaranteeing a stable API sends a message to developers saying, "Our architecture is perfect and does not need to evolve or change even after we realize it's a pile of poultry manure." These aren't excuses, these are facts backed up by practical experience. Linux' USB stack is rumored to be the fastest and most efficient when compared to other operating systems. However, the USB stack was rewritten 3 times before the hackers got things right. If they had guaranteed API stability immediately after the first attempt, the Linux community will be paying for the price of premature design to this day. Thankfully, Linux evolves with apathy and without sympathy for anyone. The kernel developers have also shown that they'll continue to redesign things until they get it right. That's a breathe of fresh air, if you ask me.

And how long has Solaris been opened?
Is that so surprising Solaris has less number of drivers than Linux? Or you think it's because Solaris has a stable API?

And how do you think about FreBSD (with mostly stable API and far less drivers) being even longer in THE game?

btw. My personal opinion is that reason for that is not constant reinvention or time of existance, but license which is favoured by developers.

There is a difference between "supports" and "runs on". You surely meant "runs on" because it is NOT supported on ANY hardware. There is also a large difference between "runs on" and "runs well on with no issues". Again, you must have meant "runs on", because that's all it's ever done for me.

The reason Linux doesn't have stable APIs isn't due to the technical inability, or any true "reason" other than there isn't enough foresight put into the design phase. The reason projects like Solaris/OpenSolaris have stable APIs is somebody spent a LOT of time designing them to be extendable in the future, without changing existing functionality, EVEN IF you totally rip out the innards and rewrite them.

It's the whole OO argument again. The people working on the kernel are obviously the "extreme coding" type folks who just start slamming stuff together and getting it out the door. That's why you have broken network card support for some NICs, that partially works, but at the same time have drivers for just about every NIC out there. Lots of code flying out the door, very little thought in the design itself (which is an ugly, UGLY mess IMO.)

I'd rather have a well designed system that is stable as a rock, but only runs on a limited set of hardware, but runs WELL on that hardware than a mish mash mixup of poopoo and mud slapped together and let cure under the sun.

"It's the whole OO argument again."

Part of the idea of OOP is to separate interface from implementation (encapsulation).

Maybe that's part of the problem. The Linux kernel is written entirely in C (with small bits of assembly). C does not support OOP natively. And while OOP is possible with C, as evidneced by GTK+ and GObject, at the library level, it's rather difficult and messy to do so, as compared to a language that supports it natively.

Is this a soapbox to say the kernel should adopt OOP, or a language that supports OOP natively? No. OOP is largely about abstraction, and with kernel development, or device driver development, abstraction can be a hinderence (need to stay close to the metal).

What I am saying is that perhaps Linus and the kernel devs don't have an OOP mindset, thus don't fully understand/appreciate the power of encapsulation (separate interface from implementation), and thus the kernel driver API probably does not fully seperate interface from implementation, thus the need to break existing API when re-writing stuff for the purpose of optimization, or "evolution". If there were complete separation of interface from implementation, it would be relatively trivial to completely re-write implementation while still providing a stable API.

I don't know. I'm not a kernel dev. Only they can answer the "encapsulation" question. But it seems logical to me that if there were true encapsulation on the API, maintaining a stable API while rewriting, innovating, evolving the implementation would be a complete non-issue.

Yet of all the OSes you mentioned with "stable" APIs, Linux, the OS without a "stable" API, still supports the most hardware and architectures out of the box compared to any OS known to man. All of a sudden, the stable_api_nonsense.txt begins to make sense.

Which is completely irrelevant to what I originally wrote; the original article which I replied to claimed that if they created a stable API it would then create a situation where innovation would be stifled in that they would be more concerned about API stability rather than correcting fundamental flaws in the implementation of the said API in question.

I'll use Solaris, for example, when USB was first implemented, it was implemented in a very adhoc fashion, basically, enough implemented to get basic mouse, keyboard and what-not functioning; but Sun clearly stated that a stable, long term USB DDK was in development; by the time Solaris 10 was released, it had a stable long term USB API which will allow any person to know that if they create a driver for Solaris 10's USB API, it'll work in 3 years time when, for example, Solaris 10.1/11 is release

The Linux issue, in respects to USB implementation could have been avoided had they instead decided to properly design it from day one rather than rushing out an implementation simply to get the 'look, we supported it first!" - better to support something properly the first time, than having to re-invent the wheel 2 more times because of a cock up in the original implementation.

When USB support was implemented; the first things should have been to consider future proofing it, to allow extensability at a later date if the USB standard is either enhanced or significantly changed to suite a new set of requirements. Yes, it would have taken possibly up to 6 months, but then atleast, when implemented, it would be in a position where it could remain stable for a few years rather than being in a constant state of flux.

Your unrealistic approach to real software development is exactly the theoretical bullshit the Linux kernel developers know well to avoid. Do you develop software? If so, has your first attempt at designing any API/infrastructure/libraries ever been perfect?

There is what you read in textbooks, and then there's what actually works in the real world. Linux got its USB stack working first, they refined it with experience and now it's arguably the most efficient. To add insult to injury it has the largest support for USB drivers out of the box of the whole bunch, including Solaris. Now tell me how its unstable API is going to be its demise? What advantage does Solaris stable API gain it over Linux? Today, in practical terms absolutely nothing. Instead Solaris has to maintain legacy code and if at any point they spot design flaws in their APIs, they are stuck with it.

Providing stable APIs is not a holy grail. It doesn't automatically suggest better design, more drivers or even higher quality ones. It just gives developers blind faith and false sense of security.

The stable API is a trap, it just leads to more binary-only modules being available, because right now one of three things happen (when some driver is available):

1) Companies provide some lame one-kernel-only binary-module (few, thank god)
2) Companies provide some blob of binary code with some open-source glue (like nvidia and ati do it now)
3) Open-source drivers are made, either by the community (with or without help/specs), or by the companies.

Which one would you think would increase if there was a stable API? If there was a way to write a driver and use it in all kernel versions instead of one?
Is it the best way to freedom to use the hardware anywhere (OS/kernel/archh) you want?

Edited 2006-07-26 19:31

Entertaingly enough, aside from a few very high profile cases, the big vendors seem to be quite good about driver support on Linux.

The high-profile cases, where vendors are reluctant to provide open-source drivers from Linux, don't even have to do with a stable driver API. They have to do with IP issues (in the case of NVIDIA and ATI), and regulatory issues (in the case of wireless chipsets).

No stable API, then don't expect vendors eager to jump in and supply device drivers

No one expects that. All kernel devs want are open specs.

No one expects that. All kernel devs want are open specs.

I'm a kernel developer and I want stable APIs. One gets tired of having to change a driver every couple of weeks because someone randomly changed the argument list to some interface, and yes, there have been periods in which the interface breakage was pretty random.

I'm a kernel developer and I want stable APIs. One gets tired of having to change a driver every couple of weeks because someone randomly changed the argument list to some interface, and yes, there have been periods in which the interface breakage was pretty random.

All I said is that kernel developers don't expect hardware vendors to supply drivers, just open specs. How you changed the argument to kernel developers wanting a stable API no one knows.

If most kernel developers wanted a stable API then there would be a stable API but obviously that's not the case.

If most kernel developers wanted a stable API then there would be a stable API but obviously that's not the case.

Believe me, Linux kernel development rules aren't set by a majority vote. Nor is it "obvious" that "most" don't want stable APIs.

I'm unaware of any survey of any sort of what "most" kernel developers want.

I'm also not calling for one. Linux is Linus' toy, and he can play with it anyway he wants.

I'm just trying to point out some problems in claims people have made about the consequences of the development model, and, in this case, some errors in assertions Greg made in his keynote.

I'm unaware of any survey of any sort of what "most" kernel developers want.

I'll concede that point but I would say that the kernel developers that provide most of the code do not want a stable API. If they did then they would code it that way.

I'm just trying to point out some problems in claims people have made about the consequences of the development model, and, in this case, some errors in assertions Greg made in his keynote.

I'm just trying to point out the problems with the claims people make about how a stable API will benefit Linux when in fact it will hurt Linux. Allowing binary drivers will not only destroy the whole concept of having a free system, but it will destroy the kernel itself. No longer will it be small, clean, and fast. It will be just like windows, big, messy, and inefficient.

"Agreed. It combines what looks like an Impress presentation with commentary, both witty and informative."

Luckily, unlike Impress, it's not eating all your system rescourses and running at 2 fps.
Just kidding.

Anyway, while I thought this was an interesting read, I fail to see his point about the lack of a need for a stable API. Yes, having one would force developers to keep backwards compatibility, but at least there would be some backwards compatibility, unlike in the existing setup, which forces closed source driver suppliers to provide hacked together open source abstaction layers. As it stands, the kernel requires a recompile for something as simple as installing a driver, so it's essenitally impossible to write a driver and distribute it with a product, if a manufacturer were imclined to do so.

Edited 2006-07-26 18:47

As it stands, the kernel requires a recompile for something as simple as installing a driver, so it's essenitally impossible to write a driver and distribute it with a product, if a manufacturer were imclined to do so.

That isn't true, is it? I thought you could just ship it as a kernel module with your product and have it loaded at runtime. Of course, it might break if the user updates their kernel.

"As it stands, the kernel requires a recompile for something as simple as installing a driver, so it's essenitally impossible to write a driver and distribute it with a product, if a manufacturer were imclined to do so.

That isn't true, is it? I thought you could just ship it as a kernel module with your product and have it loaded at runtime. Of course, it might break if the user updates their kernel."

And that gives linux a bad image/perception

"That isn't true, is it? I thought you could just ship it as a kernel module with your product and have it loaded at runtime. Of course, it might break if the user updates their kernel."

You'd only have to recompile the kernel if a dependency (of the driver) is missing from the kernel image.

"As it stands, the kernel requires a recompile for something as simple as installing a driver, so it's essenitally impossible to write a driver and distribute it with a product, if a manufacturer were imclined to do so.

That isn't true, is it? I thought you could just ship it as a kernel module with your product and have it loaded at runtime. Of course, it might break if the user updates their kernel."

Of course this isn't true, I install the nvidia drivers under Debian all the time (yes, even when I compile just the nvidia source package) and never have to recompile my kernel. It's just a matter of using Module Assistant.

The kernel doesn't have to be compiled for new drivers. New drivers have to be compiled against the current kernel.

In practice, the distinction is irrelevent. Good distros handle driver updates transparently, through their repository.

This point cannot be stressed enough. Don't install software or drivers manually on Linux and then complain when its hard. You're not supposed to do that. That's what the repository is for!

CLI, X11, KDE, and Gnome are not Linux. Let me show you:

Linux
-> CLI
-> X11
->->KDE
->->Gnome

See the parent relationship for the dependency? How it's handled up the tree has nothing to do with Linux...

Device handling in Linux, when the driver is there and working, is "studly." TMK, NT does it just as well, it just doesn't ship with the broad number of drivers.

And your point? Other than being a pointless post, you do nothing to refute my statement, or to boost the article's statement. IOW, it's a pointless post.

Did we read the same article?

In no way did I see that he was limiting the comparison only to what other OSes had "built-in".

His consideration of the Linux kernel encompasses many different archetectures, including embedded devices. Seems like a reasonable claim to me (I think that BSD would be a closest competitor in this arena).

So, what is the fact concerning Linux and devices these days. It's this:

http://www.kroah.com/log/images/ols_2006_keynote_04.jpg

Yes, that's right, we support more things than anyone else. And more than anyone else ever has in the past. Linux has a very long list of things that we have supported before anyone else ever did.

Quote from the image:

Linux supports more devices, "out of the box", than any other operating system ever has.

Sounds like it could be taken your way, but in fact it is just half of what you think it is. (does that make sense, because I re-read it, and it doesn't sound clear to me)

Let me use an example: "I drink more coffee before 8 am each day than my coworkers ever do". Does that mean to compare what they drink before 8? Or all day?

That original statement is a bit ambiguous, but to assume a limiting clause on Windows is putting a few words in his mouth.

His reply was in response to the "myth" that linux has less drivers than windows. It seems pretty clear to me that he's trying to refute this. He did prove that linux has more drivers, but he's talking about built in, whereas most people only care if they're available.

//I think it's pretty safe to say that Windows has more available drivers than linux.//

You might think that ... doesn't mean your thinking bears any realtion to reality.

Are you kidding me? Everything supports windows if it works on a PC. If you exclude other architectures, which has no bearing when you're talking about drivers for pc devices, then by definition windows has more. Do you honestly think the kernel developers instantly create a new driver the minute a new device comes out?

"His rebuttal to the "linux has no drivers" myth is completely illogical. I don't care how many drivers linux has built in, I just care how many are available. I think it's pretty safe to say that Windows has more available drivers than linux."

I will try to remember that the next time I try to install Vista and it dies because it doesn't support my Promise SATA chip. Oddly, Linux supports it in x32 and x64.

Vista isn't even released yet. Not only are you trying to compare a currently released OS to one that isn't even released, you're also trying to use circumstantial evidence to support a general claim!

Please try and provide less stupid arguments next time you decide to respond to me, mmkay?

And that's bad? People need to know. It's not that we are selling them something. Unlike other OS providers...

Kroah-Hartman works at Novell... So yes, he is selling something.