Anyone who equates someone who accepts DRM with someone who accepts the systematic slaughter of an entire people by the state needs to have their sense of proportion adjusted.
Alas, the world is not black and white and is various shaded of grey. Once you start accepting something history tells you it then becomes and ever so slightly steeper slope.
Don't freak out over strong analogies or because someone uses a particular word.
It's amazing what pointless stuff you can pay for with fiat currencies. Hold on to you hats when it all ends because you're going to find a lot of jobs and whole industries simply disappear.
That's why people who pour cold water on unsustainable population growth don't know what they're talking about.
When I see a statement like that I think to myself - why.
The fact that you have to even ask that means that you will never get it. When you have an init process that feels the need to do a whole lot more you have several times the bugs, and this is a system you're relying on to boot a system - which you're then going to have to troubleshoot. As a system administrator it fills me with absolute dread.
I really seems to me that getting rid of that horrible kludge of shellscripts and moving towards a standardised and sensible startup process is a big step forwards in Linux land.
Shell scripts are human readable, they work and they stand independently so if something fails, most of the time, it won't affect anything else. In a systemd system you won't have the faintest idea what s going to happen. There is no reason a more sane init system could not be developed that used human readable scripts and logs, and we certainly don't need systemd to get there.
If the author find real bugs and truly disruptive design choice in systemd he should do as any good open source citizen: report it. This has already been done recently for the "debug" command line switch controversy.
They have been reported, and in true fashion they are dismissed in that passive aggressive style that has become oh, so familiar. The comments section of that article makes that clear and it makes it clear that those behind systemd have no idea how a Unix style system should work, and why. Hint: Poorly documented, bullshit XML schemas have no place anywhere near there. Linus, Ingo Molnar and Ted Tso have all made their positions crystal clear on the style and maintainership of that piece of software and the people behind it. As Ted Tso put it:
...one of the reasons why this happens is because +Kay Sievers and +Lennart Poettering often have the same response style to criticisms as the +GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away.
So, please stop using that pathetic 'Report it' excuse. It will make no difference and we all know it won't.
This has already been done recently for the "debug" command line switch controversy.
You're not honestly trying to suggest that that bug report was solved in anyway approaching a satisfactory manner, are you?
The net effect of this is someone, probably a bunch of kernel developers, are going to have to get hold of this shit and sort it out by writing a proper and sane init system because userspace is getting totally out of hand.
Actually, you are arbitrarily declaring it "needless complexity," when what you mean is "this is new and I don't understand it, so I hate it." The reality is it is quite a bit simpler in a number of ways. Whether or not it is on a remote server is irrelevant.
No, it is needless complexity and it is NOT simpler in a lot of ways - not by a long stretch. systemd incorporates a lot of functions that have long been separate and focused. Troubleshooting this monolithic system, and even reading its logs, is a quantum leap harder to do so do not presume to tell me what the 'reality' is in the manner that its maintainers tend to do. I administrate servers where I require a working init system, that's the reality.
Why? That is a meaningless rebuttal.
Because it's meaningless? You've put the word 'enterprise' in there and expect it to mean something. Sorry, but it doesn't. Logs that I can read at a low level are critical for an 'enterprise' infrastructure. I've been through that with Windows.
The mailing list posts are VERY clear. There is a HUGE problem with the crew and its attitude that writes systemd and no amount of candy coating the issue with massaged 'solutions' will make that go away:
That is either a bug, or possibly a conflict. Again, I can see how it is annoying, but if you have an/etc/fstab entry that wants to steamroll a systemd entry, it is understandable that systemd will try to stop that from happening. The correct fix in that case would be to edit the systemd entry to match the changes you are trying to make with the/etc/fstab entry.
You're missing the point here. I'm not troubleshooting that needless complexity on a remote server, and the problem here is needless complexity.
but I can also see how journald is critical for certain enterprise infrastructure.
That is a meaningless statement.
If you don't like journald, you can install syslog-ng. You just have to make sure it doesn't trample on journald...
....you're seeing Sievers's actions (condemnable as they are) as representative of the whole systemd team. (They maybe, in which case you need to show more than one lone post as proof.)
the journal instead of a set of randomly formatted text-dumps all over/var/log,
Yes, those would be called, errr, yes, LOGS.......
As a sys admin I want something I can read when my system goes wrong and I don't want to have to get a retarded web server up and running to read them.
Seriously, people suggesting this kind of retarded shit don't know Unix, don't know Linux and don't have the faintest idea whatsoever. Go and read a Windows registry file, have fun and knock yourself out but don't bring that retarded crap so an operating system that actually works.
The ewontfix.com/14 article is full of factual errors and was rebunked several times by more knowlegable people.
No it hasn't. Process ID 1 should do very little. That has always been the premise of init systems. When you've got something that does the exact opposite then you've got a problem.
And Linus is pretty easy to piss off, what does that prove?
It's not often he calls into question the competence of a bunch of maintainers and effectively labels them as morons.
The software depends on systemd since it solves real problems that software used to be facing. When a wide group of developers sees value in using systemd, then maybe reading up on it (past the point where you go "oh, we never did it like that before") might be warranted?
Open source developers have often linked to bits of software long since discarded as bad ideas through real-world experience. Besides, what 'real world problems'? Linux requires a functioning init system that doesn't have a ton of unexplainable bugs in all the scenarios such a system finds itself in. I mean, it discards plain text logs for fuck's sake and has its own web server so you can fucking view them. That is retarded. End of story.
Linux and open source software in general has always been about survival of the fittest software, not by software being enforced by a company and by a bunch of people who haven't the faintest idea what they are doing. systemd is the total antithesis of the Unix philosophy - do one thing, do it well and have a bunch of focused interconnected system.
The people behind systemd are the same people who Linus Torvalds exposed as morons who kept breaking udev:
So it's OK if they don't commit to supporting it? Fantastic.
...but so was the F-104 and *that* one gets included in a lot of "best planes ever" lists.
Now that really is a joke. The F-104 was an absolute killer.
Skirting around the point. The effects of metal fatigue simply weren't known and fully understood until the Comet.
No, they didn't. It was only with the advent of the Comet that anyone understood metal fatigue and the effect of shapes of things like windows on it.
Anyone who equates someone who accepts DRM with someone who accepts the systematic slaughter of an entire people by the state needs to have their sense of proportion adjusted.
Alas, the world is not black and white and is various shaded of grey. Once you start accepting something history tells you it then becomes and ever so slightly steeper slope.
Don't freak out over strong analogies or because someone uses a particular word.
It is a stunt that will land you in jail.
A stunt that will end in the Firefox browser refusing to install or communicate with any unauthorized extensions.
Yer, like this hasn't been done before and like that's put people off doing such things in the past. We all know this is going to happen.
It's amazing what pointless stuff you can pay for with fiat currencies. Hold on to you hats when it all ends because you're going to find a lot of jobs and whole industries simply disappear.
That's why people who pour cold water on unsustainable population growth don't know what they're talking about.
That is all.
When I see a statement like that I think to myself - why.
The fact that you have to even ask that means that you will never get it. When you have an init process that feels the need to do a whole lot more you have several times the bugs, and this is a system you're relying on to boot a system - which you're then going to have to troubleshoot. As a system administrator it fills me with absolute dread.
I really seems to me that getting rid of that horrible kludge of shellscripts and moving towards a standardised and sensible startup process is a big step forwards in Linux land.
Shell scripts are human readable, they work and they stand independently so if something fails, most of the time, it won't affect anything else. In a systemd system you won't have the faintest idea what s going to happen. There is no reason a more sane init system could not be developed that used human readable scripts and logs, and we certainly don't need systemd to get there.
Those who don't know Unix are doomed to re-create it, poorly.
As simple as that, basically.
Put simply, if the systemd people feel they're going to have an argument with kernel developers about how things should work and win, forget it.
If the author find real bugs and truly disruptive design choice in systemd he should do as any good open source citizen: report it. This has already been done recently for the "debug" command line switch controversy.
They have been reported, and in true fashion they are dismissed in that passive aggressive style that has become oh, so familiar. The comments section of that article makes that clear and it makes it clear that those behind systemd have no idea how a Unix style system should work, and why. Hint: Poorly documented, bullshit XML schemas have no place anywhere near there. Linus, Ingo Molnar and Ted Tso have all made their positions crystal clear on the style and maintainership of that piece of software and the people behind it. As Ted Tso put it:
...one of the reasons why this happens is because +Kay Sievers and +Lennart Poettering often have the same response style to criticisms as the +GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away.
So, please stop using that pathetic 'Report it' excuse. It will make no difference and we all know it won't.
This has already been done recently for the "debug" command line switch controversy.
You're not honestly trying to suggest that that bug report was solved in anyway approaching a satisfactory manner, are you?
The net effect of this is someone, probably a bunch of kernel developers, are going to have to get hold of this shit and sort it out by writing a proper and sane init system because userspace is getting totally out of hand.
Actually, you are arbitrarily declaring it "needless complexity," when what you mean is "this is new and I don't understand it, so I hate it." The reality is it is quite a bit simpler in a number of ways. Whether or not it is on a remote server is irrelevant.
No, it is needless complexity and it is NOT simpler in a lot of ways - not by a long stretch. systemd incorporates a lot of functions that have long been separate and focused. Troubleshooting this monolithic system, and even reading its logs, is a quantum leap harder to do so do not presume to tell me what the 'reality' is in the manner that its maintainers tend to do. I administrate servers where I require a working init system, that's the reality.
Why? That is a meaningless rebuttal.
Because it's meaningless? You've put the word 'enterprise' in there and expect it to mean something. Sorry, but it doesn't. Logs that I can read at a low level are critical for an 'enterprise' infrastructure. I've been through that with Windows.
It's all very reminiscent of glibc actually.......
http://lkml.iu.edu//hypermail/... http://lkml.iu.edu//hypermail/...
But at least there's an upside for me: I don't have to deal with the systemd maintainers' excessively passive-aggressive behavior ;-)
There is nothing ambiguous about that.
But then you have to provide some way for the system to decide which USER is allowed to "f***ing start" each service.
No I don't, and never have done.
That is either a bug, or possibly a conflict. Again, I can see how it is annoying, but if you have an /etc/fstab entry that wants to steamroll a systemd entry, it is understandable that systemd will try to stop that from happening. The correct fix in that case would be to edit the systemd entry to match the changes you are trying to make with the /etc/fstab entry.
You're missing the point here. I'm not troubleshooting that needless complexity on a remote server, and the problem here is needless complexity.
but I can also see how journald is critical for certain enterprise infrastructure.
That is a meaningless statement.
If you don't like journald, you can install syslog-ng. You just have to make sure it doesn't trample on journald...
Great.
ewontfix article has been demystified several times.
I think that sentence adequately sums up the quality of the 'debunking' of that article - non-existent.
It doesn't need demystified, it's crystal clear.
....you're seeing Sievers's actions (condemnable as they are) as representative of the whole systemd team. (They maybe, in which case you need to show more than one lone post as proof.)
Oh come on.
I think you'll find he's calling into question the quality, or lack of it, of the software that that crew seems to be producing so yes he is.
the journal instead of a set of randomly formatted text-dumps all over /var/log,
Yes, those would be called, errr, yes, LOGS.......
As a sys admin I want something I can read when my system goes wrong and I don't want to have to get a retarded web server up and running to read them.
Seriously, people suggesting this kind of retarded shit don't know Unix, don't know Linux and don't have the faintest idea whatsoever. Go and read a Windows registry file, have fun and knock yourself out but don't bring that retarded crap so an operating system that actually works.
The ewontfix.com/14 article is full of factual errors and was rebunked several times by more knowlegable people.
No it hasn't. Process ID 1 should do very little. That has always been the premise of init systems. When you've got something that does the exact opposite then you've got a problem.
And Linus is pretty easy to piss off, what does that prove?
It's not often he calls into question the competence of a bunch of maintainers and effectively labels them as morons.
The software depends on systemd since it solves real problems that software used to be facing. When a wide group of developers sees value in using systemd, then maybe reading up on it (past the point where you go "oh, we never did it like that before") might be warranted?
Open source developers have often linked to bits of software long since discarded as bad ideas through real-world experience. Besides, what 'real world problems'? Linux requires a functioning init system that doesn't have a ton of unexplainable bugs in all the scenarios such a system finds itself in. I mean, it discards plain text logs for fuck's sake and has its own web server so you can fucking view them. That is retarded. End of story.
Linux and open source software in general has always been about survival of the fittest software, not by software being enforced by a company and by a bunch of people who haven't the faintest idea what they are doing. systemd is the total antithesis of the Unix philosophy - do one thing, do it well and have a bunch of focused interconnected system.
The people behind systemd are the same people who Linus Torvalds exposed as morons who kept breaking udev:
http://article.gmane.org/gmane...
Telling everyone to 'just get used to it' is not the way things are done.
You'd notice how slow it is though. It's a t-e-x-t e-d-i-t-o-r.
It's a fucking text editor.