I prefer to see this type of project that builds upon what it considers the good parts of systemd, instead of systemic refusal and dismissal that I’ve seen mostly.
I think it makes sense to take in to account how a project is maintained. It’s not too dissimilar to how one might judge a company by the quality of their support department: will they really try to help you out if you have a problem, or will they just apathetically shrug it off and do nothing?
In the case of systemd, real problems have been caused by the way it’s maintained. It’s not very good IMO. Of course, some people go (way) to far in this with an almost visceral hate, but you can say that about anything: there are always some nutjobs that go way too far.
Disclaimer: I have not paid close attention to how systemd has been run and what kind of communication has happened around it.
But based on observing software projects both open and closed, I’m willing to give the authors of any project (including systemd) the benefit of the doubt. It’s very probable that any offensive behaviour they might have is merely a reaction to suffering way too many hours of abuse from the users. Some people have an uncanny ability to crawl under the skin of other people just by writing things.
There’s absolutely a feedback loop going on which doesn’t serve anyone’s interests. I don’t know “who started it” – I don’t think it’s a very interesting question at this point – but that doesn’t really change the outcome at the end of the day, nor does it really explain things like the casual dismissal of reasonable bug reports after incompatible changes and the like.
tbf, Lennart Poettering, the person people are talking about here is a very controversial personality. He can come across as an absolutely terrible know-it-all. I don’t know if he is like this in private, but I have seen him hijacking a conference talk by someone else. He was in the audience and basically got himself a mic and challenged anything that was said. The person giving the talk did not back down, but it was really quite something to see. This was either at Fosdem or at a CCC event, I can’t remember. I think it was the latter. It was really intense and over the top to see. There are many articles and controversies around him, so I think it is fair that people take that into account, when they look at systemd.
People are also salty because he basically broke their sound on linux so many years ago, when he made pulseaudio. ;-) Yes, that guy.
Personally I think systemd is fine, what I don’t like about it is the eternal growth of it. I use unit files all the time, but I really don’t need a new dhcp client or ntp client or resolv.conf handler or whatever else they came up with.
Seems illogical to say projects that use parts of systemd are categorically better than those that don’t, considering that there are plenty of bad ideas in systemd, and they wouldn’t be there unless some people thought they were good.
I prefer to see this type of project that builds upon what it considers the good parts of systemd
Obviously any project that builds on a part of system will consider that part to be good. So I read this as a categorical preference for projects that use parts of systemd.
I believe s6 is more styled after daemontools rather than systemd. I never looked at it too deeply, but that’s the impression I have from a quick overview, and also what the homepage says: “s6 is a process supervision suite, like its ancestor daemontools and its close cousin runit.”
A number of key concepts are shared, but it’s not like systemd invented those.
It’s a fork, not a rewrite. It’s not trivial to port systemd to a new os, and rewriting all in a new language would be a significant effort on top. For a one person project, let’s not expect miracles :-)
That sounds like part of the problem, not part of the requirement to me.
Considering *BSD’s religious repudiation of free software like GCC, wouldn’t polishing Rust (with its LLVM backend) be more “strategically” fitting than trying to support C with all of the GCCisms more popular codebases come with?
It took about 10 years for
gnu grep to be replaced sufficiently well in our tree. This stuff
doesn’t happen overnight.
Ripgrep was already around when this was written, and judging by the git commits, it took a few months to write to a working state. Perfected over several years, though. @burntsushi is that at all accurate?
It depends on the BSD; FreeBSD might be willing to do so because they’re willing to deploy new things, but OpenBSD is very conservative and TdR seems skeptical of languages that focus on memory safety. NetBSD might be willing, but it needs portability to architectures they kinda-support like VAX first.
(My stance on OpenBSD’s “security focus” is they’re focused on plugging holes in the boat, not structural improvements like formal methods or memory safe languages.)
(My stance on OpenBSD’s “security focus” is they’re focused on plugging holes in the boat, not structural improvements like formal methods or memory safe languages.)
Maybe; but actual viable replacements to C for stuff like kernel work is quite a new thing. It certainly wasn’t around when OpenBSD got started, or for most of its history. And whether we like it or not: C will be with us for a long time even if everyone would agree that we need to rewrite it all in $safer_language.
Some stuff in OpenBSD is written in Perl by the way, like the package manager.
Free software predates GNU, they don’t get to have a monopoly on it. I’m perfectly happy with GCC for now, especially since it includes numerous backends that LLVM doesn’t. Clang is fine, though. Getting moved beyond being a Tier 3 Rust platform if you’re not Linux seems to have become even harder recently.
If the RESF spent as much time submitting patches to all the software they so graciously could fix as they do making snarky comments, we’d all be living in their memory safe utopia by now.
Quite a lot can be done, actually. Safety-critical C code can be formally verified for correctness and memory safety using Frama-C and ACSL, for example.
And UBsan is one flag away from providing runtime checks for a big surface of undefined behaviours. Compilers already warn about UB that can be reasoned in compile-time and modern C has syntax to help them in a few corner cases.
But in the end this is very much about how a problem is decomposed into the provided elements of the machine abstraction that you chose to use. Being simple and easier to reason about is a very big plus that Rust folks simply disregard because they are all way smarter than the lot of us and are very proud of the big mess that Rust has become with all of their FOMO features (half-baked closures, unworkable recursive data-types, memory layouts that all resume to a big heap pool getting trashed at runtime, etc…).
OpenBSD and BSD’s in general are easy to understand and read and these kind of systemd alternative implementations are very welcome.
Now lets all take a moment to guess one language that does not have a single alternative compiler or implementation…
Sure, but maintaining Rust on half a dozen platforms that the core Rust team doesn’t care about is an enormous task requiring deep compiler knowledge. It’s not just “a patch”, because Rust is rapidly evolving and your patch will bitrot. It’s a huge open ended commitment.
I wouldn’t expect the OpenBSD team to have the resources or expertise to take on this huge task, and criticizing them for not doing this (using C instead) is off base. If you want systemd rewritten in Rust, (which may entail porting and maintaining Rust on all the platforms that systemd and Linux support) then by all means go ahead and keep us informed of your progress. Criticizing other people for not doing it seems off.
In the absence of porting Rust to all the platforms C supports, C (and to a large extent C++) continue to be the best systems languages if you want to support all of the platforms.
I mean, speaking as someone with deep familiarity with weird platforms, these ISAs are either used for existitng applications that don’t care about Rust (why would your VMS BASIC application need Rust?), the hobbyists are keeping it going are doing it out of inertia (i.e. compare ia64 to m68k hobbyists; former are basically dead, yet the latter has enough bodies for LLVM and Rust on a commercially/industrially dead platform), or the company that maintains it hasn’t gotten around to throwing money at the problem yet (i.e. AIX).
Considering the wide enough adoption, especially for people still using these non x86 platforms, I think it’s clear they have built credible operating systems.
How do you call a platform that can’t manage to maintain a Rust backend?
Dead.
Come on, man, I get it. I know Rust, I use it, and I like it. I want it to succeed so we can leave C and especially C++ behind us. But you can’t just go around and tell people what platforms to support in their project. That’s just not nice. That’s why people get mad at the RESF. That’s why they get hostile.
You can’t just show up at someone’s door and say hey, you know that thing you’ve been working on for the last two years or so – yeah, the one I’ve been working on in my spare time, late at night, after the wife’s gone to sleep – yeah, man, sucks to be you, we don’t support it so it’s dead, why don’t you do something more productive with your time instead? It’s just not nice.
Do you see how it’s not nice? How would you feel if, whenever someone posted something on Rust mailing list, someone who never used Rust, knows Rust, or even cares about it, for that matter, would chime in to say hah, you know what you call a language that makes you jump through hoops to get a doubly-linked list? Useless.
Nevermind that it makes it hard for those of us who like the language but aren’t die-hard fans in the Silicon Valley bubble to push for its adoption to our customers or inside our organisations. It’s just nasty. Please, if you won’t stop it, will you at least try to find a more elegant way to go about it?
It gives all of us a bad name and honestly, it’s ridiculous. If making everything more secure is so important, and Rust is such a sure way to go about it, that it’s worth being nasty to people, why not just wait for the inevitable demise of insecure software? Surely after enough CVEs people will just get bit one too many times and switch from OpenBSD to Redox OS or whatever on their own. So why not contribute to Redox OS instead of telling people how to go about writing OpenBSD?
How do you call a platform that can’t manage to maintain a Rust backend?
Dead.
What has changed in the FOSS community to create such ignorance?
There are more platforms besides amd64 and arm64 and they all have their value and people still use them in production. And some of them have no Rust backend for whatever reason but that doesn’t mean they’re dead!
On one hand, yes, I agree; I’m also tired of unsafety. On the other hand, Rust isn’t memory-safe, just less unsafe than C, so you’re selling snake oil. (Or, rather, you’re asking people to kill snakes and press their own homemade snake oil because you’re confident that it’s better than bear oil. Yeah, bear oil is bad, but so is snake oil.)
How do you call a platform that can’t manage to maintain a Rust backend?
Dead.
Arduino is not a dead platform. RISC-V is not a dead platform.
Right now, Rust is immature, unstable and has shitty platform support. Rust is so immature and unstable that it doesn’t have a formal definition, and there is only one viable implementation, whose constantly changing code defines the language semantics. This makes it a bad choice for people who want a mature language that provides deep guarantees that their code will still compile and run in 10 or 20 years. In the long term, Rust will likely become mature enough to challenge C in these respects, but not now.
As it stands, rust guarantees that your code will still compile and run in 10 or 20 years just as much as C does, thanks to editions and semver. In the rare cases it doesn’t, it’s because your code depended on some bad semantic bug, the same way C code will stop running properly because $compiler started to exploit some UB in your code to optimize it (or some new warning makes your -Werror fail).
A language is only as good as its community, and look at where you left Rust standing…
Way to go troll, if it makes you feel better, you are not alone, there are a ton of others like you in Rust that are just not up for the debate nor provide any useful knowledge or expertise about what is being argued about.
I know it’s the chicken-and-egg dilemma we’re so familiar with in the FOSS world, but software that runs today is often a safer and more reliable choice than software that might be written tomorrow. If my goal were to write an init system that provides systemd compatibility today, why would I spend time writing patches that have absolutely nothing to do with that problem?
And I mean a lot of time, we’re talking about sending substantial patches to the compiler and runtime of a language that rivals C++ in complexity, even if it’s nowhere near the same level of brain damage. It takes weeks just to get your bearings on that source tree, and that’s assuming you already know Rust very well.
There are problems in this world that people can, and want to solve today, not when Rust gets the things they need, whatever those things are.
Okay, first of all, we all know adding new platform support to any language, but especially an unstable one, is not a one-time investment. That’s evidenced by the fact that there are three tiers of platform support (with sub-tiers!) in Rust. Tier 1 ppc64 support is not going to happen because the people who write an init system send an occasional compiler patch.
Second, some people just want to write an init system. Not a compiler and not a language runtime. Just an init system. That’s their project. And the “it’s open source” argument applies both ways. Want to see Tier 1 ppc64 support in Rust? Great, send patches. Want to see an init system written in Rust? Great, well, send patches.
It’s not bait, it’s just an uninformed commenter that likes to repeat orange site narratives. Obviously, if we are still using C in 2021, it’s because there are no performant and portable alternatives. But in their mind, everybody uses an x64 CPU and has 16 gigs of RAM to run all their electron apps.
For the sake of discussion, I would say there is at least one language that fits your requirement: Ada.
But except for Ada, I would like to see some more effort on the Frama-C direction, or the (seemed defunct) Brainy Code Scanner effort.
Sincerely, I think it is way more realistic to keep developing in C and using tools such as mentioned above (or even Infer), than rewriting it in a new language, be it Ada, ATS, F*, Rust, or whatever the new hype is.
yes it is a platitude, but imo slightly better than considering a language as being generically “unsafe” (right after promoting rust as the solution to go…)
just another day at these forums I guess, sometimes I wonder if these rust promoters aren’t just bots that look out for C language posts and fire away ¯_(ツ)_/¯
I mean, I get where you’re coming from; I didn’t like the comment you’re responding to either. But I do think there’s truth to the core issue: we’ve tried this C thing for quite a while now, and we’re basically still running in to the same issues as decades ago. I don’t think Rust is necessarily the answer to all of these problems either though, but that’s a different story.
Personally I think this entire thing is just off-topic here; it’s just whining about C on something that happens to be written about C with no real substance, so I flagged the previous (now-deleted) comment as such.
But I do think there’s truth to the core issue: we’ve tried this C thing for quite a while now, and we’re basically still running in to the same issues as decades ago.
Serious question: are we running into the same issues over and over again because of the number of C codebases (eg net new problems)? Or are we running into the same problems over and over again in the same set of (< 100 widely used) codebases because they suck horribly, and reoffend?
I am not arguing porting those codebases to Rust isn’t viable, but what also seems viable is rearchitecting portions of said codebases to minimize potential security problems, adopting coding standards, sanitizers, investment into Frama-C, etc..
There are probably billions of lines of C out there as part of 10s of thousands of codebases that exist without any first hand knowledge of the original decisions, requirements, design, etc. Porting that code to Rust might as well be a project from scratch, starting at requirements, which will likely fail because Joe in accounting (who needs the software) doesn’t actually know that the system does X to account for Y… the “tribal” knowledge is long dead.
However, some smart kid touches the very important C code now and then to update typos or some constants and occasionally needs to debug and patch a segfault,. They can build and distribute new releases. They also likely have enough familiarity to apply recommendations from analysis tools and can make decisions on “this part of the code has scary business logic in it, I’ll leave it alone.”
This begs the question, though: is this codebase even an assessed security risk?
Serious question: are we running into the same issues over and over again because of the number of C codebases (eg net new problems)? Or are we running into the same problems over and over again in the same set of (< 100 widely used) codebases because they suck horribly, and reoffend?
I don’t know exactly. The number of common (C) applications and libraries exposed to untrusted input/the network is actually not all that large in total, so it kind of makes sense it’s a comparatively small set we keep hearing about. As far as I know, there are very few significant codebases that have avoided these problems entirely.
As for the rest: I don’t think we should start rewriting C to $something_else en-masse. That would be silly, for the reasons you mentioned. I accept the reality that C will be with us for a long time and just continue writing in C where it makes sense, but also think that some newer languages would actually be better in the vast majority of cases.
But I’d rather be stabbed by a butter knife than with a sword.
I’d rather be slashed with a butter knife, but not stabbed. The butter knife’s bluntness would require way more force to stab, where as a sword probably goes through smooth…
Basically, you’re being brutally assaulted, too, if being stabbed by a butter knife.
If you’re actively being stabbed, I think Rust is the least of your immediate problems. But I definitely would prefer to be stabbed by a Ceramic knife/sword to avoid the complications of Rust.
here used as a response to “my favourite gun doesn’t kill good people”.
which is not something new since C has a track record of getting attacked by most other languages whenever these languages bring something “new(ish)” while making the tradeoff of complexifying the simple machine abstraction that C does (which was imo Dennis Richie greatest achievement).
this was just my poor miserable attempt at trying to avoid the discussion derailing into a Rust discussion…
Unfortunately it commits the sin of handrolling its own binary format. It would be much wiser to have instead used SQLite.
There’s a reason they use their own linear format. Sealing the previous entries with a signature guarantees any modifications before the signature will be spotted. Achieving the same properties with sqlite would likely be tricky. (or force sealing to be detached and the file split on each signature) Also it’s close to append-only, compared to a real database which needs to rewrite the trees sometimes. (format: https://systemd.io/JOURNAL_FILE_FORMAT/)
Yep. Amusingly, while journald was initially one of the reasons I personally hated systemd, I somehow made peace with it when I suddenly grokked why they were doing what they’re doing. I still wish journald weren’t quite as prone as it is to “…and 37 really important logs you badly wanted were dropped because I got overloaded,” but the structured queries and auditing features are a genuine step up from text-based logs–especially when doing forensics.
That is amazing! I was unaware of such a project. I’m not asking it to become the default, I just would like such an init system to be available on BSD at the administrator’s choice. (which would be my case)
This is a great result for what it seems to be a one-man project.
I’m not asking it to become the default, I just would like such an init system to be available on BSD at the administrator’s choice. (which would be my case)
Interesting – I find BSDs appealing and use them because of a lack of choice. The whole system is “curated”, all the parts fit together. I have to check manpages to know apache uses -t to check its config file whereas haproxy uses -c, but if I use relayd and httpd I use the same flag that I use for pfctl and other builtins.
So for me, the fact that “there’s one way to do it” is quite appealing!
In my experience, BSD is more curated than Linux, but I wouldn’t say it follows the “there is only one way to do it” principle. For example, on both FreeBSD and NetBSD, there is more than one firewall included by default (pf, ipfilter, npf etc.), and the administrator can generally choose whichever he prefers.
I just would like such an init system to be available on BSD at the administrator’s choice
I replaced the FreeBSD’s rc.d with daemontools 15 years ago. It was just a port at the time (not sure if it still is), and it’s something that’s been possible for a long time if you’re willing to put a bit of effort in it.
I’m a staunch systemd detractor. I support this project; it’s nice to have options!
It’s nice to see supervisor inits making their way into BSD; I wonder how it works with the license? surely a fork is GPL’d? Thus it could never be shipped by default.
I’m glad they didn’t take the journal format, but I wonder if they could take inspiration from Solaris SMF, in that the supervisor init tracks the log file (or can output STDERR/STDOUT on behalf of the process to a log file).
My anti-systemd views:
Contrary to those who wish to misrepresent “systemd haters”: I (and I suspect many others) don’t actually hate many of the concepts behind systemd.
I dislike systemd because it is difficult to debug, rolled a lot of it’s own reimplementations of things in difficult to debug ways (let’s do DNS over DBUS!) and claims to be modular while having tight integration to things making it an all-or-nothing deployment in most circumstances.
I dislike systemd because it removes the possibility of something better coming along later, because any potential reimplementations of an init will need to be a very large codebase and have to emulate quirks and odd-behaviours of systemd.
OpenBSD’s init scripts are quite a bit simpler than the tangled mess that was the norm on linux (Slackware being the notable exception). They’re almost nonexistent compared to systemd.
For example, here’s a typical openbsd init script:
I could post the entire openbsd init system in this one comment – it doesn’t hit the size limit. I won’t, because it’s just a bit antisocial to paste a wall of text just to prove a point.
It’s not like SysV init and systemd are the only two options.
I actually really dislike SysV init, always have. OpenRC is the worst part of Alpine by far. But at least I can debug them. If I run in to an issue with systemd … there’s basically no chance I can debug it.
Systemd is worse to debug though. It’s compiled & has a non-deterministic dependency graph.
I agree somewhat that bash is intimidating but it’s not compiled and is definitely easier than C for new users; but a few things stand out:
Your comment is a false dichotomy because there already existed inits which do not use shellscripts at all (runit, SMF)
you don’t have to use bash at all, you could invoke any interpreter, Perl/Python/Ruby (I have done this)
bash -x can be used if you’re stuck
you can modify many behaviours as a user, how easy is it to modify systemd? There are things which are easy, but a lot of things are quite a bit harder. (Arguments against HCL/Yaml for systems management apply in their entirety here).
And anyway this is arguing about the init again, and there are some good ideas. My main gripe about the init is that it positions itself in a place that’s hard to replace and that it is more difficult to debug for power users.
My larger issues surround systemd as an ecosystem.
I’m a bit confused about…well, honestly, most of your points.
systemd the tool is compiled, but the units are all interpreted. Or, if you prefer this phrasing: bash is compiled if systemd is compiled.
runit is pretty much literally just shell scripts, so I don’t get that comment, either. And while you’re right in a strict sense that SMF isn’t shell scripts, they largely just describe when and how to execute arbitrary command line apps, which is basically also what systemd does.
bash -x can be used if you’re stuck only if the scripts involved do something more than exec /sbin/foo -a -b -c, and that (well, along with something like chpst) is often all there is to such a shell script, anyway
I’d need some (any?) specific examples of things that you find easier to modify as a user than via systemd. Things I can trivially do in systemd that I can’t in native init include e.g. providing access to some root-owned files while not running the process as root or providing generic access, doing equivalents of privilege dropping even if the executable does not itself support it, trivially having inetd-style launch-on-connection/file-action/etc., and more. You absolutely can do these without systemd (often using things like inetd), but they’re not trivial, and I cannot personally think of an inverse.
I have a very complicated, at best ultimately neutral, attitude towards systemd, but I’d like to make sure we’re all on the same page about what systemd does and does not do, and how it does and does not work, so the discussion is actually valid.
I think the simple answer here is that you can’t even do conditionals with the .ini file format.
runit can run shell scripts, or you can just call a command to run. It’s supervised so you don’t have to care about forking/logging
if exec /sbin/foo is what is failing you can run it in runlevel 3 and get a pretty error message.
Trivially: checking that the environment is sane before running commands. There are still systemd units which call bash scripts because you don’t want to clobber data in some situations. Starting PostgreSQL for the first time for example if the datadir is empty or scanning for LVM volumes properly before mounting gets easier if you control it.
Like I keep saying, systemd the init has parts that beat out bash for sure, it’s easier as a user until it breaks, when it breaks you’re hopelessly fucked though (and I lived through the early days of systemd on fedora so I’m aware of just how fucked you can be).
It’s interesting that I this thread has become a defence of bash when really I don’t hold much love for bash; and this is what most people who like systemd prefer to talk about too… I don’t hate systemd because it is not Turing complete or that it’s not bash or whatever… What I do hate about systemd for is the almost closed off ecosystem due to tight integrations, the fact that it’s default everywhere and in some cases can’t even be removed and lastly the awful code/attitude of the project generally.
You can’t tell me that it’s “as debuggable” or that anything you’ve said isn’t a false equivalence, for instance if you’re decrying “exec” as being obtuse and undebuggable then systemd only does that anyway!
(Obligatory disclaimer: I’m not a systemd “fan”, but I use it and like some of the features. This ain’t an anti-systemd rant :-D).
An example from a while ago. I worked on a tiny gizmo that ran Linux. Yocto, being the steaming pile of sh quirky array of tools that it is, generated some weird image that systemd-fsck really wanted to fsck each time, for some mysterious reason.
This was early at boot time, and systemd-fsck provided pretty much no diagnostic info at all at the time (I don’t know if it’s changed in the meantime).
How do you debug this?
The best I could figure out was to get a custom systemd build up and debug it by printf, pretty much the way I’d have done it if it were all shell scripts, except with an extra, and pretty lengthy compile, generate image, burn to flash cycle in-between. If it were all shell scripts, I could’ve at least done it on-device.
I’m not saying this single incident would justify returning to shell scripts, that’s really not the case. It’s just an example of something that’s now a little harder to debug than before.
Considering that init scripts are also difficult to debug, this is just a sidegrade at worst.
Depends on the OS, the BSD’s all use similar rc.d frameworks for their init scripts, so they’re almost always declarative and fairly trivial to debug with standard unix utilities.
Now here’s the “unpopular opinion puffer meme”: that we’re in this situation means that Linux developers are implementing a form of open source vendor lock-in. With Docker, k8s, SystemD, etc, Linux is enticing developers to write code that only runs on Linux–that is, locks users into Linux.
It’s because of this open source vendor lock-in strategy that we inthe BSDs need some level of compatibility. Though FreeBSD has had a notion of containerization for over two decades, Linux’s Docker is way more popular. SystemD is wholly incompatible with any of the init systems in the BSDs. Yet some projects only support SystemD integration.
Perhaps this is because Linux offers functionality that is useful for developers, and the lowest common denominator is no longer adequate.
FreeBSD users and devs seem to think that people who don’t use or develop for FreeBSD only do so because they haven’t heard of and used FreeBSD. The fact that some smart people have looked at FreeBSD and said “Nah” doesn’t seem to occur to them
To be kinder, I actually like FreeBSD (it’s more “tasteful” than the average Linux distribution), but the reality is baseline POSIX is anemic for a modern application outside of the typical 90s Unix model, and no one really wants to catch up and standardize modern functionality (or shared common functionality). Especially when it comes to distribution/isolation.
I brought it before, but it’s a lot of wasted potential; FreeBSD’s biggest fans seem to ignore if not revile its most interesting aspects. They were first to the punch with jails - they could have led a container revolution. Instead, the tooling was painful and the rest of the world uses Docker instead.
I kinda like FreeBSD. It’s very simple, and 20 years of UNIX administration really pays off, BUT.
The rough edges on it really rub me the wrong way. I know that there’s an easier way to do most of the things FreeBSD makes really hard, and the documentation can be really inconsistent and years out of date, with no indication that there might be a newer, better way of solving some problem that somebody has come up with since the documentation was written (see LDAP authentication for a good example of that).
Yes, pkg is another papercut factory. I’d like pkg base, but that’s also predicated on pkg catching up to i.e. apk. Hope you don’t mix ports and packages!
I’ve also found the lauded Handbook slightly lacking.
Interesting. It even aims to support Linux. Will this be the new go-to option for Linux distributions who specifically want to avoid systemd? In fact, I always wondered why nobody came up with the idea yet to simply support .service files in other init systems like OpenRC.
This is an interesting project, but being perfectly happy with the OpenBSD init system right now, I see no reasons to try systemd on OpenBSD.. in fact, I see a lot of reasons not to, unless I had a very specific use case.
I prefer to see this type of project that builds upon what it considers the good parts of systemd, instead of systemic refusal and dismissal that I’ve seen mostly.
Same. Too often I see “critiques” of systemd that essentially boil down to personal antipathy against its creator.
I think it makes sense to take in to account how a project is maintained. It’s not too dissimilar to how one might judge a company by the quality of their support department: will they really try to help you out if you have a problem, or will they just apathetically shrug it off and do nothing?
In the case of systemd, real problems have been caused by the way it’s maintained. It’s not very good IMO. Of course, some people go (way) to far in this with an almost visceral hate, but you can say that about anything: there are always some nutjobs that go way too far.
Disclaimer: I have not paid close attention to how systemd has been run and what kind of communication has happened around it.
But based on observing software projects both open and closed, I’m willing to give the authors of any project (including systemd) the benefit of the doubt. It’s very probable that any offensive behaviour they might have is merely a reaction to suffering way too many hours of abuse from the users. Some people have an uncanny ability to crawl under the skin of other people just by writing things.
There’s absolutely a feedback loop going on which doesn’t serve anyone’s interests. I don’t know “who started it” – I don’t think it’s a very interesting question at this point – but that doesn’t really change the outcome at the end of the day, nor does it really explain things like the casual dismissal of reasonable bug reports after incompatible changes and the like.
I think that statements like “casual dismissal” and “reasonable bug reports” require some kind of example.
tbf, Lennart Poettering, the person people are talking about here is a very controversial personality. He can come across as an absolutely terrible know-it-all. I don’t know if he is like this in private, but I have seen him hijacking a conference talk by someone else. He was in the audience and basically got himself a mic and challenged anything that was said. The person giving the talk did not back down, but it was really quite something to see. This was either at Fosdem or at a CCC event, I can’t remember. I think it was the latter. It was really intense and over the top to see. There are many articles and controversies around him, so I think it is fair that people take that into account, when they look at systemd.
People are also salty because he basically broke their sound on linux so many years ago, when he made pulseaudio. ;-) Yes, that guy.
Personally I think systemd is fine, what I don’t like about it is the eternal growth of it. I use unit files all the time, but I really don’t need a new dhcp client or ntp client or resolv.conf handler or whatever else they came up with.
In my experience, most people who hate systemd also lionize and excuse “difficult” personalities like RMS, Linus pre-intervention, and Theo de Raadt.
I think it’s fine to call out abrasive personalities. I also appreciate consistency in criticism.
Why?
At least because it’s statistically improbable that there are no good ideas in systemd.
Seems illogical to say projects that use parts of systemd are categorically better than those that don’t, considering that there are plenty of bad ideas in systemd, and they wouldn’t be there unless some people thought they were good.
Where did I say that though?
Obviously any project that builds on a part of system will consider that part to be good. So I read this as a categorical preference for projects that use parts of systemd.
There have been other attempts at this. uselessd (which is now abandoned) and s6 (which still seems to be maintained)
I believe s6 is more styled after daemontools rather than systemd. I never looked at it too deeply, but that’s the impression I have from a quick overview, and also what the homepage says: “s6 is a process supervision suite, like its ancestor daemontools and its close cousin runit.”
A number of key concepts are shared, but it’s not like systemd invented those.
[Comment from banned user removed]
It’s a fork, not a rewrite. It’s not trivial to port systemd to a new os, and rewriting all in a new language would be a significant effort on top. For a one person project, let’s not expect miracles :-)
I realize I’m probably replying to bait but you do realize the BSDs are written almost entirely in C and will be for the foreseeable future, right
That sounds like part of the problem, not part of the requirement to me.
Considering *BSD’s religious repudiation of free software like GCC, wouldn’t polishing Rust (with its LLVM backend) be more “strategically” fitting than trying to support C with all of the GCCisms more popular codebases come with?
Theo answered this a few years back.
https://marc.info/?l=openbsd-misc&m=151233345723889&w=2
Fortunately someone did write it - not just ls, but most of the coreutils: https://github.com/uutils/coreutils
It was created in 2013 which makes the post in 2017 look not very well informed. He is right about the compilation time though.
(from the mail written by Theo in 2017)
Ripgrep was already around when this was written, and judging by the git commits, it took a few months to write to a working state. Perfected over several years, though. @burntsushi is that at all accurate?
It depends on the BSD; FreeBSD might be willing to do so because they’re willing to deploy new things, but OpenBSD is very conservative and TdR seems skeptical of languages that focus on memory safety. NetBSD might be willing, but it needs portability to architectures they kinda-support like VAX first.
(My stance on OpenBSD’s “security focus” is they’re focused on plugging holes in the boat, not structural improvements like formal methods or memory safe languages.)
Maybe; but actual viable replacements to C for stuff like kernel work is quite a new thing. It certainly wasn’t around when OpenBSD got started, or for most of its history. And whether we like it or not: C will be with us for a long time even if everyone would agree that we need to rewrite it all in $safer_language.
Some stuff in OpenBSD is written in Perl by the way, like the package manager.
Free software predates GNU, they don’t get to have a monopoly on it. I’m perfectly happy with GCC for now, especially since it includes numerous backends that LLVM doesn’t. Clang is fine, though. Getting moved beyond being a Tier 3 Rust platform if you’re not Linux seems to have become even harder recently.
Presumably as Rust matures and it’s standard library grows it becomes a bigger push to meet the quality bar.
OpenBSD supports many hardware platforms that Rust does not. C is the correct choice, given their goals.
[Comment from banned user removed]
If the RESF spent as much time submitting patches to all the software they so graciously could fix as they do making snarky comments, we’d all be living in their memory safe utopia by now.
What are these patches are supposed to do?
If there is C/C++ code, there is little more to be done than to decommission it. Sending patches would be the opposite of that.
Quite a lot can be done, actually. Safety-critical C code can be formally verified for correctness and memory safety using Frama-C and ACSL, for example.
And UBsan is one flag away from providing runtime checks for a big surface of undefined behaviours. Compilers already warn about UB that can be reasoned in compile-time and modern C has syntax to help them in a few corner cases.
But in the end this is very much about how a problem is decomposed into the provided elements of the machine abstraction that you chose to use. Being simple and easier to reason about is a very big plus that Rust folks simply disregard because they are all way smarter than the lot of us and are very proud of the big mess that Rust has become with all of their FOMO features (half-baked closures, unworkable recursive data-types, memory layouts that all resume to a big heap pool getting trashed at runtime, etc…).
OpenBSD and BSD’s in general are easy to understand and read and these kind of systemd alternative implementations are very welcome.
Now lets all take a moment to guess one language that does not have a single alternative compiler or implementation…
To be fair there is at least one alternative compiler for Rust technically, mrustc.
Sure, but maintaining Rust on half a dozen platforms that the core Rust team doesn’t care about is an enormous task requiring deep compiler knowledge. It’s not just “a patch”, because Rust is rapidly evolving and your patch will bitrot. It’s a huge open ended commitment.
I wouldn’t expect the OpenBSD team to have the resources or expertise to take on this huge task, and criticizing them for not doing this (using C instead) is off base. If you want systemd rewritten in Rust, (which may entail porting and maintaining Rust on all the platforms that systemd and Linux support) then by all means go ahead and keep us informed of your progress. Criticizing other people for not doing it seems off.
In the absence of porting Rust to all the platforms C supports, C (and to a large extent C++) continue to be the best systems languages if you want to support all of the platforms.
[Comment removed by moderator pushcx: Cleaning up some troll comments from banned user.]
Dead to you. Not dead to its users or the industrial machines still using it.
I mean, speaking as someone with deep familiarity with weird platforms, these ISAs are either used for existitng applications that don’t care about Rust (why would your VMS BASIC application need Rust?), the hobbyists are keeping it going are doing it out of inertia (i.e. compare ia64 to m68k hobbyists; former are basically dead, yet the latter has enough bodies for LLVM and Rust on a commercially/industrially dead platform), or the company that maintains it hasn’t gotten around to throwing money at the problem yet (i.e. AIX).
[Comment removed by moderator pushcx: Cleaning up some troll comments from banned user.]
Considering the wide enough adoption, especially for people still using these non x86 platforms, I think it’s clear they have built credible operating systems.
Come on, man, I get it. I know Rust, I use it, and I like it. I want it to succeed so we can leave C and especially C++ behind us. But you can’t just go around and tell people what platforms to support in their project. That’s just not nice. That’s why people get mad at the RESF. That’s why they get hostile.
You can’t just show up at someone’s door and say hey, you know that thing you’ve been working on for the last two years or so – yeah, the one I’ve been working on in my spare time, late at night, after the wife’s gone to sleep – yeah, man, sucks to be you, we don’t support it so it’s dead, why don’t you do something more productive with your time instead? It’s just not nice.
Do you see how it’s not nice? How would you feel if, whenever someone posted something on Rust mailing list, someone who never used Rust, knows Rust, or even cares about it, for that matter, would chime in to say hah, you know what you call a language that makes you jump through hoops to get a doubly-linked list? Useless.
Nevermind that it makes it hard for those of us who like the language but aren’t die-hard fans in the Silicon Valley bubble to push for its adoption to our customers or inside our organisations. It’s just nasty. Please, if you won’t stop it, will you at least try to find a more elegant way to go about it?
It gives all of us a bad name and honestly, it’s ridiculous. If making everything more secure is so important, and Rust is such a sure way to go about it, that it’s worth being nasty to people, why not just wait for the inevitable demise of insecure software? Surely after enough CVEs people will just get bit one too many times and switch from OpenBSD to Redox OS or whatever on their own. So why not contribute to Redox OS instead of telling people how to go about writing OpenBSD?
What has changed in the FOSS community to create such ignorance?
There are more platforms besides amd64 and arm64 and they all have their value and people still use them in production. And some of them have no Rust backend for whatever reason but that doesn’t mean they’re dead!
[Comment removed by moderator pushcx: Cleaning up some troll comments from banned user.]
On one hand, yes, I agree; I’m also tired of unsafety. On the other hand, Rust isn’t memory-safe, just less unsafe than C, so you’re selling snake oil. (Or, rather, you’re asking people to kill snakes and press their own homemade snake oil because you’re confident that it’s better than bear oil. Yeah, bear oil is bad, but so is snake oil.)
Arduino is not a dead platform. RISC-V is not a dead platform.
Right now, Rust is immature, unstable and has shitty platform support. Rust is so immature and unstable that it doesn’t have a formal definition, and there is only one viable implementation, whose constantly changing code defines the language semantics. This makes it a bad choice for people who want a mature language that provides deep guarantees that their code will still compile and run in 10 or 20 years. In the long term, Rust will likely become mature enough to challenge C in these respects, but not now.
As it stands, rust guarantees that your code will still compile and run in 10 or 20 years just as much as C does, thanks to editions and semver. In the rare cases it doesn’t, it’s because your code depended on some bad semantic bug, the same way C code will stop running properly because $compiler started to exploit some UB in your code to optimize it (or some new warning makes your
-Werrorfail).[Comment from banned user removed]
A language is only as good as its community, and look at where you left Rust standing…
Way to go troll, if it makes you feel better, you are not alone, there are a ton of others like you in Rust that are just not up for the debate nor provide any useful knowledge or expertise about what is being argued about.
I know it’s the chicken-and-egg dilemma we’re so familiar with in the FOSS world, but software that runs today is often a safer and more reliable choice than software that might be written tomorrow. If my goal were to write an init system that provides systemd compatibility today, why would I spend time writing patches that have absolutely nothing to do with that problem?
And I mean a lot of time, we’re talking about sending substantial patches to the compiler and runtime of a language that rivals C++ in complexity, even if it’s nowhere near the same level of brain damage. It takes weeks just to get your bearings on that source tree, and that’s assuming you already know Rust very well.
There are problems in this world that people can, and want to solve today, not when Rust gets the things they need, whatever those things are.
[Comment from banned user removed]
Okay, first of all, we all know adding new platform support to any language, but especially an unstable one, is not a one-time investment. That’s evidenced by the fact that there are three tiers of platform support (with sub-tiers!) in Rust. Tier 1 ppc64 support is not going to happen because the people who write an init system send an occasional compiler patch.
Second, some people just want to write an init system. Not a compiler and not a language runtime. Just an init system. That’s their project. And the “it’s open source” argument applies both ways. Want to see Tier 1 ppc64 support in Rust? Great, send patches. Want to see an init system written in Rust? Great, well, send patches.
It’s not bait, it’s just an uninformed commenter that likes to repeat orange site narratives. Obviously, if we are still using C in 2021, it’s because there are no performant and portable alternatives. But in their mind, everybody uses an x64 CPU and has 16 gigs of RAM to run all their electron apps.
[Comment removed by moderator pushcx: Cleaning up some troll comments from banned user.]
Give me a (non obscure) language that fits the description, then.
For the sake of discussion, I would say there is at least one language that fits your requirement: Ada.
But except for Ada, I would like to see some more effort on the Frama-C direction, or the (seemed defunct) Brainy Code Scanner effort.
Sincerely, I think it is way more realistic to keep developing in C and using tools such as mentioned above (or even Infer), than rewriting it in a new language, be it Ada, ATS, F*, Rust, or whatever the new hype is.
all languages are unsafe if you are not careful
All blades are unsafe too. But I’d rather be stabbed by a butter knife than with a sword.
yes it is a platitude, but imo slightly better than considering a language as being generically “unsafe” (right after promoting rust as the solution to go…)
just another day at these forums I guess, sometimes I wonder if these rust promoters aren’t just bots that look out for C language posts and fire away ¯_(ツ)_/¯
I mean, I get where you’re coming from; I didn’t like the comment you’re responding to either. But I do think there’s truth to the core issue: we’ve tried this C thing for quite a while now, and we’re basically still running in to the same issues as decades ago. I don’t think Rust is necessarily the answer to all of these problems either though, but that’s a different story.
Personally I think this entire thing is just off-topic here; it’s just whining about C on something that happens to be written about C with no real substance, so I flagged the previous (now-deleted) comment as such.
Serious question: are we running into the same issues over and over again because of the number of C codebases (eg net new problems)? Or are we running into the same problems over and over again in the same set of (< 100 widely used) codebases because they suck horribly, and reoffend?
I am not arguing porting those codebases to Rust isn’t viable, but what also seems viable is rearchitecting portions of said codebases to minimize potential security problems, adopting coding standards, sanitizers, investment into Frama-C, etc..
There are probably billions of lines of C out there as part of 10s of thousands of codebases that exist without any first hand knowledge of the original decisions, requirements, design, etc. Porting that code to Rust might as well be a project from scratch, starting at requirements, which will likely fail because Joe in accounting (who needs the software) doesn’t actually know that the system does X to account for Y… the “tribal” knowledge is long dead.
However, some smart kid touches the very important C code now and then to update typos or some constants and occasionally needs to debug and patch a segfault,. They can build and distribute new releases. They also likely have enough familiarity to apply recommendations from analysis tools and can make decisions on “this part of the code has scary business logic in it, I’ll leave it alone.”
This begs the question, though: is this codebase even an assessed security risk?
I don’t know exactly. The number of common (C) applications and libraries exposed to untrusted input/the network is actually not all that large in total, so it kind of makes sense it’s a comparatively small set we keep hearing about. As far as I know, there are very few significant codebases that have avoided these problems entirely.
As for the rest: I don’t think we should start rewriting C to $something_else en-masse. That would be silly, for the reasons you mentioned. I accept the reality that C will be with us for a long time and just continue writing in C where it makes sense, but also think that some newer languages would actually be better in the vast majority of cases.
I’d rather be slashed with a butter knife, but not stabbed. The butter knife’s bluntness would require way more force to stab, where as a sword probably goes through smooth…
Basically, you’re being brutally assaulted, too, if being stabbed by a butter knife.
Further complications may arise if one of them has rust.
If you’re actively being stabbed, I think Rust is the least of your immediate problems. But I definitely would prefer to be stabbed by a Ceramic knife/sword to avoid the complications of Rust.
Ahh yes, the “guns don’t kill people” of langsec discussions.
here used as a response to “my favourite gun doesn’t kill good people”.
which is not something new since C has a track record of getting attacked by most other languages whenever these languages bring something “new(ish)” while making the tradeoff of complexifying the simple machine abstraction that C does (which was imo Dennis Richie greatest achievement).
this was just my poor miserable attempt at trying to avoid the discussion derailing into a Rust discussion…
From reasons for excluding journald:
There’s a reason they use their own linear format. Sealing the previous entries with a signature guarantees any modifications before the signature will be spotted. Achieving the same properties with sqlite would likely be tricky. (or force sealing to be detached and the file split on each signature) Also it’s close to append-only, compared to a real database which needs to rewrite the trees sometimes. (format: https://systemd.io/JOURNAL_FILE_FORMAT/)
Yep. Amusingly, while journald was initially one of the reasons I personally hated systemd, I somehow made peace with it when I suddenly grokked why they were doing what they’re doing. I still wish journald weren’t quite as prone as it is to “…and 37 really important logs you badly wanted were dropped because I got overloaded,” but the structured queries and auditing features are a genuine step up from text-based logs–especially when doing forensics.
If you the default rate limit settings don’t suite your usecase you can just change them so that they do?
It would have been nice if they’re reused the auditd / auditdistd format, which already had these properties.
I am not familiar with auditd format, so could you tell if it also supports other features of journal:
That is amazing! I was unaware of such a project. I’m not asking it to become the default, I just would like such an init system to be available on BSD at the administrator’s choice. (which would be my case)
This is a great result for what it seems to be a one-man project.
Interesting – I find BSDs appealing and use them because of a lack of choice. The whole system is “curated”, all the parts fit together. I have to check manpages to know
apacheuses-tto check its config file whereashaproxyuses-c, but if I userelaydandhttpdI use the same flag that I use forpfctland other builtins.So for me, the fact that “there’s one way to do it” is quite appealing!
In my experience, BSD is more curated than Linux, but I wouldn’t say it follows the “there is only one way to do it” principle. For example, on both FreeBSD and NetBSD, there is more than one firewall included by default (pf, ipfilter, npf etc.), and the administrator can generally choose whichever he prefers.
I replaced the FreeBSD’s rc.d with daemontools 15 years ago. It was just a port at the time (not sure if it still is), and it’s something that’s been possible for a long time if you’re willing to put a bit of effort in it.
Fairly sure you can also do it on OpenBSD etc.
I’m a staunch systemd detractor. I support this project; it’s nice to have options!
It’s nice to see supervisor inits making their way into BSD; I wonder how it works with the license? surely a fork is GPL’d? Thus it could never be shipped by default.
I’m glad they didn’t take the journal format, but I wonder if they could take inspiration from Solaris SMF, in that the supervisor init tracks the log file (or can output STDERR/STDOUT on behalf of the process to a log file).
My anti-systemd views:
Contrary to those who wish to misrepresent “systemd haters”: I (and I suspect many others) don’t actually hate many of the concepts behind systemd.
I dislike systemd because it is difficult to debug, rolled a lot of it’s own reimplementations of things in difficult to debug ways (let’s do DNS over DBUS!) and claims to be modular while having tight integration to things making it an all-or-nothing deployment in most circumstances.
I dislike systemd because it removes the possibility of something better coming along later, because any potential reimplementations of an init will need to be a very large codebase and have to emulate quirks and odd-behaviours of systemd.
Considering that init scripts are also difficult to debug, this is just a sidegrade at worst.
OpenBSD’s init scripts are quite a bit simpler than the tangled mess that was the norm on linux (Slackware being the notable exception). They’re almost nonexistent compared to systemd.
For example, here’s a typical openbsd init script:
There’s about 300 lines of support code in rc.subr, mostly around parsing the command line arguments:
https://cvsweb.openbsd.org/src/etc/rc.d/rc.subr?rev=1.136&content-type=text/x-cvsweb-markup
I could post the entire openbsd init system in this one comment – it doesn’t hit the size limit. I won’t, because it’s just a bit antisocial to paste a wall of text just to prove a point.
init scripts have a great deal more determinism and a radically smaller set of moving pieces.
It’s not like SysV init and systemd are the only two options.
I actually really dislike SysV init, always have. OpenRC is the worst part of Alpine by far. But at least I can debug them. If I run in to an issue with systemd … there’s basically no chance I can debug it.
Here’s an actual systemd issue I ran in to, and here’s the patch to fix it. There is no way I would have been able to figure this out without at least a full day of work, if not more.
Systemd is worse to debug though. It’s compiled & has a non-deterministic dependency graph.
I agree somewhat that bash is intimidating but it’s not compiled and is definitely easier than C for new users; but a few things stand out:
Your comment is a false dichotomy because there already existed inits which do not use shellscripts at all (runit, SMF)
you don’t have to use bash at all, you could invoke any interpreter, Perl/Python/Ruby (I have done this)
bash -xcan be used if you’re stuckyou can modify many behaviours as a user, how easy is it to modify systemd? There are things which are easy, but a lot of things are quite a bit harder. (Arguments against HCL/Yaml for systems management apply in their entirety here).
And anyway this is arguing about the init again, and there are some good ideas. My main gripe about the init is that it positions itself in a place that’s hard to replace and that it is more difficult to debug for power users.
My larger issues surround systemd as an ecosystem.
I’m a bit confused about…well, honestly, most of your points.
bash -xcan be used if you’re stuck only if the scripts involved do something more thanexec /sbin/foo -a -b -c, and that (well, along with something likechpst) is often all there is to such a shell script, anywayI have a very complicated, at best ultimately neutral, attitude towards systemd, but I’d like to make sure we’re all on the same page about what systemd does and does not do, and how it does and does not work, so the discussion is actually valid.
I think the simple answer here is that you can’t even do conditionals with the .ini file format.
runit can run shell scripts, or you can just call a command to run. It’s supervised so you don’t have to care about forking/logging
if
exec /sbin/foois what is failing you can run it in runlevel 3 and get a pretty error message.Trivially: checking that the environment is sane before running commands. There are still systemd units which call bash scripts because you don’t want to clobber data in some situations. Starting PostgreSQL for the first time for example if the datadir is empty or scanning for LVM volumes properly before mounting gets easier if you control it.
Like I keep saying, systemd the init has parts that beat out bash for sure, it’s easier as a user until it breaks, when it breaks you’re hopelessly fucked though (and I lived through the early days of systemd on fedora so I’m aware of just how fucked you can be).
It’s interesting that I this thread has become a defence of bash when really I don’t hold much love for bash; and this is what most people who like systemd prefer to talk about too… I don’t hate systemd because it is not Turing complete or that it’s not bash or whatever… What I do hate about systemd for is the almost closed off ecosystem due to tight integrations, the fact that it’s default everywhere and in some cases can’t even be removed and lastly the awful code/attitude of the project generally.
You can’t tell me that it’s “as debuggable” or that anything you’ve said isn’t a false equivalence, for instance if you’re decrying “exec” as being obtuse and undebuggable then systemd only does that anyway!
(Obligatory disclaimer: I’m not a systemd “fan”, but I use it and like some of the features. This ain’t an anti-systemd rant :-D).
An example from a while ago. I worked on a tiny gizmo that ran Linux. Yocto, being the
steaming pile of shquirky array of tools that it is, generated some weird image that systemd-fsck really wanted to fsck each time, for some mysterious reason.This was early at boot time, and systemd-fsck provided pretty much no diagnostic info at all at the time (I don’t know if it’s changed in the meantime).
How do you debug this?
The best I could figure out was to get a custom systemd build up and debug it by printf, pretty much the way I’d have done it if it were all shell scripts, except with an extra, and pretty lengthy compile, generate image, burn to flash cycle in-between. If it were all shell scripts, I could’ve at least done it on-device.
I’m not saying this single incident would justify returning to shell scripts, that’s really not the case. It’s just an example of something that’s now a little harder to debug than before.
Depends on the OS, the BSD’s all use similar rc.d frameworks for their init scripts, so they’re almost always declarative and fairly trivial to debug with standard unix utilities.
Should be merged into
jx3cr6.My thoughts:
Perhaps this is because Linux offers functionality that is useful for developers, and the lowest common denominator is no longer adequate.
FreeBSD users and devs seem to think that people who don’t use or develop for FreeBSD only do so because they haven’t heard of and used FreeBSD. The fact that some smart people have looked at FreeBSD and said “Nah” doesn’t seem to occur to them
To be kinder, I actually like FreeBSD (it’s more “tasteful” than the average Linux distribution), but the reality is baseline POSIX is anemic for a modern application outside of the typical 90s Unix model, and no one really wants to catch up and standardize modern functionality (or shared common functionality). Especially when it comes to distribution/isolation.
I brought it before, but it’s a lot of wasted potential; FreeBSD’s biggest fans seem to ignore if not revile its most interesting aspects. They were first to the punch with jails - they could have led a container revolution. Instead, the tooling was painful and the rest of the world uses Docker instead.
I kinda like FreeBSD. It’s very simple, and 20 years of UNIX administration really pays off, BUT.
The rough edges on it really rub me the wrong way. I know that there’s an easier way to do most of the things FreeBSD makes really hard, and the documentation can be really inconsistent and years out of date, with no indication that there might be a newer, better way of solving some problem that somebody has come up with since the documentation was written (see LDAP authentication for a good example of that).
Yes, pkg is another papercut factory. I’d like pkg base, but that’s also predicated on pkg catching up to i.e. apk. Hope you don’t mix ports and packages!
I’ve also found the lauded Handbook slightly lacking.
Interesting. It even aims to support Linux. Will this be the new go-to option for Linux distributions who specifically want to avoid systemd? In fact, I always wondered why nobody came up with the idea yet to simply support
.servicefiles in other init systems like OpenRC.No, there’s no point in replacing systemd with a forked systemd. All the actual issues remain.
This is an interesting project, but being perfectly happy with the OpenBSD init system right now, I see no reasons to try systemd on OpenBSD.. in fact, I see a lot of reasons not to, unless I had a very specific use case.