4 ms·

Most of the arguments are theoretical or probabilistic. It's true that more code means more places for bugs to hide. It's also true that systemd and it's fans

Most of the arguments are theoretical or probabilistic. It's true that more code means more places for bugs to hide. It's also true that systemd and it's fans(myself included) don't really care about init freedom. Obviously, no self respecting FOSSer is going to sabotage alternatives actively, but we don't use or know the alternatives, so there could be subtle bugs. But systemd does work. It's not what I would call buggy. It doesn't appear to impede performance. And very consistently, whenever I think "Oh, how do I do X", there's a clean and purely declarative way to do it, that hooks into all the logging and monitoring perfectly. Systemd goes a long way to making Linux work like an OS, rather than a build-an-os kit. The people who are against it tend to be very security conscious. Not "I use 2FA" conscious, but "I will wholesale refuse to visit a popular site that I believe is selling my telemetry data" level. A lot of the others are enthusiasts. They want to control and understand the machines they own, and don't want any black boxes, and they are almost as grossed out by anything "overkill" as most people are by a drawer of urine. They don't care if it's tucked away, they don't like it being there and don't trust it, no matter how well it performs who who did a 3rd party audit. Systemd seems highly inappropriate for people who really like the old Linux modular kit approach, or anyone who doesn't like big things. But the majority of big corporate and average home users seem to love it, and I wouldn't want a distro without it. The arguments against it are valid, but usually only if you share the same values they tend to be based on.

cykros 4y ago
It's existence as an alternative for those who want it doesn't bother me so much. It's watching other projects that existed for years without relying on it tacking it on as a dependency that got worrisome. It DOESN'T particularly follow the Unix philosophy, but that's okay -- not everything needs to be Unix. At the end of the day, things seem to have washed out over the past few years, and folks who want to run systems without it seem relatively unimpeded at this point (heck, my Bluetooth stack on Slackware 15 worked out of the box). As long as the anti-systemd crowd keeps things constructive with parallel structures, the future seems bright. And if the systemd proliferation brings users and thus big company driver support, so much the better. I just hope it is done in a way that the benefits can be shared in an init-system agnostic sort of way where possible.
deknos 4y ago
> Obviously, no self respecting FOSSer is going to sabotage alternatives actively, is that so? i do not have the same impression. everything is now built depending on systemd. i worry about that sometimes, though i also prefer systemd.. therefore i have hope for initware which/who want to export some of the stuff to other systems. also i worked with environments (embedded and also router "things"), where systemd is indeed overblown... but that are nisches. i just hope we do not overcomplicate things for the nisches.. 80% or more (but less then 96%) profit from systemd. back then unix and opensource managed all the cases, today it looks like it only manages the maincases..
naikrovek 4y ago
> or anyone who doesn't like big things. There is definitely a significant lack of allergy to complexity among today’s software developers. Complexity is very bad, and it is usually not necessary. Lots of things that people write today are FAR more complex than necessary for no reason other than “best practice”. Need to instantiate an object? Better have an AbstractObjectFactory, an IObjectFactory, an ObjectFactoryImpl, an ObjectFactory, and an ObjectBean or you will not make it through code review! There is no room for simplicity in today’s software development world, no matter what language you use, unless you are ready to spend lots of time every single day explaining yourself. It’s sad.
- kaba0 4y ago
  Outside of some 1-2 decades old frameworks, can you show me a singular example for any of your ObjectFactories? Because I really think that the field as a whole moved a bit away from such deep object hierarchies and even in OOP circles will try to use as few levels as possible. Also, don’t forget that complexity can be divided into two categories: essential and accidental complexity. The former can’t be decreased at all. We should strive to minimize the latter of course, but we often forget about the first. Just to be a bit more relevant - system boot is a very complex task, so the first type of complexity will be plentyful. It is basically a service/hardware dependency-graph. Sure, you can hard-code singular cases (previous init systems basically did that) but hardware and services are sufficiently different to not make it that feasible, and every single hard coded version can be buggy. A declarative approach is much saner and it is no accident that basically every OS in wide use switched to that.
  - Tainnor 4y ago
    It's definitely gotten better but there's still questionable overabstraction in certain standard libraries and/or popular frameworks (such as Spring). For example, in Java, to create a Trust Manager for certificates, you have to first call a factory method to get a TrustManagerFactory, before I can even get a TrustManager: https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/TrustManagerFactory.html#getInstance(java.lang.String) https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/Trus... That's just really weird and confusing design.

cykros 4y ago

It's existence as an alternative for those who want it doesn't bother me so much. It's watching other projects that existed for years without relying on it tacking it on as a dependency that got worrisome. It DOESN'T particularly follow the Unix philosophy, but that's okay -- not everything needs to be Unix. At the end of the day, things seem to have washed out over the past few years, and folks who want to run systems without it seem relatively unimpeded at this point (heck, my Bluetooth stack on Slackware 15 worked out of the box). As long as the anti-systemd crowd keeps things constructive with parallel structures, the future seems bright. And if the systemd proliferation brings users and thus big company driver support, so much the better. I just hope it is done in a way that the benefits can be shared in an init-system agnostic sort of way where possible.

deknos 4y ago

> Obviously, no self respecting FOSSer is going to sabotage alternatives actively, is that so? i do not have the same impression. everything is now built depending on systemd. i worry about that sometimes, though i also prefer systemd.. therefore i have hope for initware which/who want to export some of the stuff to other systems. also i worked with environments (embedded and also router "things"), where systemd is indeed overblown... but that are nisches. i just hope we do not overcomplicate things for the nisches.. 80% or more (but less then 96%) profit from systemd. back then unix and opensource managed all the cases, today it looks like it only manages the maincases..

naikrovek 4y ago

> or anyone who doesn't like big things. There is definitely a significant lack of allergy to complexity among today’s software developers. Complexity is very bad, and it is usually not necessary. Lots of things that people write today are FAR more complex than necessary for no reason other than “best practice”. Need to instantiate an object? Better have an AbstractObjectFactory, an IObjectFactory, an ObjectFactoryImpl, an ObjectFactory, and an ObjectBean or you will not make it through code review! There is no room for simplicity in today’s software development world, no matter what language you use, unless you are ready to spend lots of time every single day explaining yourself. It’s sad.

kaba0 4y ago
Outside of some 1-2 decades old frameworks, can you show me a singular example for any of your ObjectFactories? Because I really think that the field as a whole moved a bit away from such deep object hierarchies and even in OOP circles will try to use as few levels as possible. Also, don’t forget that complexity can be divided into two categories: essential and accidental complexity. The former can’t be decreased at all. We should strive to minimize the latter of course, but we often forget about the first. Just to be a bit more relevant - system boot is a very complex task, so the first type of complexity will be plentyful. It is basically a service/hardware dependency-graph. Sure, you can hard-code singular cases (previous init systems basically did that) but hardware and services are sufficiently different to not make it that feasible, and every single hard coded version can be buggy. A declarative approach is much saner and it is no accident that basically every OS in wide use switched to that.
- Tainnor 4y ago
  It's definitely gotten better but there's still questionable overabstraction in certain standard libraries and/or popular frameworks (such as Spring). For example, in Java, to create a Trust Manager for certificates, you have to first call a factory method to get a TrustManagerFactory, before I can even get a TrustManager: https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/TrustManagerFactory.html#getInstance(java.lang.String) https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/Trus... That's just really weird and confusing design.