There's nothing stopping you from running rsyslog in addition to journald. The fact that you don't know this is making me wonder whether systemd is really to blame for the problems you're having booting up.
It is about design choices that people feel should not have been made
If Slashdot is at all representative of Linux users at large, it's obvious that most of them don't know dick about designing software, and would be better off deferring to people who have at least thought about it for more than 10 minutes.
Distribution maintainers are being forced to use it because developers who write the software people run on the distros are choosing to use it. Because it does useful stuff. But don't let that get in the way of your little conspiracy theory, by any means.
No, but evidently you're content being an ungrateful little douchebag. You're entirely free to keep using pre-systemd versions of your preferred distribution, but that isn't enough, is it? You want people to continue volunteering their free time maintaining them for you. Despite the fact they (evidently) pretty much all prefer to use systemd themselves. You apparently don't give a toss about their freedom of choice.
Don't get too comfy! One of these days FreeBSD is going to require you to learn something new and you'll be pissing, whinging and throwing the baby out with the bathwater about that, too.
Modern web dev hasn't given us anything we couldn't of had before
And yet, here you are, posting this to a website, instead of Usenet, which was a) developed specifically for facilitating discussions such as these b) has it's own desktop software and c) was around for about a decade before the web.
Please justify why it's okay for you to pervert the web for purposes that you deem appropriate, but it's not okay for other developers to do the same.
look, either journald is part of systemd or it isn't.
I said it was.
If it is, then systemd does multiple things, and should be broken up into more parts
systemd is a service manager. Logging is an important part of managing services. Just because systemd does multiple things doesn't mean it absolutely has to be split up.
Oh no! The Linux kernel manages file systems AND network interfaces. BETTER SPLIT THE PROJECT UP!
Xorg manages input devices AND graphical displays. BETTER SPLIT THAT UP TOO!
Libreoffice features a spell checker AND a thesaurus. WORST DESIGN DECISION EVER!
There's no reason another syslogd couldn't have been modified to permit it to save logs in memory until the log storage filesystem was mounted
Unless, you know, something goes wrong before the file gets saved. That seems like quite a good reason to me, for a logging system at least.
the only reason which it was implemented in a journald-specific fashion is that Lennart was deliberately trying to break interoperability to force you to use his syslogd
Two of those projects aren't Linux and hence aren't an aspect of a Linux system
They're aspects of my Linux system. Regardless, they're solutions to problems. The major parts of Libreoffice are integrated because the ability to paste (for example) parts spreadsheets into word-processor document is a requirement that a lot of users have.
Components of The GIMP are integrated because it's unrealistic to expect users to alt-tab to a terminal to run a separate command that applies a Gaussian blur to the image currently being edited.
And of course, a big part of the reason why we even have GNU/Linux is because GNU couldn't get their attempt at a modular kernel working in time.
So no, for certain things, "the UNIX way" is not the best way.
Or at the very least, the philosophy is not a hard-and-fast rule to which all aspects of a Linux system must adhere. Some problems are Hard in a way that cannot be solved effectively by stand-alone small sharp tools.
See also: Xorg, Libreoffice, The GIMP, and of course the kernel itself.
Such as binary logging that you probably not be able read if you have to boot from disk
This sentence is the closest you came to a valid technical argument, and it doesn't even make sense.
If [journald] worked without it before then it is not a requirement.
Because journald is part of systemd, it is able to start logging earlier in the boot process and continue logging later in to the shutdown process. This is an improvement over syslogd.
You're entirely free to not use systemd. Just stick with whatever version of whatever distribution you're running now. As as added bonus, you won't have to waste any time with distribution upgrades or the headaches that come when they go wrong.
But oh, what's that? You won't receive any security updates or new features only available in newer versions of your favourite programs?
Hmm. Clearly then, developers and maintainers should be forced to support specific versions of all the software you use, only without certain *other* pieces of software you decide you don't like.
If all the various distribution maintainers and developers have pretty much all agreed that systemd is the way forward -- which they pretty much all have -- why should they go out of their way to make sure you personally feel you have the correct amount of choice?
Out of curiousity I decided to take a look at a typical init file on this machine, running Ubuntu 14.04 LTS.
I chose apache because it was at the top of the list. The file is 410 lines long. Within the first 5 lines of code, we're in to this cryptic, barely readable shit: SCRIPTNAME="${0##*/}" SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
The file also appears to be sourcing variables left, right and centre. User-editable init config options have to be spun off into files their own directory (in this case/etc/defaults/apache2). They can't go in the init file itself because they evidently have to be updated by the package manager all the time. It's hardly any wonder with gems like SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}" all over the place.
Then you've got the usual shitting of PID files out to persistent storage, and the same logic of checking them when starting or stopping the service - which is duplicated each time, in each init file for each service, along with the same basic shit each script has to do to determine it's environment.
I'd actually proved my suspicions within about 5 minutes of opening a few files.
I won't argue that systemd breaks the Unix philosophy of doing one thing well
systemd is a centralised service management platform for Linux. It's been enabled by default on a few big distros for a couple of years now, with more and more adopting it as time goes by.
So it does do one thing, and evidently it does it quite well.
So up until now, the majority of Linux vendors have been using SvsV-init, and you appear to like SysV-init. This was only ever a coincidence.
Now they've decided to use something better. What you've lost is a bunch of people working to write and maintain an operating system that uses SysV-init, because it's no longer beneficial for them to use it. That's not losing your freedom. Nobody has lost any freedom.
I even get the impression that most people here would only be happy if there were people forced to keep working on SysV-init against their will.
Parallel startup? I don't boot servers that often where asynchronous startup of processes is a big issue
I, like a lot of others, pay for my servers by the hour. So being able to spin up and shut down large numbers of virtual servers in under a second to deal with periods of high demand is something that interests me greatly, because it could save me a shitload of cash.
I think the whole systemd saga exposes a very ugly side of the Linux "community" - just because someone is trying to solve a problem that you personally don't suffer from at the moment, their efforts are branded as either 'useless bloat', 'feature creep' or a land grab by an evil megalomaniac or corporation. This is further compounded by people slamming systemd without even knowing what the fuck it even is (HURR WHY IS THERE AN HTTP SERVER RUNNING IN PID 1???). I used to think the general Linux community was better than what I'm seeing here.
systemd is a suite of system management daemons, libraries, and utilities designed as a central management and configuration platform for Linux.
They're implementing whatever features they believe will help improve the product.
Slashdot Mirror
I guess I will have to wait until somebody invents
You might be waiting for a while. Nobody gives a shit about developing that kind of thing any more.
No, you evidently don't understand it. Journald is not "irreparably broken".
You're acting on assumptions that are false and this is more than likely why your computer is fucked up.
There's nothing stopping you from running rsyslog in addition to journald. The fact that you don't know this is making me wonder whether systemd is really to blame for the problems you're having booting up.
It is about design choices that people feel should not have been made
If Slashdot is at all representative of Linux users at large, it's obvious that most of them don't know dick about designing software, and would be better off deferring to people who have at least thought about it for more than 10 minutes.
and that it is forced on them
Nothing is being forced on anyone.
You are entirely free to keep using Windows Millennium Edition instead of Windows 7/8/10
You are, though. What's your point?
running older versions with known security/stability issues is a pretty fucking shitty compromise.
So simply maintain systemd-free forks of all software you use, and packages that depends on that software.
Or convince all software authors not to write software that depends on systemd. What's so hard about that?
Distribution maintainers are being forced to use it because developers who write the software people run on the distros are choosing to use it. Because it does useful stuff. But don't let that get in the way of your little conspiracy theory, by any means.
Yeah, we're getting desperate now nobody is adopting systemd.
oh wait
Are you being dense in purpose?
No, but evidently you're content being an ungrateful little douchebag. You're entirely free to keep using pre-systemd versions of your preferred distribution, but that isn't enough, is it? You want people to continue volunteering their free time maintaining them for you. Despite the fact they (evidently) pretty much all prefer to use systemd themselves. You apparently don't give a toss about their freedom of choice.
Don't get too comfy! One of these days FreeBSD is going to require you to learn something new and you'll be pissing, whinging and throwing the baby out with the bathwater about that, too.
Modern web dev hasn't given us anything we couldn't of had before
And yet, here you are, posting this to a website, instead of Usenet, which was a) developed specifically for facilitating discussions such as these b) has it's own desktop software and c) was around for about a decade before the web.
Please justify why it's okay for you to pervert the web for purposes that you deem appropriate, but it's not okay for other developers to do the same.
What's your point? Are you claiming that it's okay for kernels to be monolithic, but nothing else?
look, either journald is part of systemd or it isn't.
I said it was.
If it is, then systemd does multiple things, and should be broken up into more parts
systemd is a service manager. Logging is an important part of managing services. Just because systemd does multiple things doesn't mean it absolutely has to be split up.
Oh no! The Linux kernel manages file systems AND network interfaces. BETTER SPLIT THE PROJECT UP!
Xorg manages input devices AND graphical displays. BETTER SPLIT THAT UP TOO!
Libreoffice features a spell checker AND a thesaurus. WORST DESIGN DECISION EVER!
There's no reason another syslogd couldn't have been modified to permit it to save logs in memory until the log storage filesystem was mounted
Unless, you know, something goes wrong before the file gets saved. That seems like quite a good reason to me, for a logging system at least.
the only reason which it was implemented in a journald-specific fashion is that Lennart was deliberately trying to break interoperability to force you to use his syslogd
I stopped reading here.
Two of those projects aren't Linux and hence aren't an aspect of a Linux system
They're aspects of my Linux system. Regardless, they're solutions to problems. The major parts of Libreoffice are integrated because the ability to paste (for example) parts spreadsheets into word-processor document is a requirement that a lot of users have.
Components of The GIMP are integrated because it's unrealistic to expect users to alt-tab to a terminal to run a separate command that applies a Gaussian blur to the image currently being edited.
And of course, a big part of the reason why we even have GNU/Linux is because GNU couldn't get their attempt at a modular kernel working in time.
So no, for certain things, "the UNIX way" is not the best way.
Okay, here's mine: the philosophy is irrelevant.
Or at the very least, the philosophy is not a hard-and-fast rule to which all aspects of a Linux system must adhere. Some problems are Hard in a way that cannot be solved effectively by stand-alone small sharp tools.
See also: Xorg, Libreoffice, The GIMP, and of course the kernel itself.
Such as binary logging that you probably not be able read if you have to boot from disk
This sentence is the closest you came to a valid technical argument, and it doesn't even make sense.
If [journald] worked without it before then it is not a requirement.
Because journald is part of systemd, it is able to start logging earlier in the boot process and continue logging later in to the shutdown process. This is an improvement over syslogd.
Isn't it funny how people only really have problems with monolithic cultures when they don't like the monolith?
It seems we're all happy enough with a monolithic kernel, but if someone dares to set up another one *directly below it*, there's fucking murder.
If this particular monolith is as bad as everyone is saying, there should be plenty of alternatives already.
Jesus fucking Christ. A sane and rational person in a discussion about systemd. . .
You're entirely free to not use systemd. Just stick with whatever version of whatever distribution you're running now. As as added bonus, you won't have to waste any time with distribution upgrades or the headaches that come when they go wrong.
But oh, what's that? You won't receive any security updates or new features only available in newer versions of your favourite programs?
Hmm. Clearly then, developers and maintainers should be forced to support specific versions of all the software you use, only without certain *other* pieces of software you decide you don't like.
Fuck *their* freedom! It's all about you.
If all the various distribution maintainers and developers have pretty much all agreed that systemd is the way forward -- which they pretty much all have -- why should they go out of their way to make sure you personally feel you have the correct amount of choice?
Out of curiousity I decided to take a look at a typical init file on this machine, running Ubuntu 14.04 LTS.
I chose apache because it was at the top of the list. The file is 410 lines long. Within the first 5 lines of code, we're in to this cryptic, barely readable shit:
SCRIPTNAME="${0##*/}"
SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
The file also appears to be sourcing variables left, right and centre. User-editable init config options have to be spun off into files their own directory (in this case /etc/defaults/apache2). They can't go in the init file itself because they evidently have to be updated by the package manager all the time. It's hardly any wonder with gems like SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}" all over the place.
Then you've got the usual shitting of PID files out to persistent storage, and the same logic of checking them when starting or stopping the service - which is duplicated each time, in each init file for each service, along with the same basic shit each script has to do to determine it's environment.
I'd actually proved my suspicions within about 5 minutes of opening a few files.
I won't argue that systemd breaks the Unix philosophy of doing one thing well
systemd is a centralised service management platform for Linux. It's been enabled by default on a few big distros for a couple of years now, with more and more adopting it as time goes by. So it does do one thing, and evidently it does it quite well.
So up until now, the majority of Linux vendors have been using SvsV-init, and you appear to like SysV-init. This was only ever a coincidence. Now they've decided to use something better. What you've lost is a bunch of people working to write and maintain an operating system that uses SysV-init, because it's no longer beneficial for them to use it. That's not losing your freedom. Nobody has lost any freedom. I even get the impression that most people here would only be happy if there were people forced to keep working on SysV-init against their will.
[systemd is] wildly popular with distribution builders, but this doesn't mean jack with anyone else.
There are so many things wrong with this single statement I don't know where to begin.
Parallel startup? I don't boot servers that often where asynchronous startup of processes is a big issue
I, like a lot of others, pay for my servers by the hour. So being able to spin up and shut down large numbers of virtual servers in under a second to deal with periods of high demand is something that interests me greatly, because it could save me a shitload of cash.
I think the whole systemd saga exposes a very ugly side of the Linux "community" - just because someone is trying to solve a problem that you personally don't suffer from at the moment, their efforts are branded as either 'useless bloat', 'feature creep' or a land grab by an evil megalomaniac or corporation. This is further compounded by people slamming systemd without even knowing what the fuck it even is (HURR WHY IS THERE AN HTTP SERVER RUNNING IN PID 1???). I used to think the general Linux community was better than what I'm seeing here.
systemd is a suite of system management daemons, libraries, and utilities designed as a central management and configuration platform for Linux. They're implementing whatever features they believe will help improve the product.