Earlier quoted context omitted.
I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions…
> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script I never really understood this point — it’s not some proprietary format that has to be reverse engineered, you quite literally has both encrypt and decrypt source code available for every single version it has been released. You can also just pipe the binary output through the…
Systemd 252
221–230 of 317 posts
Re: Systemd 252
#222Earlier quoted context omitted.
What does canonical log even means here? Systemd will produce logs in its own structured representation and write them straight away as plain text in the logger of your choice. For all intent and purpose, you now have text logs.
What I meant by "canonical" is that you can't get rid of the binary log; you can pipe it into a database, or a textfile, or /dev/null, if you want, but that database or textfile is transcoded copy of the binary log.
Re: Systemd 252
#223About removing support for what they call split-usr and unmerged-usr: Why does a init system and daemon manager even need suppport for a certain directory layout, shouldn't it be agnostic? Having a separate usr-space saved my bacon in the past a couple of times. The thing I dislike most about Systemd is that it leads to homogenisation, where to me, running Linux is about choice.
>where to me, running Linux is about choice.
Quote :
"From: Adam Jackson To: Development discussions related to Fedora Subject: Linux is not about choice [was Re: Fedora too cutting edge?] Date: Wed, 09 Jan 2008 15:58:45 -0500
> Linux is about choice.
If I could only have one thing this year, it would be to eliminate that meme from the collective consciousness. It is a disease. It strangles the mind and ensures you can never change anything ever because someone somewhere has OCD'd their environment exactly how they like it and how dare you change it on them you're so mean and next time I have friends over for Buffy night you're not invited mom he's sitting on my side again.
As a consumer, yes, you have lots of choices in which Linux you use. This does not mean Linux is in any sense _about_ choice, any more than because there are so many kinds of cars you can buy that cars are about choice.
The complaints up-thread about juju and pulse are entirely valid, but the solution is not to try to deliver two things at once. If you try to deliver both at once you have to also deliver a way of switching between the two. Now you have three moving parts instead of one, which means the failure rate has gone up by a factor of _six_ (three parts, and three interactions). We have essentially already posited that we have insufficient developer effort to have 100%-complete features at ship time, so asking them to take on six times the failure rate when they're already overburdened is just madness. Alternatively, we could say that we're integrating features too rapidly, but you do that at the expense of goal 1, to be the showcase for the latest and greatest in free software.
Software is hard. The way to fix it is to fix it, not sweep it under the rug.
There is a legitimate discussion to be had about where and how we draw the line for feature inclusion, about how we increase and formalize our testing efforts, and about how we develop and deploy spike solutions for corner-case problems like the one device class that juju happens to do worse than the old stack. But the chain of logic from "Linux is about choice" to "ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster.
- ajax "
Re: Systemd 252
#224Living without systemd is sometimes a rough choice at the moment but I think it can be polished.
Re: Systemd 252
#225Earlier quoted context omitted.
What does canonical log even means here? Systemd will produce logs in its own structured representation and write them straight away as plain text in the logger of your choice. For all intent and purpose, you now have text logs.
What I meant by "canonical" is that you can't get rid of the binary log; you can pipe it into a database, or a textfile, or /dev/null, if you want, but that database or textfile is transcoded copy of the binary log.
Seems like a pointless complain to me. It’s arguing for the sake of it.
Re: Systemd 252
#226Earlier quoted context omitted.
But then you should only get the users account as shell, so while this is a neat trick, being able to gain persistent root if you are already root is not that hard.
It was part of the contest that your enemy team is not able to detect and remove your backdoor. The obscurity of systemd sockets was my winning move.
Re: Systemd 252
#227Earlier quoted context omitted.
> There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft. I only learned about that a few days ago, here on HN (some thread or some old comment). It is completely insane and gives lots of fuel to the systemd haters. I do run both Debian (systemd) and Devuan (a Debian fork with all the systemd stuff…
> and there should be Linux distros packaged without systemd. systemd should be an optional package on all distros. Shoving it down throats is one of the valid major criticisms. What should have happened instead is systemd was optional on Debian at setup and Debian was forked to include it by default. It is simply backwards that Debian needed to be forked for purity. Duvuan shouldn't need to exist, but it very much d…
Human systems tend to flourish when political and economic decision-making is relatively distributed throughout a given population. I believe this position is backed by a reasonable amount of empirical observation.
Machines are (as of this writing) programmed by humans. Unlike humans, machines are automated rule-followers. This is substantively different from decision-making, which is a uniquely human trait involving moral agency, free will, etc. (at least as I'm defining it for the purposes of my argument). If you try to turn humans into automated rule-followers by decree, they tend to become miserable. Fortunately, one does not have to take into account how machines feel about being absolved of all decision-making, making such control systems very effective (you don't have to kill / imprison the dissenters). But even though the machines might be more effectively programmed by a centralized, unified, top-down, "authoritarian" control architecture, you still need humans to build this controller. And since we know software projects end up mirroring the communication structure of the humans in charge of building them, it follows that authoritarian-minded software engineers would be a best fit for building such systems.
The converse is that libertarian-minded software engineers tend to recoil in horror when they encounter authoritarian software design, no matter how unified, elegant, or effective it may be. Such things are a moral transgression to the libertarian.
Re: Systemd 252
#228Earlier quoted context omitted.
What I meant by "canonical" is that you can't get rid of the binary log; you can pipe it into a database, or a textfile, or /dev/null, if you want, but that database or textfile is transcoded copy of the binary log.
Every log ever is a transcodification of a system state. What difference does it actually make that it is emitted into systemd structured format before being put into your logger? Seems like a pointless complain to me. It’s arguing for the sake of it.
Re: Systemd 252
#229Earlier quoted context omitted.
What I meant by "canonical" is that you can't get rid of the binary log; you can pipe it into a database, or a textfile, or /dev/null, if you want, but that database or textfile is transcoded copy of the binary log.
That's not true, you can configure journald to be in-memory only in which case there's no binary log, no file. If your using systems, you can't really git rid of journald, but you can get rid of the binary logs.
Re: Systemd 252
#230Earlier quoted context omitted.
I mean it's pretty hard to debate the merits of systemd as a server init system when you think we should all be using come kind of containerization system :p
I did not say anything about containers.