Let me try and come at this from a different angle for you. I'm willing to bet you have a router sitting somewhere nearby, or at the least, you know what a router is and what it does.

So, let me ask this: does the router "operate?" Does it do something useful for the end user? Could you plug devices into a router and get a useful benefit without issuing any commands to the router? Unless you have very different routers than me in your household, your answer to all those questions should be "yes."

Now, you may want to say that you need to go through a web interface to customize settings. But don't confuse that with issuing commands to the router. Customizing settings is much more akin to changing a configuration file than issuing commands. I could add more to why the web interface is not issuing commands, but I don't want to get off track.

So, would you feel uncomfortable saying that a router has an "operating system?" There is a chunk of code that tells the router what to do, when to do it, and how to do it. If you are uncomfortable calling it an "operating system," then what would you call it?

The point is, as macemoneta has been saying, that the meaning of "operating system" depends on your perspective. Your perspective is bundled together with the concept of an user-interactive appliance/device. User interaction is not a prerequisite of an operating system. For embedded devices (e.g. routers, traffic lights, battery rechargers, etc.), a kernel is all that is necessary to qualify as an "operating system."

That is the way I always understood it too.

The people at Debian's website seem to describe it that way also:

It's a pointless argument, but I was nevertheless interested to get LQ's take on it. Thanks people.

OK, great answer, but how would one interact with the traffic light in your example, or how would the lights interact with the kernel for that matter?

Surely (and I'm not calling anybody Shirly ) there must be some intervening layer that interprets the lights and sends signals to the kernel to react upon?

Not required at all. Linux (the kernel) is modular and extensible. When used in an embedded application (such as a traffic light), a kernel module can be created which initializes the needed functions on load (scheduling timers, performing I/O to physical pins, etc.). The traffic application would then be part of the kernel, and it would always have an (internal) workload. This type of functionality isn't hard to implement, but most shy away because of the GPL requirement to open source kernel code. By placing the same code in an application, the GPL issue is avoided.

1 members found this post helpful.

More likely that its not EPROM (erasable programable read only memory and its EEPROM (electricaly erasable programable read only memory.) LOL

ps if it was EPROM then you would have to remove the sticker and apply ultra violet light to erase it.

Hi,

Look at;
Simple but a fair definition.

For wiki fans, excerpt from Linux kernel:
Excerpt from Linux ;
Notice the differences in the above three definitions for 'Linux'. Audience! Simple one liner for concept of kernel: 'the core of an operating system - must exist or os goes nowhere'.

So for a CS major to define 'Linux' as being a OS or not then one must first define the operations to be performed and how. Then the problem can be addressed via the kernel and application.

You don't have an EPROM burner? Huh.

Hi,

Cannot find the eraser lamp either! Sun would take too long!

Clearly, Android is ... Android. It uses a modified Linux kernel, but as the OS does not market itself a Linux variant, beyond putting the kernel in the credits they don't have to call it a Linux variant at all.

To add more excerpts to the mess... err... I mean discussion.


I believe the answer is both.

Linux is an OS (or at least a class of related OSs), but it is also the name applied to the kernel commonly used in Linux.

Actually, linux can operate on its own. say we have a shell sh. We put it in initrd and boot the kernel with the argument init=/bin/sh. This way you'll get a working shell with no GNU stuff.

In my opinion, a monolithic kernel is an operating system, while a microkernel is not. You can use the kernel with busybox, or with X11 and not need the GNU stuff at all. In fact most users don't use the GNU stuff directly as much as they used to. Modern utilities have overtaken the original tools in terms of ease of use and features. Today, we don't mount. We let the HAL daemon pass the information to d-bus and mount it via GNOME-VFS.

There is an OS.

Just becasue it doesn't use the GNU userland doesn't mean it couldn't use a different one. In this case, one custom made for Android.

The way I have always thought of it is the kernel is the OS. Applications add functionality for the user.

Just because it isn't attached to anything doesn't mean an engine ceases to be an engine. It may be it is of no use to someone that wants to drive a car, but it is still an engine. Plug in an ignition system, throw it in a frame with some wheels and a steering system (applications) and you have a basic vehicle (distribution).

Add in all the extras and call it the Ubuntu or Slack car, or windows, or Mac.

Your definition is horribly dated and proven to be wrong.
Are you honestly claiming that a monolithic kernel can't add anything in user-pace?

Pure tech, any monolithic kernel can work as a (utterly useless) OS.
In a modern (GNU/)Linux distribution, Linux is indeed the kernel but not the full OS (not even in your definition).

How is this relevant anyway?
The OP is clearly using a gnu-linux system and not some alternative.

A user (meaning a living, breathing person) would not interact with the traffic light aside from observing its state (i.e. red, green, yellow). The lights wouldn't interact with the kernel either--they are passive. So that begs the question: what would interact with the kernel? In the simplest example: a timer.

At my first job, we were working with PowerPC processors. The PowerPC had some interrupt pins. When a signal to any of those pins was activated, the processor would stop what it was doing (as quickly as possible) and "service the interrupt." I imagine virtually every processor out there has at least one such interrupt pin.

So, to tie this back to the traffic light, you have a timer of some sort (crystal oscillation, radio receiving NIST timing signals, a simple counter, whatever). When the timer reaches a certain value, the interrupt pin is activated*. The kernel is responsible for identifying what caused the interrupt and switching control to the appropriate driver to service the interrupt. In this case, identifying what caused the interrupt is easy: the timer--only one component is capable of causing the interrupt. Servicing the interrupt may be as simple as writing values to two locations in memory: (1) to change the state (i.e. which color is currently lit) and (2) to disable/clear the interrupt until the next timer event.

* - Both of these activities (i.e. comparing the timer against a certain value and activating the interrupt) can be implemented directly in hardware--no software necessary.

All of the above creates a traffic light that displays each color for a fixed amount of time. It could be refined to change how long each light is displayed, to change the display time of each color depending on the time of day, to respond to pressure sensors buried beneath the roadway, etc. Where to implement the added capability--in hardware or software--is a design decision, but some things (such as the pressure sensors--an external source of information) must include some some hardware-level changes at a minimum.

So, I think that answers your last two questions at the same time: that the lights don't interact with the kernel, but a timer does, and the interaction doesn't require any intermediate software at all--just straight hardware signals.

Then you must be calling all of us "nobodies!" or you think you're talking to yourself.


Lastly, if I may be so presumptuous, the reason your question has caused so much back and forth is because defining "Linux" as a kernel or an operating system depends on your definition of "kernel" and "operating system." And has been shown in this thread, "operating system" is open to some interpretation. As I stated in my first response, I think you were coming at the question from a background that an operating system must include some element of user interaction. And I think jens falls in that camp more or less.

The purpose of my traffic light example was to illustrate a situation that doesn't have user interaction, but would also fit your concept of a device with an operating system. A diagram of which, in ASCII art, might be represented as:
Where, depending on the role of the device, X > 0 (desktop computer, smartphone) or X = 0 (traffic light). So, again depending on the role of the device, this implies that an operating system can include the kernel and "user space" tools, or an operating system can be limited to the kernel alone (in which case the two terms would be synonymous/reflexive).

1 members found this post helpful.