131–140 of 191 posts
I wish voidlinux gained more attention from the community and got adapted to serious production stuff. It has all the good elements on paper except the maturity and user base.
What are the benefits of void in production compared to Alpine?
Earlier quoted context omitted.
That's just saying "I want things to be the way I first learnt them and don't want them to change." This is fine, but you do have to accept that things are going to move on without you.
No, that's saying I want things that stick to the Unix philosophy of simplicity, clarity and text formats with no hidden magic.
I wish voidlinux gained more attention from the community and got adapted to serious production stuff. It has all the good elements on paper except the maturity and user base.
What are the benefits of void in production compared to Alpine?
The one benefit would probably providing a glibc version if you require it.
(I'm a Void Linux contributor.)
Earlier quoted context omitted.
> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.
Many simple systems don't do parallel service startup like systemd, if that is what you mean.
I see a lot of hate about systems and I used to loathe it too. Then I took a course on systemd specifically and it opened my eyes, and now I'm quite fond about it. Systemd actually does ONE thing and does it well: it manages the system. It's the missing layer between kernel space and user space. It has quirks and bugs like all software, but I think it works very well, all things considered. To those who say that it's…
Earlier quoted context omitted.
> nobody of the anti-systemd folk was willing to pick up the work needed to maintain consolekit Why would I want to start working on software I don't use or need? Why do systemd advocates always insist that every implementation must include the features they think are important? The entire point of designing for modularity is that different people have different requirements; operating systems cannot be "one size fit…
> Why would I want to start working on software I don't use or need? Why do systemd advocates always insist that every implementation must include the features they think are important? If you don't care about multi-user session management, sure, but considering practically every window manager/DE relied on consolekit and now logind to provide that functionality, I find it hard to believe it's not desirable by a larg…
The constant misrepresentation and/or refusal to address the actual "anti-systemd" complaints by systemd advocates is also rather annoying.
> makes me suspicious as to whether they did more than have a knee-jerk reaction to a tool that is different than what they used before.
Resorting to accusations of incompetence only add toxicity to the discussion. You'll have to take my word for it, but I assure you I know what I'm talking about.
> but considering practically every window manager/DE relied on consolekit
Mine doesn't. Some of the special-purpose computer's I used to use didn't use a window manager. These may be uncommon use cases; so what? They solve the problems they are supposed to solve without any unnecessary overhead.
> I find it hard to believe it's not desirable by a large majority of users
So only popular need should be supported? The entire point I'm making is that there are many different reasons people use computers, including many that are unique or almost unique. I may use an older window manager, others might prefer to use consolekit or logind, someone else could be interested in developing a totally new post-window-manager design that doesn't even use metaphors like "desktop", "windows", "sessions", etc. All I'm arguing for is the freedom choose any of those options, which includes variations where consolekit isn't used even if it is used in popular configurations.
The alternative is to argue that one design must be used everywhere, even when it is inappropriate or unwanted.
> in my experience, the bash scripts always ended up being a hot mess
I disagree, but you're welcome to your own opinion. If other software works better for you, then great, use it. I'm not trying to convince you to write bash scripts; I'm trying to explain why a single "one size fits all" design isn't possible, because we may be trying to solve different problems or prefer different tools. If systemd wasn't tightly cou0led and instead played nice with the rest of the systemj, we simply replace parts of it when necessary and we wouldn't be having his argument.
> Not to mention that none of the alternatives give me the functionality I want
Which is why I want you to have the freedom to use the tools you prefer to use, even systemd. Shouldn't other people have the freedom to made different choices?
Earlier quoted context omitted.
systemd is a perfectly fine init system. The problem is that it comes bundled with a whole bunch of other tools for handling networks, cron, ntp, etc which really ought to be separate projects. By bundling them with the successful init system they're not exposed to the usual Darwinian selection processes that shake out the best free software.
Honestly, I much prefer systemd timers over cron. They work just like systemd units and shed all the odd special cases that cron accumulated over the years. They’re pretty well defined in how they behave in face of systems being down while a job was supposed to run (more a desktop thing, but relevant for some server cases as well). It makes sense to use the same config mechanism. Still, systemd timers are exposed to…
Earlier quoted context omitted.
Many simple systems don't do parallel service startup like systemd, if that is what you mean.
Sure, but doesn't that also make them slower?
My favorite part is OpenRC still likes the old ways, has script extensions for new ways, and runs the same path every time.
The fact that we're still having _this_ conversation, after after a decade since being released and years after mass adoption, should say a lot. I can't think of any other software I have to use on a daily basis that gets so much heat, every time it comes up. One can make all the arguments for it they want but the continued public comtempt means something.
> One can make all the arguments for it they want but the continued public comtempt means something. It means that Linux community is full of people that refuse to give up on their gripes even after years. Those also tend to be the people who refuse to understand that "the old way" might not be the best way to do something and also fail to produce a viable alternative. Linux audio was not usable for end users until P…