I want to understand the OS hierarchy:
Please clarify.

A Kernel is the software that speaks in hardware language and a shell is made mostly of software commands?

I know my current shell is bash. I was confused reading about the nature of userspace/userland. What is an example of a program you would need outside of a shell at that program level? (*when trying to run a GUI based OS)

I think i'm looking for a pyramid chart that shows EVERYTHING at each step of building an OS. Wikipedia has a vague chart but not a specific one. Right now it seems like a browser (or app) is to an OS, what an OS is to a shell.

Do you run things outside of a shell? *besides other shells*

My practical use for an ideal shell instance would be a singular ?userland? where you would have no need of other shell instances because the applications themselves are the things you want to manage while the shell is relatively unchanged.

Please do not post reprimands for me asking questions. If you do not have an answer do not reply. "There is no need to work in shell since it is already optimally configured." is an example of a useless reply. I am trying to learn for fun and theory.

thanks
-Jonathan

Hrm, if I understand your question correctly...

You've got the kernel on the bottom interfacing with the hardware, and then bash as "runlevel 3", the most basic user interaction. daemons are tasks that are run independent of a user. *whether daemons are independent from bash I know not*. Then X is built on top of runlevel 3. X runs the window manager and *optional* the desktop environment.

Sorry if I didn't answer your question. (If I screwed something up in my explanation, feel free to correct me... always want to be learning!)

Well, the way I understand it. The Kernel runs below everything. It communicates with hardware. It runs in kernelspace. Everything else runs in userspace or userland (I like "userland" better). The shell is pretty much just a program. The only thing special about a shell is that its purpose is to execute other programs. You can have more than one shell running at a time, side by side, say on different terminals, or on top of one another. Say I like sh better than bash, but bash is already running, I can type sh to run sh on top of bash. Though that isn't very efficient, it would be better to type "exec sh" which would drop out of bash and into sh.
A shell isn't even necessary for an operating system to exist. You can run a single application on top of a kernel and it would be an operating system. Its unusual, but certainly possible.

I believe the normal hierarchy is hardware->kernel->shell->gui->applications

That is simplified however. There is a lot more to it, but that should give you a basic idea.

Some fairly good answers there.
I'd just add that on a server, you typically don't have a GUI, so you get hardware->kernel->shell->applications (after Prushik).
Note that, as also mentioned above, a (compiled binary) app/service can run directly on top of the kernel; it doesn't actually need a shell as such.
Most systems, even embedded, usually have at least a basic shell so humans can communicate/ctrl it.
Of course, the app might have a built in interface to talk to humans, so again, a shell isn't reqd.

The shell is just a program that reads and parse commands. It draws a prompt and then reads whatever you write and acts accordingly. Commands can be many things, and each shell has different rules for resolving them. Some of the commands will be shell builtins, but most of them will resolve to external binary files, which are not part of the shell.

The shell is to the command line like the window manager or desktop is to X. In the same fashion, the window manager is the "shell" of a desktop: it let's you interact with your computer, and provides a way to launch and control applications. Not all shells have to be bash/sh-like, for example, it's perfectly possible to use midnight commander as a shell.

You may find this page useful: http://linux.about.com/od/commands/l/blcmdl_2a.htm
It lists the system calls that are performed by the kernel. In a userland program, you might call these system calls directly or indirectly. The C compiler may translate a similar call to a system call. Some system functions may look familiar. Remember that the C language was written to rewrite the kernel in. Now this is as far as a userland program goes. It's the kernel that actually carries out that operation.

The userland environment and kernel environments are different as well. The kernel is more constrained in how much memory it can use. Also, if you run a C program, the glibc environment is present. A process running in kernel land uses it's own stripped down version of the C library.

A userland program may utilize system calls. But it is the kernel the performs the system calls on your behalf.
Look at the "time" program. It will run the command after it and tell you how much time was spent in userland and how much was spent in kernel land.

example:
time man 1 time

real 0m6.406s
user 0m0.048s
sys 0m0.032s

The .048 seconds is how much time was spent executing in userland. The .032 seconds was how much was spent in kernel land. Reading a man page for a few seconds, a lot more time was spent simply waiting (sleeping). The user + system + sleeping times make up the real time.

Great replies thanks. I learned a lot

so kernel>shell (which could be as simple as 1 command line like dos; or as big as I want)> X> window manager (which is the gui?)> apps. Daemons run independent of these.

Does that sound right? Are there any other steps like x that I originally left out because I didn't know about them?

Well, the thing can be very different depending on your setup.

The kernel is always the first thing to load. It queries your hardware, sets up the drivers and finally calls init. init is always the first process that the kernel spawns on every Linux system and has the PID number 1. You might want to check the init man page for more info on that.

After that, more than probably, init will spawn one or more bash instances. The init system uses the shell for many things. *What* shell? it will depend on the distro. Famouse choices are bash and busybox, but it can virtually be anything that provides some scripting capabilities (and it doesn't need to be necessarily a shell language, it's just the trend).

Init might get you to a final login shell, or it might launch xdm and start X for you.

Inside X you will most likely be running a window manager of any kind, might it be standalone or inside a desktop environment. But it's also possible to run X applications inside X without a WM. However it's not usual, because that way you can't even control the size and position of the applications unless they have been designed to be used that way, and you can't control the stacking or layering either, which is quite painful for a regular desktop usage.

You can as well run shells inside X, for example in a terminal emulator. So, as you can see, it's not something linear, the chain can have very different forms.

In which regards daemons, they are programs like any other, they just run permanently in the background, without needing to be attached to a console or a display of any kind. Most daemons are launched at init time, and stay running until you shut off the pc, but there are also daemons that are launched at later times (typical case for jackd or moc, for example).

X programs can also live daemonized in the system tray of your desktop, waiting for events or whatever.