The core of systemd isn't just an init system. It's an init system and other mandatory crap, plus some optional crap. If it were simply an init system with other optional crap (sans the mandatory crap -- like journald), you would be correct. The minute your core functionality depends on an external package that serves no other purpose than to give the appearance of separation, the two effectively become one and the distinction becomes meaningless.
Can I use journald without systemd? I'm legitimately asking. If not, then it relies on systemd; and since systemd relies on it, that circular dependency makes them a unit. Following the Unix philosophy, you should have no circular dependencies in critical infrastructure; if you do, you've really got a single unit trying to do two or more jobs, in violation of the first tenet of the Unix philosophy. Period.
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to.
True, but only an idiot would contribute to them. It's like handing the guy with a gun to your head the bullet he's going to use to shoot you. Much better to disarm him while the gun's not loaded.
That's not to say I believe that systemd contributors are idiots because I disagree with it's philosophy, just so they're no confusion; if they agree with it. But to contribute to something with which you don't agree is just plain idiotic.
Speaking of which, can I get you to weigh in on UnknowingFool's status as a child rapist? Is he or is he not? I'm two people away from making it a truth by his own standards and your assistance would be greatly appreciated. He hasn't bothered responding to me since I first said it, so perhaps it's already true without my intervention.
I never claimed it was monolithic, but it doesn't stick to a single task, nor does it necessarily do that task all that well, which is the first tenet of the Unix philosophy. Its logging system also doesn't work on a text stream, which is the third. Arguably, its components do work together, so it at least (maybe) follows the second.
Ah, but it is a workaround, and not even a reliable one. There is no guarantee that systemd will actually pass all logged data to your logging system of choice and, as I stated (and you failed to address):
Having two logging systems running in parallel isn't exactly ideal and is, in fact, yet another problem.
Let me clarify, though: two logging systems for the same data. Yeah, real efficient; there's no problem with doubling the amount of storage required to store logs, nor with doubling the I/O load of your logs. Right.
The fact is that systemd's excuse for what binary logging was necessary are bullshit; the same benefits could have been achieved with a text log and, if you really want to see it perform, a separate binary index for searching.
And the whole argument ignores the fact that systemd isn't really solving any real problem; but it does violate the Unix philosophy, which is why many people who use Linux for its Unix-like environment and mostly-adherence to the Unix philosophy have a problem with it.
Personally, I don't care one way or the other as long as my servers boot and do what I need them to do. Currently, systemd isn't causing problems for me, but it is important to understand the real reason people complain about it. I'd rather still be suing sysvinit because it fits the Unix philosophy that brought me to Linux in the first place, but I'm not exactly up in arms over systemd. Unlike you, though, I do understand why a lot of people are; and I don't think they're wrong.
Why does it throttle in the first place? I can see an argument for collapsing (e.g. "Some-logged-message [100]" to denote that "Some-logged-message" was logged 100 times), but if I have 100 unique messages, they need to all be in the log. Period.
A workaround doesn't fix the problem; the problem still exists, he's just able to deal with it for the time being. Having two logging systems running in parallel isn't exactly ideal and is, in fact, yet another problem.
No, the problem is that systemd violates the Unix philosophy:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
Most of us chose Linux because we wanted a Unix-like environment; systemd violates that choice.
If systemd were a collection of loosely coupled modules we could pick and choose from (e.g. a collection of programs that do one thing) and they could manage to each do the one thing they do well, we'd have less of a problem with it. If that collection of programs worked together (we'd presume that to be the case, of course), we'd have even less of a problem. If it handled text streams (rather than a forced binary logging interface) as well, we'd have no problem with it.
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
It was later revised to:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
And, of course, systemd isn't compatible with either specification, which means it would (and should) be rejected by the Unix world and, thus, by Minix, which follows the Unix philosophy; as such, it should be rejected by Linux, which is based on Minix and also strives to follow the Unix philosophy.
Why is that so hard for systemd proponents to understand? Just make a fork of Linux that doesn't purport to be Unix-like and limit systemd's reach to that fork and everyone will be happy. We chose Linux because we wanted a Unix-like environment and your systemd violates that choice.
You may have missed the nuance in my message. Also, 'twas the AC before me who raised the idea that people are shit, I was mere expanding on that.
Also, for someone whose username appears to be complaining about SJWs, you sure have latched on to their tactics. You embrace reflection the same way they do to; what, with calling me a child whilst falling back on the most childish of argumentative strategies yourself.
Perhaps the worst of them are those who believe that, if at least a handful of people make a claim, that claim must be true. I do wonder how those morons reconcile 3 people claiming the earth is round and 3 more claiming it's flat, though.
Want to bet that within 10 years some loudmouthed idiot group demands to teach the flat earth model as "an alternative theory" to the globe model because we should "teach the controversy"?
No, I'd rather not think of that as even being a possibility. We have guns and they'll out themselves on the internet long before they get around to petitioning for anything.
the modules are "tightly coupled" vs. old school loosely coupled
Tightly coupled means module A depends on module B and module B depends on module A, so you must always use both together. That is, they're not really separate modules but, rather, separate parts of the same module. It means you cannot easily use just one component, or easily change out just one component in favor of another that better suits your needs or use case. Being tightly coupled is exactly the opposite of being modular.
Tight coupling makes a system less adaptable and more difficult to maintain. When you hear someone speak of "spaghetti code", they're talking about tight coupling.
Loosely coupled systems aren't old school, either; they're what replaced the tightly coupled messes that came before them.
Learn a little bit of computing history and comp sci before you spout off, please.
No, really, it happens. Especially when there are a lot of events being logged; some condition exists within journald's code that causes it to just drop messages if it can't keep up. It's like they've never heard of buffers or, at least, just learned of them and aren't quite sure how to properly implement them.
I'd fix it, but then I'd have my name on systemd and that would be worse than dealing with spotty logs.
On your last point, that's REALLY BAD! When there is a catastrophic failure of some part of one of my systems, I want lights and sirens and a flashing sign pointing at the problem, not just "fail" printed out on a screen I might not even be looking at!
But, of course, we're handing the world over to a generation that believe that only the things they want to matter actually matter and, if they can minimize their interaction with things they don't like, those things cease to exist. By that logic, hiding the issue fixes the issue, so I can see why they did it.
But no, really, if something breaks on my system, spam the message over top of whatever ncurses-based application I might have open in a terminal, pop up a persistent notification in whatever notification manager I've got running in my GUI (if I'm running a GUI) or pull me to a console if no notification manager is present or running, fill my terminal with details about the issue, alert me in every way possible so I can fix the issue. The right thing to do is to NOT make it easy to ignore!
Oh, but that might interrupt your YouTube video or the game you're paying?
SO WILL THE ENTIRE FUCKING SYSTEM GOING DOWN IN FLAMES BECAUSE YOU'VE BEEN IGNORING PROBLEMS AND LETTING THEM PILE UP UNTIL THEY REACH A TIPPING POINT AND THE COMPUTER SAYS "FUCK IT, i CAN'T GO ON LIKE THIS ANYMORE!"
Slashdot Mirror
Then desktop distros should use it and server distros should not. Ubuntu vs Ubuntu Server, for example.
Is this even supposed to be a serious argument?
Considering that the flags were "-f -u", I'm thinking you're the only one who needs that question answered. No, it was not.
The core of systemd isn't just an init system. It's an init system and other mandatory crap, plus some optional crap. If it were simply an init system with other optional crap (sans the mandatory crap -- like journald), you would be correct. The minute your core functionality depends on an external package that serves no other purpose than to give the appearance of separation, the two effectively become one and the distinction becomes meaningless.
Can I use journald without systemd? I'm legitimately asking. If not, then it relies on systemd; and since systemd relies on it, that circular dependency makes them a unit. Following the Unix philosophy, you should have no circular dependencies in critical infrastructure; if you do, you've really got a single unit trying to do two or more jobs, in violation of the first tenet of the Unix philosophy. Period.
If you say so.
;)
So, like grep, more (or less), and sed, which can all be used on a disk pulled from a system with a failed init?
Two separate points, you're conflating them when you should not be.
Patches for those security issues would be prime examples, dunce.
That's fair too, but that's life. Sometimes you have to deal with things you are fundamentally opposed to.
True, but only an idiot would contribute to them. It's like handing the guy with a gun to your head the bullet he's going to use to shoot you. Much better to disarm him while the gun's not loaded.
That's not to say I believe that systemd contributors are idiots because I disagree with it's philosophy, just so they're no confusion; if they agree with it. But to contribute to something with which you don't agree is just plain idiotic.
Speaking of which, can I get you to weigh in on UnknowingFool's status as a child rapist? Is he or is he not? I'm two people away from making it a truth by his own standards and your assistance would be greatly appreciated. He hasn't bothered responding to me since I first said it, so perhaps it's already true without my intervention.
I never claimed it was monolithic, but it doesn't stick to a single task, nor does it necessarily do that task all that well, which is the first tenet of the Unix philosophy. Its logging system also doesn't work on a text stream, which is the third. Arguably, its components do work together, so it at least (maybe) follows the second.
I disagree with what you say, but I will defend to the death your right to say it.
You, on the other hand, think I should be silenced.
Who's the infant, here? Probably the moron with the week old account.
That really and truly is the world we live in now, it seems.
Having two logging systems running in parallel isn't exactly ideal and is, in fact, yet another problem.
Let me clarify, though: two logging systems for the same data. Yeah, real efficient; there's no problem with doubling the amount of storage required to store logs, nor with doubling the I/O load of your logs. Right.
The fact is that systemd's excuse for what binary logging was necessary are bullshit; the same benefits could have been achieved with a text log and, if you really want to see it perform, a separate binary index for searching.
And the whole argument ignores the fact that systemd isn't really solving any real problem; but it does violate the Unix philosophy, which is why many people who use Linux for its Unix-like environment and mostly-adherence to the Unix philosophy have a problem with it.
Personally, I don't care one way or the other as long as my servers boot and do what I need them to do. Currently, systemd isn't causing problems for me, but it is important to understand the real reason people complain about it. I'd rather still be suing sysvinit because it fits the Unix philosophy that brought me to Linux in the first place, but I'm not exactly up in arms over systemd. Unlike you, though, I do understand why a lot of people are; and I don't think they're wrong.
Why does it throttle in the first place? I can see an argument for collapsing (e.g. "Some-logged-message [100]" to denote that "Some-logged-message" was logged 100 times), but if I have 100 unique messages, they need to all be in the log. Period.
A workaround doesn't fix the problem; the problem still exists, he's just able to deal with it for the time being. Having two logging systems running in parallel isn't exactly ideal and is, in fact, yet another problem.
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
Most of us chose Linux because we wanted a Unix-like environment; systemd violates that choice.
If systemd were a collection of loosely coupled modules we could pick and choose from (e.g. a collection of programs that do one thing) and they could manage to each do the one thing they do well, we'd have less of a problem with it. If that collection of programs worked together (we'd presume that to be the case, of course), we'd have even less of a problem. If it handled text streams (rather than a forced binary logging interface) as well, we'd have no problem with it.
It breaks a lot of the *concept* of unix.
And therein lies the problem. After all, Linux is based on Minix and Minix is "a POSIX-compliant (since version 2.0), Unix-like computer operating system".
POSIX, of course, is a standard derived from the various versions of Unix that existed when the standard was first thought of; and Unix systems are characterized by a modular design that is sometimes called the "Unix philosophy".
The original draft of the Unix philosophy stated:
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
It was later revised to:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
And, of course, systemd isn't compatible with either specification, which means it would (and should) be rejected by the Unix world and, thus, by Minix, which follows the Unix philosophy; as such, it should be rejected by Linux, which is based on Minix and also strives to follow the Unix philosophy.
Why is that so hard for systemd proponents to understand? Just make a fork of Linux that doesn't purport to be Unix-like and limit systemd's reach to that fork and everyone will be happy. We chose Linux because we wanted a Unix-like environment and your systemd violates that choice.
You may have missed the nuance in my message. Also, 'twas the AC before me who raised the idea that people are shit, I was mere expanding on that.
Also, for someone whose username appears to be complaining about SJWs, you sure have latched on to their tactics. You embrace reflection the same way they do to; what, with calling me a child whilst falling back on the most childish of argumentative strategies yourself.
This from someone who can't use vowels in their username... except for that one "i" that somehow slipped in there.
Want to bet that within 10 years some loudmouthed idiot group demands to teach the flat earth model as "an alternative theory" to the globe model because we should "teach the controversy"?
No, I'd rather not think of that as even being a possibility. We have guns and they'll out themselves on the internet long before they get around to petitioning for anything.
Ah, the golden rule. I'm guessing you're over 30? Because I don't know anyone under 30 who even knows what that is.
We should start teaching them before it's too late.
the modules are "tightly coupled" vs. old school loosely coupled
Tightly coupled means module A depends on module B and module B depends on module A, so you must always use both together. That is, they're not really separate modules but, rather, separate parts of the same module. It means you cannot easily use just one component, or easily change out just one component in favor of another that better suits your needs or use case. Being tightly coupled is exactly the opposite of being modular.
Tight coupling makes a system less adaptable and more difficult to maintain. When you hear someone speak of "spaghetti code", they're talking about tight coupling.
Loosely coupled systems aren't old school, either; they're what replaced the tightly coupled messes that came before them.
Learn a little bit of computing history and comp sci before you spout off, please.
Ubuntu or one of the other Debian-based systems, I'm guessing? Same boat, buddy...
No, really, it happens. Especially when there are a lot of events being logged; some condition exists within journald's code that causes it to just drop messages if it can't keep up. It's like they've never heard of buffers or, at least, just learned of them and aren't quite sure how to properly implement them.
I'd fix it, but then I'd have my name on systemd and that would be worse than dealing with spotty logs.
On your last point, that's REALLY BAD! When there is a catastrophic failure of some part of one of my systems, I want lights and sirens and a flashing sign pointing at the problem, not just "fail" printed out on a screen I might not even be looking at!
But, of course, we're handing the world over to a generation that believe that only the things they want to matter actually matter and, if they can minimize their interaction with things they don't like, those things cease to exist. By that logic, hiding the issue fixes the issue, so I can see why they did it.
But no, really, if something breaks on my system, spam the message over top of whatever ncurses-based application I might have open in a terminal, pop up a persistent notification in whatever notification manager I've got running in my GUI (if I'm running a GUI) or pull me to a console if no notification manager is present or running, fill my terminal with details about the issue, alert me in every way possible so I can fix the issue. The right thing to do is to NOT make it easy to ignore!
Oh, but that might interrupt your YouTube video or the game you're paying?
SO WILL THE ENTIRE FUCKING SYSTEM GOING DOWN IN FLAMES BECAUSE YOU'VE BEEN IGNORING PROBLEMS AND LETTING THEM PILE UP UNTIL THEY REACH A TIPPING POINT AND THE COMPUTER SAYS "FUCK IT, i CAN'T GO ON LIKE THIS ANYMORE!"