The trick to the Betteridge law is that when a journalist writes a headline as a question, the question is suggesting what most people find improbable; and the improbable rarely happens.
In in the case of certain publications, where the editors want to inflame the masses by suggesting that their fondest prejudices MIGHT be true.
I think you got the impression that I meant that systemd "broke gnome3".
I did not. BOTH systemd AND gnome3 broke things that people were actively using. In my case, gnome3 lost me all the system-monitoring applets in the screen borders. That wasn't a matter of "learning to do things different", it was a matter of a critical day-to-day resource being taken away from me. Gnome3's failure was that it didn't offer an acceptable alternative, not that it was "different". It was, bluntly put, LESS functional for my needs than its predecessor. Nautilus angered a lot of people when its developers arrogantly removed some of the window functions, but in their case, I think after enough abuse from the user community theu put it back.
My solution for my gnome3 problems turned out to be simple. I now use the Cinnamon Desktop and the Gnome people can go twist in the wind for all I care.
The systemd issue has aroused even greater ire, however, because it's not designed to be plug-replaceable the way that GUI desktops are. You either learn to love it, suffer with it, or find an alternative distro to work with. Or an alternative OS, if you run out of acceptable distros.
I'm not one to hold to old ways just because "it's always been done that way". I've seen a LOT of changes in Linux since I started playing with it in the early 90's. I don't have any particular hatred for systemd's init subsystem, because, while I think it can evolve to be better, it's basically usable. The only real fault I could give it is that in my experience, if you're so tightly wired into external things that you become an essential part of them, that's probably not the optimal system design.
I DO have a lot against the binary logging for very good reasons. I've worked with a lot of products that did their logging in proprietary binary formats over the years, and even when the internal data formats are well-published, the mere fact that intermediary services are required to access and format them has made their respective products harder to work with.
It's rather like the Windows Registry. The Registry was created to solve several problems, some of which no longer exist even on Windows. It's widely considered to be a real mess for all sorts of reasons, which I won't bother to repeat at the moment, although, for example, restoring selected applications - and their configurations - from a backup tape are a good example. Linux, on the other hand, settled on a tree of text config files and the benefits have been immeasurable. The tree of text log files is perhaps less obviously beneficial - at least until you have to recover them off a dead disk from a foreign OS, but it does have enough weight behind it to warrant keeping for functional reasons, and not merely because it's "old fashioned".
The Emperor's clothes were new, too, but I don't want to wear a set of them.
Actually, it's the fact that systemd doesn't rotate logs that's one of my pet peeves. Unless you go in and mess around with the defaults, it's going to keep things virtually forever.
Usually what I need to know is at the tail of the active logfile. logrotate typically keeps 4 weeks of logs. I figure after a month, about the only real use that data is going to be is for the benefit of lawsuits and the NSA, as by then I'll have either fixed the issue or given up on it.
Irony. Considering how important selinux is to Red Hat, it's funny that as recently as Fedora 20, the selinux audit logs are still discrete text files. They didn't eat their own dog food.
Although that does bring up an interesting point. A consolidated log cannot be secured to "need-to-know" groups the way that discrete logs can. Red Hat also historically has been more prone than most OS's to split logs into distinct product groups instead of putting everything into one log. Maybe they thought it would be easier to work with if you didn't have 97 other product's log messages to winnow out.
Fortunately the US is likely to tell Cameron to fuck off, since it would be unconstitutional to ban encryption and after the economic damage that the NSA did they won't allow the UK to force service providers to back-door their apps.
Have you forgotten? Up to and including the Clinton years, encryption was classified as a "munition" and was very much controlled by the US Government.
users: Why is there binary logging? I cant grep anything and dont know why the system crashed. the way user switching works is a huge security hole pottering:no ones forcing you to use it, use something else XXXXX You're an ungrateful wretch. Just pipe it out from the binary logs. No one REALLY needs logs that are directly accessible to the multitude of text utilities that Unix/Linux first became famous for.
I tend to grit my teeth when people say "If it ain't broke, don't fix it" about IT. IT tends to erode from the outside in, if no other way.
On the other hand, if you do "fix it", don't break things that people like and rely on. And don't have the hubris to tell people that they're wrong/misguided/old-fashioned when they complain. That's the sin that both gnome3 and systemd committed.
To a manager "that sounds easy" = AYHTDI and they want it by 8 AM tomorrow. I realize there's a difference, but it tends to get lost in translation. One thing I've learned in IT is that things that sound simple are often harder than they look, although fortunately often stuff that seems like it would be hard turns out to be easier than expected.
The idea of an IoC-style external wiring scheme is definitely something that could be done via static declarative configuration, and it would be a lot easier than coding (and debugging) in the actual init process. Which is what systemd is supposed to provide, although it does so in ways that could probably be more straightforward. I'd prefer this method because I've run into situations where the normal init-script dependencies have had deadlocks that could have been prevented without re-writing the init scripts if they'd just been wired from the outside a la systemd.
Systemd does offend in one noteable area - a lot of initscripts have functions beyond the usual stop/start/restart/status functions and the systemd designers didn't allow for that. It's probably repairable. What inflamed me about systemd wasn't its handling of system init functions, it was its usurping functions outside its mandate for questionable gain.
The ls/X/ghostscript example was contrived, I'll admit. But it mirrors more than one real-world case where pulling a 150KB package has required tens of megabytes of dependencies on stuff that for my particular usage are simply dead weight.
Yes, because it does useful stuff that software needs.
That's certainly one possibility and we'll hope that it's true.
Of course, being a cynic, I could also posit the possibility that systemd is so intrusive that you can't plug-replace it and therefore all these systemd-controlled packages simply cannot opt out.
And yet, if you open up a mainframe, you will see that on the inside, it is exactly a vastly distributed system with thousands of nodes.
No it isn't. Even this latest monster doesn't have that many actual processors in it.
The main advantage to a mainframe is its ability to shovel around vast amounts of data very rapidly. IBM has offloaded a lot of the I/O work onto the peripheral data controllers ever since the System/360.
Technologically, mainframes are lagging. This is the first IBM mainframe that has had the ability to run multiple instructions at once on a single core the way Intel chips have done for many years now. The processor clock speed isn't anything outstanding for the day, either.
It really sounds a lot like the beginning of the end. There's a lot of interesting stuff that IBM has done to their big iron systems over the years, but it's pretty much stuff that didn't transport outside their own little world. Within that world, you have all sorts of interconnects, and one should never underestimate the benefits of having One Big Box when it comes to power consumption and real-estate needs, especially since IBM's reputation has always been that just because you have One Big Box doesn't mean Single-Point failure.
But in the end, I think they may simply fade away. There's no cheap way to get into the mainframe business, The closest thing to open-source is the Hercules emulator, but the licensing fees for any IBM OS release past 1986 mean that small businesses cannot leverage it. There are all sorts of specialized skills required that are no longer dime-a-dozen. Most software products and systems that run on mainframes have counterparts that run on commodity hardware and OS's - often cheaper, and considering what IBM has done to their workforce, often better supported.
So if you have lots of legacy code to support, or are willing to dedicate a lot of expensive resources to a totally-packaged system, this new box may be wonderful for you. For the computing world at large, it's likely to be hardly noticed.
That sounds like an easily-surmountable technical problem that would leave init simple and delegate this bit to a network-specific thing.
Also, at that point it's not really called a daemon anymore, it's just a program. It's like a CGI script, but for any incoming network connection.
Ah, yes, those so-popular but deadly words. "All You Have To Do Is..."
There are 2 basic approaches to working with modular systems. The old, traditional approach where each module knows what it's doing and how it interfaces with other modules. And the Inversion of Control approach, where the modules have less knowledge of what other modules do and the job of connecting and managing the interfacing.
You can further break down IoC here into the option of having one Master Control Program or a bunch of different mini-master programs. Overall, the MCP approach works better, since it is (or SHOULD be) simpler and more generalized.
The SysV init system was the traditional approach and for systems of the day, it worked fairly well. But as systems get more and more complex, you end up with more and more complex modules and the end result is that you have do things like install X and ghostscript just to run the "ls" program from a command line.
The most obvious dependency for daemons is networking. Scores of systems either have to shift operating modes or won't function at all unless the network is up (and in some cases unless certain network resources are up). But there are other dependencies as well.
So, conceptually, systemd could provide the overall service status monitoring and control facility that allows the administrator to wire together dependencies as needed instead of making every system process require detailed knowledge of every other system process. The problem is that they didn't know when to leave well enough alone and made it a "Tron-style" MCP, not a simple MCP.
Umm, installing SystemD is the trendy thing to do. Criticizing it comes from the learned wisdom of people that have been doing this for a very long time.
No, installing systemd (note caps) is unavoidable if you want to run many recent Linux distro releases such as Fedora or RHEL 7.
Personally, I've learned enough to know that I appreciate certain things it does, and that I utterly loathe other things that it does. But because it's monolithic, it's all-or-nothing.
They were clearly being sarcastic. Either way, you can decode those binary logs and shoot them as text through a pipe.
Yes, and you can put that manadatory binary data into a mandatory system where the binary logs are punched out as paper tape and then run the paper tape back into a reader when you need them.
Why complicate something when the direct approach has worked well for most people for decades? The more links in the chain, the more work it takes to get at the critical data, the fewer the tools that can work with it and the greater the possibility that critical data can be destroyed or become inaccessible,
We live in a complex and rapidly-changing world. It's never a bad idea to push a little knowledge up front. Unless you're actively working with something complex, even if you do know something about it, that knowledge may be outdated and erroneous.
I wasn't aware of W^X as a discipline. I don't have the need or the time to study it in detail. But the succinct description of what it is and what it's good for informs me that there's something out there that I might want to take advantage of someday and if I should happen to RTFA, at least I'll have a clue what it's all about.
You are a retarded idiot. The author states right at the beginning of the article that he's focusing on x86. In the (late) 80s, most people had an IBM PC, if they had anything.
"Most", maybe. But the late 1980s were the heyday of the Macintosh, Amiga and Atari ST.
Come to think of it, I'm not even sure of "most" outside the business world. The Commodore 64 and Apple computers fit in there somewhere.
This centuries motto wouldn't be a problem if idiots didn't expect us to Boldly Go - at Bargain Basement prices. And without losing any vehicles. And especially without loosing any lives.
We don't Boldly Go anymore. We stand in line with our shoes off.
Clearly these gunmen were victims, and we should not judge them for their actions. They should be rewarded for standing up against the big bad papers for printing cartoons.
This is the real irony. The Prime Commandment of Islam is that You Shall not add gods to God.
That's the reason why so much Islamic artwork is geometric or calligraphic and does not portray humans or animals. Because apparently Muslims are so weak against temptation that even the slightest glimpse of a female body will incite the faithful to uncontrollable lust and any picture or statue is a potential idol to be worshipped in place of Al-lah, The God. Even children's dolls have been made suspect, though the Prophet himself gives them a pass.
When the Prophet is portrayed, it is with his features obscured or veiled.
In other words, they treat him as a God.
And a weak God at that. Any god who needs the violence of armed men against the unarmed to protect Him is a feeble god indeed.
The Qur'an says it over and over again: God will be the judge. If you have faith that God is the all-wise, and all-powerful, you should have faith that He will take care of himself and his own and that no force on Earth can truly harm Him or those under His protection. And certainly not some silly pictures, whether ridiculing the faith or sympathizing with it. To assume the role of judge and punisher in the name of the one who can create and destroy whole worlds is an act of unspeakable arrogance. And that is true regardless of your religion.
Slashdot Mirror
The trick to the Betteridge law is that when a journalist writes a headline as a question, the question is suggesting what most people find improbable; and the improbable rarely happens.
In in the case of certain publications, where the editors want to inflame the masses by suggesting that their fondest prejudices MIGHT be true.
are thought to be there specifically so others are able to see who you are communicating with. Improving cooperation between people.
This doesn't bode well for those of us who lean autistic.
I think you got the impression that I meant that systemd "broke gnome3".
I did not. BOTH systemd AND gnome3 broke things that people were actively using. In my case, gnome3 lost me all the system-monitoring applets in the screen borders. That wasn't a matter of "learning to do things different", it was a matter of a critical day-to-day resource being taken away from me. Gnome3's failure was that it didn't offer an acceptable alternative, not that it was "different". It was, bluntly put, LESS functional for my needs than its predecessor. Nautilus angered a lot of people when its developers arrogantly removed some of the window functions, but in their case, I think after enough abuse from the user community theu put it back.
My solution for my gnome3 problems turned out to be simple. I now use the Cinnamon Desktop and the Gnome people can go twist in the wind for all I care.
The systemd issue has aroused even greater ire, however, because it's not designed to be plug-replaceable the way that GUI desktops are. You either learn to love it, suffer with it, or find an alternative distro to work with. Or an alternative OS, if you run out of acceptable distros.
I'm not one to hold to old ways just because "it's always been done that way". I've seen a LOT of changes in Linux since I started playing with it in the early 90's. I don't have any particular hatred for systemd's init subsystem, because, while I think it can evolve to be better, it's basically usable. The only real fault I could give it is that in my experience, if you're so tightly wired into external things that you become an essential part of them, that's probably not the optimal system design.
I DO have a lot against the binary logging for very good reasons. I've worked with a lot of products that did their logging in proprietary binary formats over the years, and even when the internal data formats are well-published, the mere fact that intermediary services are required to access and format them has made their respective products harder to work with.
It's rather like the Windows Registry. The Registry was created to solve several problems, some of which no longer exist even on Windows. It's widely considered to be a real mess for all sorts of reasons, which I won't bother to repeat at the moment, although, for example, restoring selected applications - and their configurations - from a backup tape are a good example. Linux, on the other hand, settled on a tree of text config files and the benefits have been immeasurable. The tree of text log files is perhaps less obviously beneficial - at least until you have to recover them off a dead disk from a foreign OS, but it does have enough weight behind it to warrant keeping for functional reasons, and not merely because it's "old fashioned".
The Emperor's clothes were new, too, but I don't want to wear a set of them.
Actually, it's the fact that systemd doesn't rotate logs that's one of my pet peeves. Unless you go in and mess around with the defaults, it's going to keep things virtually forever.
Usually what I need to know is at the tail of the active logfile. logrotate typically keeps 4 weeks of logs. I figure after a month, about the only real use that data is going to be is for the benefit of lawsuits and the NSA, as by then I'll have either fixed the issue or given up on it.
Irony. Considering how important selinux is to Red Hat, it's funny that as recently as Fedora 20, the selinux audit logs are still discrete text files. They didn't eat their own dog food.
Although that does bring up an interesting point. A consolidated log cannot be secured to "need-to-know" groups the way that discrete logs can. Red Hat also historically has been more prone than most OS's to split logs into distinct product groups instead of putting everything into one log. Maybe they thought it would be easier to work with if you didn't have 97 other product's log messages to winnow out.
Doesn't have to rewrite the entire OS.
Just enough to be cost-prohibitive.
You forgot about the 20-minute delay while it ran through every unrelated log item since January 2013.
Ooops! Bad sector in journal file. Here's the broken pieces. Good luck reading them without the missing segments.
grep foo /var/log/messages
That wasn't so hard either, was it?
Fortunately the US is likely to tell Cameron to fuck off, since it would be unconstitutional to ban encryption and after the economic damage that the NSA did they won't allow the UK to force service providers to back-door their apps.
Have you forgotten? Up to and including the Clinton years, encryption was classified as a "munition" and was very much controlled by the US Government.
users: Why is there binary logging? I cant grep anything and dont know why the system crashed. the way user switching works is a huge security hole
pottering:no ones forcing you to use it, use something else XXXXX You're an ungrateful wretch. Just pipe it out from the binary logs. No one REALLY needs logs that are directly accessible to the multitude of text utilities that Unix/Linux first became famous for.
FTFY.
I tend to grit my teeth when people say "If it ain't broke, don't fix it" about IT. IT tends to erode from the outside in, if no other way.
On the other hand, if you do "fix it", don't break things that people like and rely on. And don't have the hubris to tell people that they're wrong/misguided/old-fashioned when they complain. That's the sin that both gnome3 and systemd committed.
In other words, if you dont like it, you're free to rewrite any part of the software you want.
But what has the rabble up in arms with systemd is that that particular "freedom" means basically having to rewrite the entire operating system.
That's not what we had in mind.
To a manager "that sounds easy" = AYHTDI and they want it by 8 AM tomorrow. I realize there's a difference, but it tends to get lost in translation. One thing I've learned in IT is that things that sound simple are often harder than they look, although fortunately often stuff that seems like it would be hard turns out to be easier than expected.
The idea of an IoC-style external wiring scheme is definitely something that could be done via static declarative configuration, and it would be a lot easier than coding (and debugging) in the actual init process. Which is what systemd is supposed to provide, although it does so in ways that could probably be more straightforward. I'd prefer this method because I've run into situations where the normal init-script dependencies have had deadlocks that could have been prevented without re-writing the init scripts if they'd just been wired from the outside a la systemd.
Systemd does offend in one noteable area - a lot of initscripts have functions beyond the usual stop/start/restart/status functions and the systemd designers didn't allow for that. It's probably repairable. What inflamed me about systemd wasn't its handling of system init functions, it was its usurping functions outside its mandate for questionable gain.
The ls/X/ghostscript example was contrived, I'll admit. But it mirrors more than one real-world case where pulling a 150KB package has required tens of megabytes of dependencies on stuff that for my particular usage are simply dead weight.
Sure you can. You can roll your own.
Yes, but there's a major difference between rolling your own application and rolling your own full distro.
When you have to throw out the baby just to get rid of the bathwater, that should be troubling.
Yes, because it does useful stuff that software needs.
That's certainly one possibility and we'll hope that it's true.
Of course, being a cynic, I could also posit the possibility that systemd is so intrusive that you can't plug-replace it and therefore all these systemd-controlled packages simply cannot opt out.
So it does do one thing, and evidently it does it quite well.
No it doesn't. It does at least 2 things, one of which I most definitely don't want, and doesn't do it as well as what it replaced.
HTH: In this case, the "peripheral data controllers" are the nodes, which lie on a network. HAND.
No, I meant Channel Processors, which were stock back when networks were expensive add-ons.
Depending on the mainframe model, a channel processor might be microcode, custom hardware, or even a microprocessor.
And yet, if you open up a mainframe, you will see that on the inside, it is exactly a vastly distributed system with thousands of nodes.
No it isn't. Even this latest monster doesn't have that many actual processors in it.
The main advantage to a mainframe is its ability to shovel around vast amounts of data very rapidly. IBM has offloaded a lot of the I/O work onto the peripheral data controllers ever since the System/360.
Technologically, mainframes are lagging. This is the first IBM mainframe that has had the ability to run multiple instructions at once on a single core the way Intel chips have done for many years now. The processor clock speed isn't anything outstanding for the day, either.
It really sounds a lot like the beginning of the end. There's a lot of interesting stuff that IBM has done to their big iron systems over the years, but it's pretty much stuff that didn't transport outside their own little world. Within that world, you have all sorts of interconnects, and one should never underestimate the benefits of having One Big Box when it comes to power consumption and real-estate needs, especially since IBM's reputation has always been that just because you have One Big Box doesn't mean Single-Point failure.
But in the end, I think they may simply fade away. There's no cheap way to get into the mainframe business, The closest thing to open-source is the Hercules emulator, but the licensing fees for any IBM OS release past 1986 mean that small businesses cannot leverage it. There are all sorts of specialized skills required that are no longer dime-a-dozen. Most software products and systems that run on mainframes have counterparts that run on commodity hardware and OS's - often cheaper, and considering what IBM has done to their workforce, often better supported.
So if you have lots of legacy code to support, or are willing to dedicate a lot of expensive resources to a totally-packaged system, this new box may be wonderful for you. For the computing world at large, it's likely to be hardly noticed.
That sounds like an easily-surmountable technical problem that would leave init simple and delegate this bit to a network-specific thing.
Also, at that point it's not really called a daemon anymore, it's just a program. It's like a CGI script, but for any incoming network connection.
Ah, yes, those so-popular but deadly words. "All You Have To Do Is..."
There are 2 basic approaches to working with modular systems. The old, traditional approach where each module knows what it's doing and how it interfaces with other modules. And the Inversion of Control approach, where the modules have less knowledge of what other modules do and the job of connecting and managing the interfacing.
You can further break down IoC here into the option of having one Master Control Program or a bunch of different mini-master programs. Overall, the MCP approach works better, since it is (or SHOULD be) simpler and more generalized.
The SysV init system was the traditional approach and for systems of the day, it worked fairly well. But as systems get more and more complex, you end up with more and more complex modules and the end result is that you have do things like install X and ghostscript just to run the "ls" program from a command line.
The most obvious dependency for daemons is networking. Scores of systems either have to shift operating modes or won't function at all unless the network is up (and in some cases unless certain network resources are up). But there are other dependencies as well.
So, conceptually, systemd could provide the overall service status monitoring and control facility that allows the administrator to wire together dependencies as needed instead of making every system process require detailed knowledge of every other system process. The problem is that they didn't know when to leave well enough alone and made it a "Tron-style" MCP, not a simple MCP.
Umm, installing SystemD is the trendy thing to do. Criticizing it comes from the learned wisdom of people that have been doing this for a very long time.
No, installing systemd (note caps) is unavoidable if you want to run many recent Linux distro releases such as Fedora or RHEL 7.
Personally, I've learned enough to know that I appreciate certain things it does, and that I utterly loathe other things that it does. But because it's monolithic, it's all-or-nothing.
They were clearly being sarcastic. Either way, you can decode those binary logs and shoot them as text through a pipe.
Yes, and you can put that manadatory binary data into a mandatory system where the binary logs are punched out as paper tape and then run the paper tape back into a reader when you need them.
Why complicate something when the direct approach has worked well for most people for decades? The more links in the chain, the more work it takes to get at the critical data, the fewer the tools that can work with it and the greater the possibility that critical data can be destroyed or become inaccessible,
Just what the fuck is SystemD supposed to be?
A services manager, actually. It starts and stops services on the system, and if they go down, it optionally restarts them.
Would that it was.
It's also a horrible gratuitous ruination of the logging subsystem.
We live in a complex and rapidly-changing world. It's never a bad idea to push a little knowledge up front. Unless you're actively working with something complex, even if you do know something about it, that knowledge may be outdated and erroneous.
I wasn't aware of W^X as a discipline. I don't have the need or the time to study it in detail. But the succinct description of what it is and what it's good for informs me that there's something out there that I might want to take advantage of someday and if I should happen to RTFA, at least I'll have a clue what it's all about.
You are a retarded idiot. The author states right at the beginning of the article that he's focusing on x86. In the (late) 80s, most people had an IBM PC, if they had anything.
"Most", maybe. But the late 1980s were the heyday of the Macintosh, Amiga and Atari ST.
Come to think of it, I'm not even sure of "most" outside the business world. The Commodore 64 and Apple computers fit in there somewhere.
"Basic income" is already working in one area.
We call them "farm subsidies" - crop price support.
Somehow the nation survived.
This centuries motto wouldn't be a problem if idiots didn't expect us to Boldly Go - at Bargain Basement prices. And without losing any vehicles. And especially without loosing any lives.
We don't Boldly Go anymore. We stand in line with our shoes off.
Clearly these gunmen were victims, and we should not judge them for their actions. They should be rewarded for standing up against the big bad papers for printing cartoons.
This is the real irony. The Prime Commandment of Islam is that You Shall not add gods to God.
That's the reason why so much Islamic artwork is geometric or calligraphic and does not portray humans or animals. Because apparently Muslims are so weak against temptation that even the slightest glimpse of a female body will incite the faithful to uncontrollable lust and any picture or statue is a potential idol to be worshipped in place of Al-lah, The God. Even children's dolls have been made suspect, though the Prophet himself gives them a pass.
When the Prophet is portrayed, it is with his features obscured or veiled.
In other words, they treat him as a God.
And a weak God at that. Any god who needs the violence of armed men against the unarmed to protect Him is a feeble god indeed.
The Qur'an says it over and over again: God will be the judge. If you have faith that God is the all-wise, and all-powerful, you should have faith that He will take care of himself and his own and that no force on Earth can truly harm Him or those under His protection. And certainly not some silly pictures, whether ridiculing the faith or sympathizing with it. To assume the role of judge and punisher in the name of the one who can create and destroy whole worlds is an act of unspeakable arrogance. And that is true regardless of your religion.