💾 Archived View for yonado.cities.yesterweb.org › writings › 23.6.2024.gmi captured on 2024-08-24 at 23:29:49. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

My problems with UNIX(-likes)

UNIX is an operating system that is praised for it's philosophy, which has the same name (i.e. "UNIX philosophy"). I don't disagree with this philosophy, which summarized is basically:

Write small programs that do one and only one thing. Everything else is done through the combination of these small programs.

This is how UNIX is structured. You have small utilities like "cat," "ls," "grep," "awk," and so on that all do one thing. "cat" would output the contents of one or more files. The "grep" utility would find a particular string in some text. This is as opposed to having one command, let's say "cagrep" that would do both at once. This idea is certainly neat, but we'll get to that.

Problem 1: C is the language of the UNIX operating system

UNIX expects you to write programs that follow the aformentioned philosophy using the famous C programming language. The only issue with this is that C, to be completely blunt, is shit. C has already been critiqued to hell and back and if you'd like to know more issues with it, you can look for it elsewhere. Here are some off the back of my head:

It's not type safe. Examples of this include arrays decaying to pointers, which effectively allows you to set the array to pretty much anything. There's also the "void" type which nullifies any type checking.
Trying to be a low-level language. This is a bad idea because not all computer architectures are the same. C forces you to use its own abstract architecture and when you need to use anything else... compiler extension. To give C credit here, I can't think of a clear solution to this problem.
C needs a bunch of compiler extensions to fix some of its problems (and to add new things, and problems along with those things).
Implicit type promotion. Great idea for a low-level language.

C is not very pleasant to write either, take having to use "header" files for example. I would summarize it as having so many little quirks that they all add up to be stupid.

Problem 2: UNIX philosophy does not work for everything

Let's say there an internet browser that uses the UNIX philosophy. There are a bunch of tasks a browser needs to do. The first is rendering the document correctly. The second is requesting the document using the correct protocl. Getting user input might be the third task.

There are three seperate programs. One that gets a document, let's say via the Gemini protocol. One that renders it to the terminal, and passes it off to the user input program. This input might be passed to the document retrieval program. So good so far.

There's a slight problem: what's the point to all this passing of the ball? There can just be one program that does all these things and it would work better and in more unison and more efficiently than the former program that employs the philosophy. Why use the philosophy in something like this?

The UNIX philosophy is also somewhat vaguely defined. What constitues doing "one" thing? Does the document retrieval program ONLY retrieve documents using Gemini or can it also do it with Gopher? Does the rendering program also have to support rendering both Gopher and Gemini documents?

It all feels clumsy. For simpler programs, the UNIX philosophy may work.

Problem 3: Everything is a file

This can lead to being able to do cool stuff, like get user input from a file then pass it around like we do in UNIX. But we can also delete devices somehow and stop the system from working.

Problem 3.5: UNIX is inconsistent. Why not have a program that detects devices and does something with them? This would also employ the philosophy. Why choose to make the operating system work in this weird manner where you abstract away the way things like devices work into mere files?

Again, this could also just be a program. Or it could not be and be like a normal operating system. Detecting devices manually is not that much more difficult than the operating system automatically scanning for them and adding them as files into a filesystem that exists solely on memory.

The reason UNIX does this I presume is for a "unified" interface, which to it means a bunch of bytes. Devices are represented as bytes rather than ports that you read from (through which you get BYTES). Still, I think the way UNIX does it is weird, and does not provide that much bigger of an advantage over the way traditional systems do it.

I don't understand

Why are processes represented as a tree? Why does closing my terminal have to close everything else along with it? Was that the point? If so, then I don't get why we're forced into the tree hierarchy. If you fork a new process, then it becomes a child of the process that forked it. Cool. But what if I want the forked process to become independent? As far as I can tell, there's no way to do this but do correct this if you can.

Problem 4: Everything is UNIX-like

Most operating systems coming out today are UNIX-likes. They all use the same architecture as Linux and BSD do. I just feel like this might be hindering development in operating systems a bit if every other thing that comes out is yet another clone of the same 70's operating system.

Conclusion

UNIX and UNIX-likes are weird and stupid, but I feel like too much is based on these things to ever go back. Windows is certainly not much better.

Written from a UNIX-like

../