-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
A lot of those things don't use plain bash either... Of that bigger things in that list:
There is OpenWRT, which uses "procd" (a process management daemon written in C, like systemd but smaller) with its own system bus ubus (like dbus but smaller)
There is Android with its own proprietary init system.
And many others use OpenRC, which is 65% C and 30% shell (according to github). the init files do use shell syntax, but you are supposed to use their interpreter [0] "if you insist on using #!/bin/sh you're on your own" [0]. In fact, the recommended approach is declarative method when you specify name of main binary and their args.. just like systemd.
The world is moving and sysvinit is left behind.
[0] https://github.com/OpenRC/openrc/blob/master/service-script-...
> Well you have to start fiddling with iptables and descend into that level of hell wherein you are fundamentally fiddling with stuff you do not want to fiddle with, and beside that solution is going to be system wide.
This is just a really strange and depressing-to-hear stance, as you seem to simultaneously be claiming that it is worthwhile to read the documentation for systemd to learn about all of its one-off solutions but somehow NOT worthwhile to read the documentation for the actual Linux IP stack?
> systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere.
Honestly, this just sounds horrible... this sounds like a project that has a million tiny one-off "simple solutions" to individual "challenging problems" instead of providing a generic tool that can be integrated with other generic tools to solve arbitrary problems in infinite combinations.
> systemd is a beautiful, integrated work of art, and there's constant payoffs and benefits from the fact that it encompasses so much functionality previously split across a huge range of inconsistent small solutions to the various problems systemd solves.
And so like, here is just where I guess there's a philosophy problem at play: those "inconsistent" solutions were just combinations of separate components. To me, that's beautiful... and it's beautiful, in no small part, because it was NOT "integrated", and was instead extensible and transparent.
> If Linux had started off with systemd and someone came along and said "better idea, lets tear systemd apart into a wide range of tiny applications all with different approaches, syntaxes, maintainers and functionality, with no overarching architecural approach and call it sysV", everyone would say "what a crazy idea, no thanks."
Really? You seriously don't see any benefit to taking a monolithic framework and breaking it apart into a ton of libraries? Yes: there are people out there who like the large monolithic opinionated frameworks... but there are also a lot of people who prefer having a toolkit of libraries.
In particular, when we see this debate show up in other places, a big benefit of the "lots of libraries" approach is that it is an inclusive and extensible way of approaching a complex problem, where if you have an idea that you think makes the world better you can just work on that part.
And so when someone is working on new network addressing or new ways of doing hypervisor-assisted sandboxing or new ways of managing user accounts, some of us would like to think that the mechanism for "run a bunch of stuff when the system boots" doesn't have to understand any of that.
When you have a single program that has decided to form a giant knot in the space of solutions--where to solve anything you feel like you can't just add another library but you have to go modify the big central framework--you stifle a lot of participation and narrow the set of options.
And that's where I feel like you are just going to say "that's great! I don't like options! I'd prefer someone else not only solve my problems but tell me what my problems are in the first place" and again: that's where this becomes a big philosophical argument instead of a technical one.
So like, do I have technical issues with systemd? I mean, yes: I'm sick of being burned by this "journald" issue--one which has been open over a decade now and will probably never get fixed--because as far as I'm concerned if you build a logging system and you routinely lose log messages you probably aren't qualified to develop a logging system.
https://github.com/systemd/systemd/issues/2913
https://bugs.freedesktop.org/show_bug.cgi?id=50184
But, at the end of the day, the reason that systemd makes me sad is because when I started doing system administration the entire community was firmly in the "we should strive to have a lot of separate tools that can be composed in fun ways" camp, and now it seems like the reins have been taken by the "you shouldn't know or care how things are put together: let me solve it for you" camp, and that makes me nigh-unto existentially sad about the state of computing. :(
(And like, I want to be clear: normally, I just don't care that much?... I went into my past HN comments to find the link to that journald issue, and it seems like meekly asking after that specific bug is the only time I've ever even commented about systemd... I've always just figured it's yet another annoying change that maybe I'll have to get used to, from the ever-increasing essential complexity people like to foist on us every year; but then I see your comment here, and it is just SO SAD to see that it seems like you don't even consider it a depressing tradeoff but seem to actually WANT IT and I'm just like "ugh".)