Readit NewsIt's a war, things have changed.
> in a mature product, reading and maintaining code takes about 10 times as much effort as writing it in the first place
Wouldn't that imply that rewriting a mature codebase from scratch would take ten times less effort than reading and maintaining it?
I only saw two instances where (different) management approved a complete rewrite of a working product and in both cases it turned out to be a disaster, because it is easy to severely underestimate how much effort it will take to match the features, quality and performance of the old codebase. I suspect it is almost universally better to refactor the old codebase incrementally.
Based on that, I take that you mean something else and I didn't get your point.
If a line of code belongs in a project with one file and a main() function, the presumption of impact of that code line on overall code paths is trivial.
If that line of code belongs in a library procedure used by a million LOC project, presumption cannot be done if you don't the project internals and tooling.
Rewriting entire systems or frameworks because one thinks that it's hard to implement a certain class of features is almost always a recipe for disaster.
The main article attempts to explain why instantaneous “spooky action at a distance” is real, yet information can’t be relayed this way.
I'll show myself out
Implementing a service manager that can understand and interpret systemd unit files for FreeBSD would require it to be based on completely different kernel mechanisms than Linux, feature parity aside. I can easily see that people with enough skill won’t see the need to be bothered to write such a piece of software, and those who don’t will just shrug and stay on Linux.
FreeBSD had to mock several parts of systemd in order to port newer GNOMEs that are dependent on systemd. rc still runs this software, but unfortunately software depends on systemd sockets which is absurd design choice but here we are. Again mocking the absurd interprocess part is the way to go, as opposed to supporting entire specification and API of systemd.
"Any unix" doesn't cut it, too general, too broad. You did ask in dual sense in your original question but then you specifically stated FreeBSD as an example; so I'm answering for FreeBSD specifically.
The problem that I have with opinion in your post is an implication about groups of people - people with skills that should supposedly write a systemd clone for FreeBSD or other Unices, and people without skills that are supposedly waiting for the first group to do some work so they can enjoy systemd on *BSD or wherever. Let me be blunt here, I can assure you this is not the case. Systemd is not a factor for anyone in BSD world and it's a factor only for people that would like to migrate from Linux and retain their usual workflow and muscle memory.
In practice this means more seamless 'isolation' in Linux case but that isolation is weak. Which perfectly corresponds to FreeBSD looking at server uses 99% of the time and Linux looking at the desktop too.
About your conclusion, I don't think that's based on anything so please do write on what facts do you base the assessment that FreeBSD has no resource limiting and isolation features, and that it would be a 'separate implementation', as FreeBSD always tends to upgrade and not change tools and interfaces, and that there is not enough interest from anyone to implement it, as most major FreeBSD features are actually paid for by FreeBSD sponsors.
(Another fun future would have been one where SCTP got widespread adoption.)
Otherwise you're just switching port (16-bit) value to arbitrary 32-bit identifier.