> You can easily have it not produce binary logs. How do you do that? If you want non-binary logs, you can have journald tee log records to rsyslog; but the canonical log is still the binary log. Have I missed something?
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.
> It is completely insane and gives lots of fuel to the systemd haters. Sorry, what exactly is the issue with a bunch of Linux maintainers working for Microsoft? Is there still some sort of collective adjustment issue with Microsoft being a major backer of Linux now? If the maintainers themselves (people who have dedicated their lives to progressing Linux) are ok with it, why does anyone else have an issue? And what…
And what kind of fuel would it add? That systemd has corporate backers? Systemd was 100% created by redhat, so no, corporate backers aren't the problem. The real problem is that Microsoft has historically tried to destroy linux, and beyond that, has a huge history of FUD and embrace and extinguish. Many in the OSS community consider Microsoft to be pure evil. And if their historical behaviour is any indication, nothi…
I totally get it – I've watched it all unfold over the last couple of decades.
But everything I see since Nadella has taken over, tells me that they aren't just paying lip service, that they have just realized nearly a decade ago that it's good business to embrace (loaded word) Linux if they have any chance for Azure to succeed, and their moves suggest that's a core part of their future.
I wish Windows ran systemd--seriously. Windows services and low level functionality is just a hot mess of cruft, decade plus old UI and configs, etc. Please jettison it all and give a consistent declarative way to manage it all like systemd does for Linux.
You can run virtually any Windows application on top of Systemd already via Wine. Unless you have some particular attachment to the NT kernel, there near zero reasons to use Windows today.
If only that were true. "Virtually any Windows application" is a fantasy I'm afraid, many important applications run poorly or not at all on Linux. Then there's the "particular attachment to the NT kernel" caused by driver support for $HARDWARE - there's tons of niche hardware that just can't be driven from Linux.
If you use a computer for actual industrial work, you will hit one of these problems very quickly.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/n... blocks SIGHUP and captures output in a file. That lets me type nohup ./long_batch_job.sh & and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost. systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end use…
They broke tmux too: https://superuser.com/questions/1372963/how-do-i-keep-system... Systemd does a lot of good but they like to move fast and break things. Making tmpdir per process, their homedir changes etc are all good for security but tend to break things in unexpected ways
They've never done tmpdir per process... There's a PrivateTmp option for services, but that has to be enabled explicitly
> 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…
The primary definition of fascism, according to the Merriam Webster dictionary, is this: > a political philosophy, movement, or regime (such as that of the Fascisti) that exalts nation and often race above the individual and that stands for a centralized autocratic government headed by a dictatorial leader, severe economic and social regimentation, and forcible suppression of opposition systemd has nothing to do with…
Thank you, and a worthy attempt, but as you have defined Fascism, the political movement and a noun and proper name, as opposed to the adjective fascist, as in advocation of an authoritarian regime and in opposition of and intolerant of opposing views, and in modern definitions, a synonym of "bullying," your post is somewhat of a straw man. Obviously I was not suggesting that systemd was literally Nazi software. What I was saying is that systemd, as an unnecessarily complex machine in itself as it proceeds to annex other parts of the system, is autocratic, strongly regimented and centralized, suppresses opposition, and subordinates individual interests.
It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend. How long until “Systemd: The Good Parts”? *The most trivial new name would be système which would at least be in keeping with the French naming. **In Debian stable if you create a new user, ssh in as that user, logout, then delete th…
Wait, what French naming?
"e" following "d" in the alphabet, the successor to systemd would be called "systeme", which is the french translation (système) for "system".
It's zero downtime in that at no point does the kernel not respond to a TCP SYN packet and all those connections eventually get seen by the daemon. (Really useful for updating local services on Unix sockets.) It's also much simpler than redundant instances, and applications are updated much more commonly than hardware failures so it's a cheap way to increase availability in practice. And if your app can restart in a…
I believe that if a webpage (for example) doesn't download all resources, and be fully responsive in under 100ms, there is an issue. So maybe you think I have issues in general.
Using a server language with GC will break that.
Using any kind of network that isn't hardwired to the server will break that. (Cellular, WiFi, roommate starts downloading an update over DSL, etc)
Even just having other services on the server spike in usage can break that.
Also I'm talking about "100% of requests finish in 100ms", which is damn near impossible, vs "99.9% of requests finish in 100ms", which is very doable and having a couple seconds a day you don't respond isn't going to break that.
The arrogance of Lennart has something to do with it. The way he tends to disregard real bugs as not a bug, since he and his production are perfect and always right. Numerous cases of that. Then the security aspect of a jack of all trades process running as one that controls every other process. Reading logs after a panic and rebooting to check them is a pain in the ass without journald on the chrooting system, readi…
> Numerous cases of that. Like when? Because I have interacted with projects where Lennart is part of the admin team and from where I stand it’s all in your head. Both bugs and security are taken seriously. > The above doesn't represent my personal opinion, it's a representation of what reasons people might have. I admire the courage you display in standing for your opinion.
I don't know about your experiences, but systemd is leaking preconceived notions and self-imposed limitations like a broken sieve where one is left to sift manually through documentation and bug-reports, collecting and evaluating rules, exceptions and idiosyncratic notions to determine whether systemd will do what one wants.
Latest example: I have a service I want running, so I set it to Restart=always. Read the long Restart= documentations - seems ok. Does it work?
Failure 1: Well.. you also need appropriate RestartSec/StartLimitInterval. Ok, I I set it up. Does it work?
Failure 2: Well.. restart doesn't actually apply to failed dependencies, so .. don't have dependencies that fail, ok? That's not a bug. [1][2]
People who want to use it can use it. I am thankful for the non-systemd distributions, which are listed at https://nosystemd.org ; just scroll down to the list if you want to skip the advocacy.
I have absolutely fallen in love with FreeBSD after Debian and Arch stopped being what I wanted. It feels closer to what I wanted than a proper Linux.
I have found FreeBSD to be very coherent as a Unix; and the documentation is very well written. Jails, once understood, seem very good also, even if not perfect.
And what kind of fuel would it add? That systemd has corporate backers? Systemd was 100% created by redhat, so no, corporate backers aren't the problem. The real problem is that Microsoft has historically tried to destroy linux, and beyond that, has a huge history of FUD and embrace and extinguish. Many in the OSS community consider Microsoft to be pure evil. And if their historical behaviour is any indication, nothi…
> The real problem is that Microsoft has historically tried to destroy linux, and beyond that, has a huge history of FUD and embrace and extinguish. And now they're one of the major backers. All the work is being done in the open, so it's not like there's a nefarious hidden agenda there (an agenda that would have needed to somehow stay dormant for 10+ years). The idea that working for Microsoft is something dirty tha…
Pulseaudio was developed in the open. So was systemd, and many take issue with that.
And embrace and extend can exist in OSS models.
Microsoft is dirty, and it is dirt they cannot wash off in a mere few years.
If they behave correctly for 20 years, as long as they behaved in a literally evil fashion, then maybe they have reformed.