It’s weird to use this title for a link that is not directly to Derek Sivers himself, but rather a blog quoting his post. To skip the intermediary, here’s Derek Sivers: https://sive.rs/openbsd
I would like to highlight a quote from Ruben’s article:
Every now and then I open top(1) and ps(1) aux on my Mac and Fedora machines, and balk at the sheer volume of background processes. Resource use is desirable if it can be accounted for, is transparent, serves a functional purpose, and if I require it. Otherwise it’s bloat, […]
Couldn’t agree more! (Or maybe it’s OCD on my side?)
Fortunately, being a long-time Linux user, and in fact a low-demand desktop user (99% of my work involves Firefox and URxvt, the rest being done in the terminal), I am able to trim down a lot of services to the point I can say each and every process what it’s purpose is.
However, last autumn I had the same feeling as the author, that perhaps Linux (like any modern operating system) has become too much, and I’ve taken a look at OpenBSD. It was OK-ish, but I just couldn’t do my job, mainly because Rust isn’t yet favorable to OpenBSD… (Not to mention wireless, although I’m using a cable even on Linux, WebRTC and other “niceties”…)
Part of the reason ps on the Mac runs so many processes is that Apple has pushed further than anyone else on compartmentlisation. This ought to make OpenBSD users happy, since OpenBSD was the first system to really push for privilege separation. The Apple OS family splits a lot of core system daemons into components the run with reduced privileges and communicate with others. Many of these have a tiny resource footprint (a few hundred KiBs of RSS and they occasionally wake up and consume 1% of a core). A lot of them are started via socket activation from launchd, so will exit after a while if they’re not actually being used and then start again when they’re needed.
That said, it would be nice if top and ps had a nice way of grouping these into abstract services, rather than just showing the raw processes.
I understand that privilege separation by having multiple processes is a general accepted solution; however if a tool requires more than 2 or 3 such separate processes, maybe there is an issue with the tool in the first place?
Also, I don’t think going the micro-services route is the best approach. The main problem with so many processes (especially socket activated ones) is complexity: with so many moving parts sooner or later things will not work properly, and diagnosing the whole thing is not a pleasant experience.
For example some time ago I found that Firefox on OpenSUSE takes ~30 seconds to start without any apparent reason (at least nothing was reported on stderr). The problem was that it tried to connect to dbus, and because dbus failed to activate something (because “reasons”), everybody just stood there and waited for some timeout to elapse…
Yeah, that’s one of the things I kindda find scary on my Mac. I’ve switched my personal machine to a Mac about two years ago and two years later, if I look at ps, I don’t even know what most of those things are.
Then again, I don’t find myself needing to run ps or top as often, since I’m not troubleshooting things as often, so I am not yet filled with existential dread about it :-D.
It’s weird to use this title for a link that is not directly to Derek Sivers himself, but rather a blog quoting his post. To skip the intermediary, here’s Derek Sivers: https://sive.rs/openbsd
I would like to highlight a quote from Ruben’s article:
Couldn’t agree more! (Or maybe it’s OCD on my side?)
Fortunately, being a long-time Linux user, and in fact a low-demand desktop user (99% of my work involves Firefox and URxvt, the rest being done in the terminal), I am able to trim down a lot of services to the point I can say each and every process what it’s purpose is.
However, last autumn I had the same feeling as the author, that perhaps Linux (like any modern operating system) has become too much, and I’ve taken a look at OpenBSD. It was OK-ish, but I just couldn’t do my job, mainly because Rust isn’t yet favorable to OpenBSD… (Not to mention wireless, although I’m using a cable even on Linux, WebRTC and other “niceties”…)
Part of the reason ps on the Mac runs so many processes is that Apple has pushed further than anyone else on compartmentlisation. This ought to make OpenBSD users happy, since OpenBSD was the first system to really push for privilege separation. The Apple OS family splits a lot of core system daemons into components the run with reduced privileges and communicate with others. Many of these have a tiny resource footprint (a few hundred KiBs of RSS and they occasionally wake up and consume 1% of a core). A lot of them are started via socket activation from launchd, so will exit after a while if they’re not actually being used and then start again when they’re needed.
That said, it would be nice if top and ps had a nice way of grouping these into abstract services, rather than just showing the raw processes.
I understand that privilege separation by having multiple processes is a general accepted solution; however if a tool requires more than 2 or 3 such separate processes, maybe there is an issue with the tool in the first place?
Also, I don’t think going the micro-services route is the best approach. The main problem with so many processes (especially socket activated ones) is complexity: with so many moving parts sooner or later things will not work properly, and diagnosing the whole thing is not a pleasant experience.
For example some time ago I found that Firefox on OpenSUSE takes ~30 seconds to start without any apparent reason (at least nothing was reported on
stderr). The problem was that it tried to connect todbus, and becausedbusfailed to activate something (because “reasons”), everybody just stood there and waited for some timeout to elapse…Yeah, that’s one of the things I kindda find scary on my Mac. I’ve switched my personal machine to a Mac about two years ago and two years later, if I look at
ps, I don’t even know what most of those things are.Then again, I don’t find myself needing to run
psortopas often, since I’m not troubleshooting things as often, so I am not yet filled with existential dread about it :-D.