<BLOCKQUOTE><font size="-1">quote:</font><HR>As for what constitutes an OS... well, I think that it's kernel-space stuff only,<HR></BLOCKQUOTE><BR>Well, that's more than just the kernel, isn't it? Like, much of NT is kernel-space, but not kernel.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>but there are other things you could lump in with it and not get too big an argument from me. The UI is not one of those, however. That's largely an attitude shaped by living in the Unix world... in the traditional DOS/Win/Mac single-user desktop PC world, it's one OS, one UI. That's not true in the Unix world, and never has been (well, not never, but not in decades, anyway). The UI on Unix systems is a completely modular thing, that has zero ties to the underlying OS layer, and can even be removed completely without affecting the machine's suitability for certain tasks.<HR></BLOCKQUOTE><BR>But can it? Once you've got a machine set up and running, then there's no need to have a user interface, but in the meantime, how do you interact with the machine? You can't interact with the kernel directly (IME), you need some layer between the user and the kernel. It might be, say, a web server; an interface between the network driver talking raw IP, and a user talking HTTP (often with an enabler, such as a browser). It might be a terminal capability; either a telnetd, or local video and keyboard capabilities. It might be removed once the machine is set up. But I'd argue that three has to be a user interface, of some description, that sits above the kernel -- and it's that what makes up an OS.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>I'm not talking about just the X/command-line separation, either, where you can peel off the entire graphics subsystem and throw it away if you don't have a use for it, or the various different X window managers that all provide completely different UIs. Even at the lowest level, the command line, there are multiple UIs that can be interchanged, exchanged, or removed without affecting the machine's capabilities.<HR></BLOCKQUOTE><BR>They do change the machine's capabilities, though. Remove the shells (which just provide a UI), remove the graphical subsystem (which provides both an API and a UI), remove the servers (web, ftp, whatever) (which again provide an API and/or a UI), and what have you got? A kernel, that can't do a whole lot.<P>The command line isn't the lowest level; the kernel is the lowest level. It needs a layer on top of that (command line, server-type tools, GUI) in order to do anything. It is that layer, whatever form it may take, that is (along with the kernel) an 'OS'.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>I've got a Linux machine here that hosts several user accounts. Most of the users use bash for their login shell, but there's one who (used to) use tcsh. Is she using a different OS when she logs in with tcsh than I am when I log in with bash? I think not...<HR></BLOCKQUOTE><BR>Not a different OS, but a different consituent of the OS.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>If I nuke tcsh now that there's no one using it, have I changed the OS? Again, I think not. I've just removed one of the many programs on the machine that users can use to run other programs. These include not only programs that are normally considered to be shells, but also things like lynx and emacs, both of which I've seen used for login shells...<HR></BLOCKQUOTE><BR>Or Pine, as our school used. But I'd still say that they are -- when used in that way -- OS components. There's flexibility; just as pine can be used as a login shell, you could use Winword in Windows, and that makes them core UI tools; they *become* the user interface.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>Some sort of UI is necessary to make an OS generally useful, but it's not part of the OS. It's a program that allows users to easily communicate with the OS. And that's what all programs do, really... and you can use just about anything as the UI in Unix. Using it that way doesn't instantly make it part of the OS, however.<HR></BLOCKQUOTE><BR>The OS allows communication with the kernel and the user, IMO. Either as a means of starting programs (like a shell, for instance) or as a program in its own right (like using Pine or winword).<P>A user cannot (in any practical sense) communicate with a kernel. Router tasks (for instance) are kernel --> kernel communications, not user --> kernel. The OS is a higher level than that. It might be human readable (HTTP server, CLI, Pine, Winword), it might not (SMB/Samba, DirectX), but it provides another layer.<P>I guess it needn't be a human UI; it can be an API; I guess an interface of some description that's not provided by the kernel, that permits something other than kernel to kernel communication. Typically, this is (in part) a user interface, and typically it's some kind of networking (at a higher level of abstraction than raw network packets or (say) TCP/IP).<P><BR>To be honest, though, I'm knackered, and can barely think. The bastards at work made me go in at 1100 instead of my customary 1300.