5 ms·
And BSDs removed it, deeming it a security risk. Personally, I don’t like that it’s more of parsing text files to get a number, when you could have functions r
by yakubin 4y ago
And BSDs removed it, deeming it a security risk.
Personally, I don’t like that it’s more of parsing text files to get a number, when you could have functions returning structs (of variable length, to get extensibility, while preserving backwards compatibility).
- trasz2 4y agoNot just BSDs; no major operating system other than Linux uses procfs anymore.
- kelnos 4y agoSure, but Linux is also on more devices than any other OS in the world. Your statement would be more damning it Linux was a minority player or on the decline, but that's not the case. Procfs seems... fine, really.
- ectopod 4y agoBeing pedantic, isn't Minix more widespread because Intel embedded it in CPUs?
- trasz2 4y agoAlso most Linux machines, like phones, also contain instances of things like SEL4, often a couple of them. And Linux... well, it managed to accumulate a lot of historical baggage for something that young. Device numbers are another example.
- TristanBall 4y agoNearly 30 years seems like plenty of time? Many projects manage to accumulate plenty of tech debt in 30 months, without being a deliberate work-alike reimplementation of an existing system.. which I suspect means you're already starting with a certain amount of baggage.
- linksnapzz 4y agoSolaris has had procfs for years.
- trasz2 4y agoSolaris is a history at this point.
- linksnapzz 4y agoOracle and Fujitsu still sell and support it.
- nix23 4y agoReally? Tell that oxide computers...well it's not Solaris but Illumos.
- somat 4y agoA fair assessment, but at the end of the day it is all just a stream of bits, bits packed into a into a structure, how do you know the structure?, how do you know how wide each part is? or bits packed into an array of encoded bytes. what is the encoding? how do you parse it? The array of encoded bytes despite it's complexity overhead has an advantage in that is lays on the human visible side of computing, that part of computers designed for the human to use. I have to admit more often than not I prefer to eat the overhead and have an interface that I can see.
- marcus0x62 4y agoThe BSD approach at the time was to require setuid access for programs like ps to be able to read the kernel memory space via /dev/kmem to produce a running process list. That is infinitely more stupid than procfs.
- asveikau 4y agoThe stupidity of that is orthogonal to whether to use procfs or another sane, but less plan9 approved design like a syscall interface or an ioctl. I'm reminded of another thing that used to be file based but moved away, and towards syscalls: random number generation. One criticism of a /dev/random approach I've seen is that open(2) could have some fringe error case (descriptor table too big?), and you don't want your secure RNG to bail on you. In particular lazy initialization of a secure RNG where the caller may not be able to check for errors.
- ilyt 4y agoOverall it's far more universal interface, you app "just" needs to parse relatively simple texfiles instead of api call per data type. The text format is a problem on its own tho, "procfs but serialized using single format" would IMO be a best middle ground between tying your app to essentially kernel headers and parsing a bunch of random textfiles