Can someone be kind enough to explain why "everything is a file" is such a GREAT idea that LITERALLY EVERYONE keeps hyping it up?

I'm literally losing my mind here trying to understand what makes it so great.

#linux #unix #posix #filesystem #filedescriptors #unixphilosophy

@innocentzero here's how I understand it. If I have it wrong I'm sure some other graybeard will chime in to correct me. Basically it sets up a lowest common denominator, a standard, on which nearly everything else operates. This makes the entire system ultimately flexible. It becomes easy to query, move, and manipulate everything with a simple set of tools.

@innocentzero at the lowest level nearly everything uses open(), read(), write(), close() calls. You don't need to learn a separate API for every type of device or resource.

That's at the core of the flexibility. Everything speaks the same language so things become ultimately composible. You can link series of command in infinite combinations.

Introspection becones trivial, you can cat everything. Security and permissions can be standardized and simplified.

@Tekchip @innocentzero you can use the same api, for example epoll() function for descriptors like socket tcp/udp, terminals, events, fifo, signals etc. It’s very cool for programmers.

@wesu @Tekchip

Hmm, I broadly seem to agree with these, but at the same time, I also find it too 'coarse-grained'.

Everything being a file is like a stop-gap solution to providing a proper, structured-data API for accessing OS-level resources, as everything's now reduced to an integer that you abstracted over.

In the end, I'd reckon you're paying for this simplicity by the tradeoff with security and performance.

@innocentzero @Tekchip Not really, it’s mature solution used and tested for years.

@wesu @Tekchip yes, and C is also a tried and tested 'solution' for systems programming, but I'd never take anyone says C is secure easily.

And yes, also stuff like this is why I think the entire model is too coarse-grained (if not outright horrible)

https://xcancel.com/i/status/2060746160558543217

MacOS exposes its internals through swift, a significantly richer language than C. A lot of linux's decisions seem to stem from providing a C compatible ABI, not necessarily a bad thing, but it really could be done better imho.

But I'm no OS dev, the best I've done is written firmware and ranted at C's idiosyncracies

Son Luong (@sluongng)

Codex just found a “workaround” of not having sudo on my pc…

Nitter
@wesu @innocentzero so is windows with its mess of APIs but absolutely no one (expect maybe Microsoft) is holding windows up as a bastion of security.
@Tekchip @wesu microslop is not in question here
@innocentzero @wesu that's a tough claim to make about security and performance given *nix is the OS of choice for most things that need to be performant and secure. BSDs are arguably security king and function on this principle.

@Tekchip @wesu

BSDs are secure because of small code surface.

Linux is performant because companies pour in huge amounts of resources into making it performant. Seriously, what other contenders are there? Not to mention, most perf-stuff actually massively deviates from unix philosophy.

If linux actually had a proper capability based oriented perms system, SELinux/AppArmor would not be a thing. There's a reason AOSP blocks so much kernel stuff through selinux and reimplements things through their Java layer. The recent vulnerabilities prove exactly this.

@innocentzero sounds like hell to me

@innocentzero Back in the 1970s, “everything is a file” was a pretty revolutionary idea. It allowed you to configure hardware and services using ordinary text editing tools, and treat text as objects on a map (the filesystem tree), whereas before you would have had to write numbers directly to certain locations in memory.

It is still a somewhat useful idea nowadays, it is just that there are actually better ways to do things. For example, relational algebra like what SQL databases provide, or object oriented systems like what Smalltalk systems provide (I think IBM’s OS/2 was an attempt at making an “everything is an object” operating system), or everything is an environment, like what Lisp systems provide.

And it is a lie, actually, not everything is a file. For example, you can’t change the list of processes that are running by just editing a file, you can’t rearrange a network of interacting processes by editing a file — you can write software that does this (Guix Shepherd), but the operating system itself will not without a lot of extra software installed.

For better or worse (mostly worse) the Unix philosophy won, and the whole computer industry adopted the “everything is a file (mostly)” approach. There has been much dispute as to why, but few question it nowadays.

The Unix way is not the end-all-be-all of computing paradigms, anyone who thinks so is probably not all that well informed. https://tilde.town/~ramin_hal9001/articles/emacs-unix-04_lisp-does-fp-better-than-bash.html

Worse Is Better

@ramin_hal9001
Thanks! This was insightful. I guess back in the day, systems were already really small, so this probably made things simpler.
@innocentzero that’s rights (at least, in terms of computing power). Also, computer technology had only recently evolved beyond entering information by punch card. “Time Sharing Systems” allowed many users to connect to a computer over the telephone and enter commands directly by teletype terminal. So a system of controlling the computer with text, especially allowing a person to save a file of commands and replay them as a “script,” or even send the output of one program to another, was a very useful innovation.

@innocentzero I like to think of it as a way to keep the kernel small, so that it can just provide access to hardware. Everything else should happen in userspace, where the code running has limited privileges.

A lot of functionality is exposed via ioctl(), where you are basically passing structured data to the kernel with a function code so that it knows what to do with it. It’s easier to ensure that the boundary between user and kernel is safe when the API is so consistent. That doesn’t mean it’s perfect, and there are certainly calls that require additional checks, but most can be covered by common code.