Terminal and all that other shit, I follow you. Command lines. Fine. I don’t know what the Linux terms mean, but I understand command lines etc… But GNOME… what the fuck is it? Is it a suite? an environment? Every Linux user explains things like I’ve already been a user for a few years and all of them have forgotten what being NEW actually is.
Ironically, the WORST place to find Linux environments explained simply and clearly from the bottom up: The Internet.
This is where I remind and beg: Like. I’m. FIVE.
In: 81
OK, the fact that you’re used to using the command line / terminal is actually going to be quite helpful here!
My explanation will maybe be a bit longer-winded than others, but you did say “from the bottom up” so here goes. Also of note, I’m going to gloss over and oversimplify some things for the sake of getting the spirit right. Folks who know more detail, don’t come at me, ok? Splitting hairs usually leads to less understanding.
Way back in the early, early days of computers, earlier than, and leading through, the punch-card era, the program being run off the punch cards or storage media *was* often the one and only program run on the computer. There wasn’t an operating system, per se, the computer would just sit idle until an operator loaded the stack of cards and hit the go button, at which point the computer would just churn through that one program until it completed, either with a success or an error. You would submit a program to be run to this operator and they would (often overnight) feed various programs from you and your peers through the computer, then you’d pick up the results in the morning.
Along the way, someone had the idea to automate this running of programs. Instead of a person feeding in the one and only program at a time, what if you had a separate supervisor program… and this program was responsible for running *other* programs, which would then return to the supervising program when they were done.
This is the first, basic role of the **operating system**: it’s a program that runs other programs. Notably, one of its main roles is to handle scheduling: so what program runs for how long and when. So a *scheduler* is one of the fundamental parts of the operating system. It’s integral to the core of the OS, which is called the *kernel*.
Over time the operating system was expanded to handle more jobs that just seem very fundamentally tied into how to allocate hardware resources: by abstracting the idea that programs running within this supervisor might want to read and write data, for instance, we get a “filesystem” where the program asks the OS to create a file in a virtual location / folder; the OS will know how to interface with the hardware of the computer, but the program only has to know how to read and write to this abstract file object, not how to control, say, the magnetic head to write a specific sequence of north/south poles into a rotating drum. The part of the OS that translates between the abstract idea of functionality (like a file) and the hardware is called a **driver**. This is also generally considered to be part of the operating system, but isn’t (usually) considered part of the *kernel*; instead, it’s more like a plugin that the kernel can defer to when one of the running programs wants to store or read information.
What parts of all these units fit into the kernel, and what parts are separate, are all part of the design of the operating system. Linux, Windows, Mac OS, Unix (etc…) all make separate choices here.
Finally, to the point of your question, there are basic programs that run in “user space” (not part of the protected kernel, but are programs that are being run *by* the kernel) and these programs often feel so fundamental to the operation of the computer that they are often confused with being part of the operating system. One such framework is the *desktop environment*. It is not part of the kernel, nor part of the OS, but is a very low-level fundamental framework that is present on many, many installations of the OS.
It is quite possible to run Linux with no desktop environment. A lot of embedded Linux installs don’t have one at all. It’s the same operating system, for the most part, but there’s no graphical interface. Instead, users have other ways of handling interaction. If it’s a full computer with mouse and keyboard, it might have a terminal emulator – only text and blinking cursors, no windows. If it’s an embedded Linux install it might not even have this, and it might just run some version of Linux on just the hardware at hand, be it a chip in a car, a wearable device, what have you.
Point being: the desktop environment is not part of Linux; rather, there are a few very popular programs that all run on Linux to give you the windows / desktop / file browser / start menu / etc, that sort of thing.
In general, one of the strengths of Linux is that the “layers” of what are thought about with regards to the OS are more split out and can be mixed and matched. If you run Windows, you get the Windows kernel and the Windows windowing system. They’re not the same thing, but you really only have the one choice, so it feels like it’s all part of the same thing, even if it’s not (you can still run the Windows kernel just from the command line with no GUI and interact with it in a DOS-like way).
On Linux, you have GNOME, KDE, xfce, etc… as options for the desktop environment that runs on top of the Linux kernel, and they all have a little bit different idioms, look and feel, etc…
OK. With me so far?
If you have a different desktop environment, generally any GUI app will be built to use that environment’s libraries. Programs that are built using GNOME will use GDK libraries, have GNOME-looking windows, fonts, that sort of thing. KDE will use KDE libraries and Qt for handling the GUI, bringing up windows for the UI, etc… So using a different desktop environment will look and feel different, and have different programs. There will be a GNOME program for graphically showing attached drives and for formatting them, and KDE will have a different program for the same purpose.
Last part of confusion, if you have the right libraries installed, you can usually run a different desktop environment’s programs if you really want to. You can run KDE’s drive manager on GNOME so long as you *also* have all the KDE libraries installed as well. For the most part, through, this feels like using a strange sibling program that has slightly different, say, menu structures, so people often stick to the programs using their main desktop environment.
So the desktop environment controls the look and feel of your windows, start menus, etc… but is not technically part of the OS kernel. If you use a different environment you will usually get different programs that are built for that environment.
Latest Answers