46 ms·

I have used systemd only as one of the data points in overall state of the industry, please read my initial post. It is important point for me because I used to

I have used systemd only as one of the data points in overall state of the industry, please read my initial post. It is important point for me because I used to use Linux everywhere and rely on its modularity and security. I am looking at the big picture and how trends correlate, not particularly focused on systemd only. Rest of the conversation emerged because 'silent majority' (lol) focused on systemd only. You are aware of the feature creep and taking over of every sane unix/linux utility? Usually with very questionable results, changing su or dns resolver, for the worse? You know about number of vulnerabilities that are introduced by systemd, then dismissed and not-our-bug or wontfix? You are aware of the tying in systemd with every other program they can get their hands on? That makes harder and harder to run properly secured machine that does not have systemd. Not saying to you since you know system administration but: This is a BAD thing. You probably know about all vulnerabilities introduced by systemd? Coupled with inability to not use systemd, with its huge attack surface this makes Linux much less secure and monolith. Back to my initial intention: there is huge trend throughout the industry that kills variety and ties in systems in a monolith mess. Systemd is just one of the data points. I care same way about Oracle buying Sun with one of the main reasons being MySQL. Thanks to MariaDB folks that lock in didn't happen but I was aware they will try it as soon as Oracle got hands on MySQL.

merb 9y ago
> You probably know about all vulnerabilities introduced by systemd? You probably know about all vulnerabilities introduced by openrc or sysvinit? Right you can't since every script itself could have a vulnerability
- binaryapparatus 9y ago
  No need since I can choose what I start, in what order, and I can check every simple script myself. They were short and doing one thing well. Good luck doing that with 300+K lines of code with systemd. Arguments like this really don't help systemd and show either ignorance or worse.
  - kuschku 9y ago
    I’ve got 1400 init scripts my systems, each over 800 lines long, before I switched to systemd And in a language without linters or typecheckers. It’s literally easier to read the entire systemd code than trying to debug the interactions between these init scripts, all slightly buggy, interacting in slightly unexpected ways, and working mostly, although they never should.
    - binaryapparatus 9y ago
      > I’ve got 1400 init scripts my systems, each over 800 lines long, before I switched to systemd There is something wrong with those numbers. Can you upload them somewhere or let me know what distro it was? I am curious to take a look. If there is 1400 of them, each over 800 lines long then you have 1.1M lines of init script code, which doesn't seem right. How many of them did you use daily? All 1400? 5? 10? Because checking sanity of ten of them, even if they are whooping 800+ lines of code (I'll have to see that) can't be compared to over 300K lines of monolithic systemd.
      - kuschku 9y ago
        > How many of them did you use daily? All 1400? 5? 10? Because checking sanity of ten of them, even if they are whooping 800+ lines of code (I'll have to see that) can't be compared to over 300K lines of monolithic systemd. All of them, it was over several servers, running different distros, with similar services, all with similar but slightly different init scripts for the same packages, and all having to interoperate. All scripts from the distro’s packages. All of them were running daily, and many of them were constantly causing issues. In fact, I have a single sysvinit script left on my systems, and it’s exactly that one that doesn’t work reliably.

merb 9y ago

> You probably know about all vulnerabilities introduced by systemd? You probably know about all vulnerabilities introduced by openrc or sysvinit? Right you can't since every script itself could have a vulnerability

binaryapparatus 9y ago
No need since I can choose what I start, in what order, and I can check every simple script myself. They were short and doing one thing well. Good luck doing that with 300+K lines of code with systemd. Arguments like this really don't help systemd and show either ignorance or worse.
- kuschku 9y ago
  I’ve got 1400 init scripts my systems, each over 800 lines long, before I switched to systemd And in a language without linters or typecheckers. It’s literally easier to read the entire systemd code than trying to debug the interactions between these init scripts, all slightly buggy, interacting in slightly unexpected ways, and working mostly, although they never should.
  - binaryapparatus 9y ago
    > I’ve got 1400 init scripts my systems, each over 800 lines long, before I switched to systemd There is something wrong with those numbers. Can you upload them somewhere or let me know what distro it was? I am curious to take a look. If there is 1400 of them, each over 800 lines long then you have 1.1M lines of init script code, which doesn't seem right. How many of them did you use daily? All 1400? 5? 10? Because checking sanity of ten of them, even if they are whooping 800+ lines of code (I'll have to see that) can't be compared to over 300K lines of monolithic systemd.
    - kuschku 9y ago
      > How many of them did you use daily? All 1400? 5? 10? Because checking sanity of ten of them, even if they are whooping 800+ lines of code (I'll have to see that) can't be compared to over 300K lines of monolithic systemd. All of them, it was over several servers, running different distros, with similar services, all with similar but slightly different init scripts for the same packages, and all having to interoperate. All scripts from the distro’s packages. All of them were running daily, and many of them were constantly causing issues. In fact, I have a single sysvinit script left on my systems, and it’s exactly that one that doesn’t work reliably.