35 ms·

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, besid

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.

nyanpasu64 2y ago
The funny thing is that Linux does have an alternative ioctl-based suspend interface (https://docs.kernel.org/power/userland-swsusp.html https://docs.kernel.org/power/userland-swsusp.html)... with an incompatible API and different purpose from the string-based one...
LegionMammal978 2y ago
> 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.
- pino82 2y ago
  Cooool! Thx! I recently searched precisely for that, but was unable to find anything.
pino82 2y ago
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.
- ahartmetz 2y ago
  > 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.
  - jdiez17 2y ago
    I like Drew's racecar analogy (from https://drewdevault.com/2021/12/05/What-desktop-Linux-needs.html 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.
    - lproven 2y ago
      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_win_xp_in_23/ 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 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.
p_l 2y ago
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 https://man.9front.org/9/parsecmd

nyanpasu64 2y ago

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

LegionMammal978 2y ago

> 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.

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

pino82 2y ago

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.

ahartmetz 2y ago
> 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.
- jdiez17 2y ago
  I like Drew's racecar analogy (from https://drewdevault.com/2021/12/05/What-desktop-Linux-needs.html 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.
  - lproven 2y ago
    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_win_xp_in_23/ 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 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.

p_l 2y ago

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 https://man.9front.org/9/parsecmd