Comment by pino82 | Hacker News Reader

Comment by pino82 | Hacker News Reader

I just read the first few lines so far. They play around a lot with strings, compared to the fact that it's not about word processing but power management.

I'm not a developer on this system level of things. When you usually try to write 'nice' code, you are somewhat surprised about concerns like "convert the last space to a newline" there.

Yes, I know, everything is a file, and this is just the other side of this odd ancient paradigm.

To me it looks tedious. But, well, could be that this is just for me, because I'm not used to it. Maybe it's not a problem at all once you are deeper inside it.

But even from a logical perspective, it is funny: There is a file that contains all available sleep modes. Once you write a particular one into the same file (let's say you open it in a text editor and remove all states but one and then save), the system goes into that sleep mode.

Yes, I know, operating systems are different from a tiny web service in Python (and even there you start tricking around with weird http concepts instead)... It was just an observation.

I'm not sure where you're coming from here.

"Everything is a file" is literally part of the design philosophy.

Thats all it is: design philosophy. Well, besides improper string termination being the root of a staggering number of vulnerabilities.

There's nothing keeping somebody in either windows or linux from writing kernel code/drivers that takes syscalls instead of text, or text instead of syscalls. Except microsoft and the linux community would both decline to include it.

The funny thing is that Linux does have an alternative ioctl-based suspend interface (https://docs.kernel.org/power/userland-swsusp.html)... with an incompatible API and different purpose from the string-based one...

> Except microsoft and the linux community would both decline to include it.

And yet the number of syscalls and ioctls expands nonetheless. E.g., in Linux, they just last year added the listmount() and statmount() syscalls, even though they return substantially the same information as /proc/self/mountinfo, since the latter simply can't be queried as flexibly.

Cooool! Thx! I recently searched precisely for that, but was unable to find anything.

At first glance, the Redmond philosophy looks better to me here. I know that they made a lot of marketing around it (files vs APIs). And parts of that is just marketing bs, but there is some truth imho. What is all the string overhead really for? Isn't the client side equally tedious? You write e.g. weird shell scripts that sed/awk/grep some files from procfs or sysfs, spend a lot of time into string parsing, and then there are also corner cases where it fails (sometimes it's enough to have a space in some file names). What do I actually get back from all that complexity? There is probably something; I just haven't recognized it so far.

I'm asking that as a Linux-only-since-two-decades user btw.

> What do I actually get back from all that complexity?

Very easy experimentation / exploration, extremely rapid prototyping and one-off scripts.

I have written a GUI program to show memory pages of a process using procfs, it was fine. About two days of effort to parse and piece together data from obscure procfs files. A well-documented API with example code would have been faster I guess, but a text format with minimal documentation is OK.

I like Drew's racecar analogy (from https://drewdevault.com/2021/12/05/What-desktop-Linux-needs....): Linux is a high-performance F1 car intended mostly for advanced users, other operating systems are like an SUV.

That is an interesting comparison, from at least 2 different angles.

1. As a performance car: it's not a particularly high-performance OS compared to a lot of much smaller simpler OSes, such as RTOSes, but also including some former contemporaries (e.g. RISC OS, Symbian, or late-era OS/2). Last year I installed, updated and briefly used Windows XP64 as a desktop OS on some fairly late hardware it can support: a Core 2 Duo with 8GB of RAM, a discrete GPU, and an SSD.

https://www.theregister.com/2023/07/24/dangerous_pleasures_w...

It is amazingly fast and responsive compared even to the lightweight end of modern Linux, such as Crunchbang++, Bodhi Linux, or Q4OS. It's also faster and more responsive than OpenBSD or NetBSD.

The only thing that came close was Alpine Linux and XP64 still wins.

So, I think as a model of screaming fast performance vehicle is poor: it's not. As Neal Stephenson put it in _In The Beginning Was The Command Line_

https://web.stanford.edu/class/cs81n/command.txt

... it's a sort of super-efficient amphibious armoured car: big, fat, ugly, but can do anything on anything, will get you there, costs nothing and runs on anything (I am thinking of "Mr Fusion" from Back to the Future here.)

2. So how does it compare to an F1 car? Well, it's fiddly and delicate and complicated and only an expert can drive it.

It can be easy and nigh-on foolproof. Look at Android or ChromeOS. They are barely recognisable as Linux but they're billion-selling consumer OSes.

But it doesn't compare well to the performance aspects at all, IMHO. It's the ultimate Swiss army knife: can be used for anything but as a result it's huge and ugly and complicated and won't fit in any pocket.

That said, it could have been handled better than have from scratch string handling in every driver.

Compare Plan 9's getfields or approach from 9front https://man.9front.org/9/parsecmd

There was an article a while back, I think it was Marc talking about OpenBSDs pledge(), which argued that just taking a string argument of space separated flags is better than the traditional enum flags argument for a syscall. Sort of orthogonal but I found it very persuasive, even as someone who also breaks out in hives when I see my kernel full of stringly typed APIs.

PS: Yes, I know, if it would be a web api, I'd need to do play the same games with strings there.

But there it's at least obvious why it is needed (and it would also be less tedious in a modern scripting language, compared to dealing with string in raw C).

Again, I'm not really complaining. I'm just wondering whether one would still solve it in the same today in a brand new OS.

Microsoft has powershell and it’s a properly good tool for manipulating objects.

Strings are easiest to manipulate using string manipulation tools, which unix/linux/posix has plenty, and no standard way to expose objects. Perfect is the enemy of the good here.

I hope support for structured text output becomes more common. For example, the `ip` set of tools can output data in JSON, which is safe and easy to destructure and extract whatever fields you need. Seems like a nice middle ground.

  % ip --json link
  % ip --json addr

etc.

Not sure why people are downvoting you. Sure, it can seem surprising at first to see string management in the PM side of the Linux kernel. But the advantages of almost-everything-is-a-file are worth it.

Reply on news.ycombinator.com