3 ms·

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

by pino82 2y ago

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.

pino82 2y ago
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.
- baq 2y ago
  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.
  - homebrewer 2y ago
    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.
telgareith 2y ago
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.
jdiez17 2y ago
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.
mastax 2y ago
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.

by pino82 2y ago

pino82 2y ago

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.

baq 2y ago
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.
- homebrewer 2y ago
  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.

telgareith 2y ago

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.

jdiez17 2y ago

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.

mastax 2y ago

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.