For me, there is only a single mandatory piece that I have a problem with and that is the binary logging but that is easy to bypass even if I can't turn it off. For the rest of the crap such as his DHCP server or his NTP server, I have no plans to install them.
This will not be the end of Linux, it is slightly different and hasn't caused me any headaches server side and a single problem with pulseaudio (permissions problem) on my desktop running Debian testing (my laptop works fine however). It has however saved me once on the server when I accidentally typed "/etc/init.d/networking restart" instead of "nohup/etc/init.d/networking restart" Previously that would have caused the machine to terminate the script as soon as my remote console dropped without completing, leaving me without a network connection but now the command runs in the background and it just works.
When they spread misinformation? Yes. When they bring up every possible opportunity to tell the whole world how much they hate SystemD? Yes.
What pisses me off is that based on the posts I was seeing here, I started to really worry about my future as a Linux admin but then I looked for myself and discovered just how much misinformation was being passed around here.
SystemD has put in jeopardy the entire presence of Linux in the server room:
1: AFIAK, as there have been zero mention of this, SystemD appears to have had -zero- formal code testing, auditing, or other assurance that it is stable. It was foisted on people in RHEL 7 and downstreams with no ability to transition to it.
Formal code testing is pretty much what Redhat brings to the table.
2: It breaks applications that use the init.d mechanism to start with. This is very bad, since some legacy applications can not be upgraded. Contrast that to AIX where in some cases, programs written back in 1991 will run without issue on AIX 7.1. Similar with Solaris.
At worst it breaks their startup scripts, and since they are shell scripts they are easy to fix.
3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions. It does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing... and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes a solid program. Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has multiple daemons to separate privs, unlike SystemD.
Do you really understand the architecture of either SystemD or sendmail? Sendmail was a single binary written in a time before anyone cared about security. I don't recall sendmail being a bundle programs but then it's been a decade since I stopped using it precisely because of it's poor security track record. Contrary to your FUD, Systemd runs things as separate daemons with each component using the least amount of privileges needed to do it's job and on top of that many of the network services (ntp, dhcpd) that people complain about are completely optional addons and quite frankly, since they seem designed around the single purpose of Linux containers, I have not installed them. This is a basic FAQ entry on the systemd web site so I really don't get how you didn't know this.
4: SystemD cannot be worked around. The bash hole, I used busybox to fix. If SystemD breaks, since it encompasses everything including the bootloader, it can't be replaced. At best, the system would need major butchery to work. In the enterprise, this isn't going to happen, and the Linux box will be "upgraded" to a Windows or Solaris box.
Unlikely, it is a minority of malcontents who are upset about SystemD who have created an echo chamber of half truths and outright lies. Anyone who needs to get work done will not even notice the transition.
5: SystemD replaces many utilities that have stood 20+ years of testing, and takes a step back in security by the monolithic userland and untested code. Even AIX with its ODM has at least seen certification under FIPS, Common Criteria, and other items.
Again you use the word "monolitic without having a shred of knowledge about how SystemD works.The previous init system despite all of it's testing was a huge mess. There is a reason there were multiple projects that came before SystemD that tried to clean up the horrific mess that was the previous init.
6: SystemD has no real purpose, other than ego. The collective response justifying its existence is, "because we say so. Fuck you and use it." Well, this is no way to treat enterprise customers. Enterprise customers can easily move to Solaris if push comes to shove, and Solaris has a very good record of security, without major code added without actual testing being done, and a way to be compatible. I can turn Solaris 11's root role into a user, for example.
Solaris has already transitioned to it's own equivalent daemon that does roughly what SystemD does. As for SystemD: It all
I think the big issue is the potential to use this as a vector to introduce malware to the phone or PC the owner interfaces the device with. Not sure how practical that is.
The big issue will be that people will use this to display rude things on random people's armbands.
You want to bet that number subtracts the cost of their network build out from the profit margins? The bulk of the costs are the labour and equipment needed to run the fiber. Once the fiber is in place, upgrades are just a matter of swapping out the equipment at both ends and the costs will drop sharply.
They are making money, it's just that internet is less of a profit center than wireless so they would rather put the money where they can make the higher profit.
Your plan falls apart when you have large groups of people who are willing to believe literally anything about some group they don't like and refuse to accept any evidence that they are wrong.
The number of people who believe Obama will bring in Sharia law or has the national guard preparing internment camps is outright staggering.
That's pretty interesting considering it was designed for servers to begin with. Servers are far more likely to have weird dependencies on boot such as root drive over the network or worse yet, boot drive over clustered file system over the network and where Debian said they are losing share due to not being able to support some of the larger server configurations.
For the embedded space, it either uses less memory than the current setup, or you are rolling your own init and don't care about systemd at all.
PfSense is a must if you are running ESXi topologies.
SystemD hatred is pretty simple. A large amount of untested, potentially unsecure, unaudited code was placed at the core of Linux's userland, and forced on end users (enterprise IT shops) without any real testing or feedback by end users.
RedHat has bet the farm on SystemD... if/when it has security issues (it has network connections, so in theory, it can be remote rooted), it can cause a mass flight from RHEL and downstreams. The gain? Little to none, from the end user point of view.
I am keeping fingers crossed, and hoping someone forks the cash for an audit of the code... Oracle and Microsoft are waiting in the wings for mainstream Linux distros to fall on their face if something does break.
You do realize that most of the systemd addon daemons run 1. As a completely separate process 2. With the minimum permissions need to do their job. 3. The stuff with network connections are definitely optional..
I know they have some network things that they optimized for containers but they don't seem general purpose so I don't run any of them on the servers I'm testing systemd on. So far the only actual Systemd issue I've had is that it screws up pulse audio on one of my machines (works fine on the laptop screws up on my desktop).
Plenty of performance and memory, never any issues. It makes me wonder why more router manufacturers don't use Linux or BSD derivatives for their firmware instead of writing garbage in-house.
Mainly because the market is very price sensitive and as a result routers tend to use some slow SOC with a minimal amount of RAM because it costs less. Linux or BSD wouldn't do you much good if every time someone fires up bittorrent, the NAT table fills because there just isn't enough RAM to handle it all. It has only been recently that I've seen routers with a decent amount of ram and even then that has been in the $150+ range while most people I know refer to spend $30 to $40.
A few years back my friend went to get his BMW from my garage where he had left it for the winter only to find a flat tire waiting. I thought "no problem" we can just use the spare just as my father taught me. We pull the jack out that came with the car and attempted to jack the car up but the jack actually started to collapse under the weight of the car. At that point we gave up and called CAA and when the guy arrives says "why did you guys try to do this yourselves?" It seems the jack was mostly decorative.
Throw in modern cars with diagnostic readouts proprietary to the car and you find a car that is simply not designed to be repaired by anyone other than the dealership so don't blame training or our generation for the problem.
You might want to reread that. It's not supporting it, it is just ignoring the certificate error and indexing the site anyways. On the plus side it will work by accident as long as you don't tell apache to redirect to an error page on SNI failure. So it's mostly good news.
That said, GP nails it: the problem with SSL is not the tech, it's the that the CAs are money grubbing semi-competent boobs, and the trusted certificate lists are administered by either OS or browser producers leaving a huge open arena for politics and perverse incentives.
Which is why it was really sad when chrome backed off on supporting DANE
Uh no, the Linux kernel is monolithic because it runs the drivers as if they were a part of the kernel rather than running the drivers as separate processes.
It isn't in the actual init system, it is an optional daemon that uses the interfaces that systemd exports so there is nothing that actually forces anyone to use it. My Debian based firewall runs systemd with unbound without any problem.
Did it actually not boot or did it seem to hang and the guy resets it after a minute? I ask because my PC had exactly this problem. Ages ago I had a drive die in my system so I pulled it but missed one of the references in/etc/fstab and when I did the initial conversion to systemd it hung and I was about to pull my hear out but instead I left the room to clear my head and came back several minutes later to find my system booted with no explanation as to why the delay.
The systemd update a few weeks ago finally gave me a nice message on console to let me know that one of my fstab entries was timing out so I checked, found the entry and now everything boots faster.
And the criticism from those who are against systemd is extremely important to consider. The complaints are very sound, from a technological perspective. They're also based on decades of real world experience, which just cannot be ignored.
I'm not a total fan of every design feature of everything systemd has done but gave you actually read their supporting references? I'm most of the cases boycottsystemd has rephrased events to make the systemd folks look as bad as possible in ways that would make a Fox news reporter feel proud. A good example is their comment about requiring "bug for bug" compatibility with glibc was instead a use of a certain non posix flag needed for thread safety and complaining that it is tightly tied to Linux is about as helpful as complaining that udev is tightly tied to Linux.
At any rate, I find it very telling that they don't actually mention any of their supporters.
64bit... again, bragging points about how many bits you use, no functional difference to anyone. Its like when I gave the 32 bit version of Visual Studio to a colleague and he complained that he wanted the 64 bit version.... there is no 64 bit version because it isn't needed. Its just the typical knee-jerk reaction that 64 bits is somehow essential for everything, not just those programs that really do require it.
Not entirely true, x86 was famously register starved meaning you had to spend a lot of time swapping things into and out of the general purpose registers. When AMD designed the 64 bit extensions, they doubled the number of registers to 16 total, meaning software could spend less time moving things around and more time actually doing something useful.
If gimp pulls in systemd libs then a bug should be filed there. There is no technical requirement it needs to be that way according to the gnome folks.
During that "lengthly consultation process", nearly all of the for systemd was based on the advantages that systemd, as an init system, offer over competing init systems. In the months since Debian committed to systemd, Poettering has been increasingly vocal that he wants systemd to be more than an init system. That is why there is a renewed call for debate.
This is what I mean by reading things for yourself. I've been reading about his plans but you are mistaking the systemd init system with the overall collections of things he is working on. It's not as if the high speed DHCP daemon he has just written will end up in PID 1. His proposals so far is that there will be more optional daemons that either work better and at some point in the future I wouldn't be shocked if there were to be a debate over whether his addons should replace existing daemons but we aren't there yet.
You do not have to install gnome3 on Debian, I don't. As for systemd, I suggest looking through Debian's extensive documentation detailing why they chose systemd over the alternatives. At any rate the time to argue systemd was last year when Debian had a very lengthily consultation process. I also suggest looking up the systemd documentation for yourself considering the huge amount of FUD being spread about it and I find it telling that neither the Debian fork website nor the boycott systemd websites don't actually name any of their supporters.
1. OpenBSD supports laptops, specifically Thinkpads, better than any other operating system not called Windows. Suspend/resume works, instantly.
That's less of a good thing considering how nasty Lenovo is to work with. Not only did they continue locking their mini pcie port against "unauthorized" wifi cards, they have double downed on their customer hating behaviour by refusing to charge third party batteries. Since that was written, they seem to have moved the enforcement into the firmware.
This is news to me. My main PC (debian jessie) has four cifs mounts on startup and they all come up with no trouble. The only systemd issue I've had so far was a minute and a half hang on startup that I couldn't spot but that was fixed by the latest debian update making the startup process actually tell me what it was doing. Turns out I had a swap entry in/etc/fstab from an old drive I removed ages ago and systemd was giving it a full 90 seconds in case it was slow to initialize rather than not there.
Slashdot Mirror
For me, there is only a single mandatory piece that I have a problem with and that is the binary logging but that is easy to bypass even if I can't turn it off. For the rest of the crap such as his DHCP server or his NTP server, I have no plans to install them.
This will not be the end of Linux, it is slightly different and hasn't caused me any headaches server side and a single problem with pulseaudio (permissions problem) on my desktop running Debian testing (my laptop works fine however). It has however saved me once on the server when I accidentally typed "/etc/init.d/networking restart" instead of "nohup /etc/init.d/networking restart" Previously that would have caused the machine to terminate the script as soon as my remote console dropped without completing, leaving me without a network connection but now the command runs in the background and it just works.
When they spread misinformation? Yes. When they bring up every possible opportunity to tell the whole world how much they hate SystemD? Yes.
What pisses me off is that based on the posts I was seeing here, I started to really worry about my future as a Linux admin but then I looked for myself and discovered just how much misinformation was being passed around here.
Who modded this up?
SystemD has put in jeopardy the entire presence of Linux in the server room:
1: AFIAK, as there have been zero mention of this, SystemD appears to have had -zero- formal code testing, auditing, or other assurance that it is stable. It was foisted on people in RHEL 7 and downstreams with no ability to transition to it.
Formal code testing is pretty much what Redhat brings to the table.
2: It breaks applications that use the init.d mechanism to start with. This is very bad, since some legacy applications can not be upgraded. Contrast that to AIX where in some cases, programs written back in 1991 will run without issue on AIX 7.1. Similar with Solaris.
At worst it breaks their startup scripts, and since they are shell scripts they are easy to fix.
3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions. It does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing... and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes a solid program. Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has multiple daemons to separate privs, unlike SystemD.
Do you really understand the architecture of either SystemD or sendmail? Sendmail was a single binary written in a time before anyone cared about security. I don't recall sendmail being a bundle programs but then it's been a decade since I stopped using it precisely because of it's poor security track record. Contrary to your FUD, Systemd runs things as separate daemons with each component using the least amount of privileges needed to do it's job and on top of that many of the network services (ntp, dhcpd) that people complain about are completely optional addons and quite frankly, since they seem designed around the single purpose of Linux containers, I have not installed them. This is a basic FAQ entry on the systemd web site so I really don't get how you didn't know this.
4: SystemD cannot be worked around. The bash hole, I used busybox to fix. If SystemD breaks, since it encompasses everything including the bootloader, it can't be replaced. At best, the system would need major butchery to work. In the enterprise, this isn't going to happen, and the Linux box will be "upgraded" to a Windows or Solaris box.
Unlikely, it is a minority of malcontents who are upset about SystemD who have created an echo chamber of half truths and outright lies. Anyone who needs to get work done will not even notice the transition.
5: SystemD replaces many utilities that have stood 20+ years of testing, and takes a step back in security by the monolithic userland and untested code. Even AIX with its ODM has at least seen certification under FIPS, Common Criteria, and other items.
Again you use the word "monolitic without having a shred of knowledge about how SystemD works.The previous init system despite all of it's testing was a huge mess. There is a reason there were multiple projects that came before SystemD that tried to clean up the horrific mess that was the previous init.
6: SystemD has no real purpose, other than ego. The collective response justifying its existence is, "because we say so. Fuck you and use it." Well, this is no way to treat enterprise customers. Enterprise customers can easily move to Solaris if push comes to shove, and Solaris has a very good record of security, without major code added without actual testing being done, and a way to be compatible. I can turn Solaris 11's root role into a user, for example.
Solaris has already transitioned to it's own equivalent daemon that does roughly what SystemD does.
As for SystemD: It all
I think the big issue is the potential to use this as a vector to introduce malware to the phone or PC the owner interfaces the device with. Not sure how practical that is.
The big issue will be that people will use this to display rude things on random people's armbands.
You want to bet that number subtracts the cost of their network build out from the profit margins? The bulk of the costs are the labour and equipment needed to run the fiber. Once the fiber is in place, upgrades are just a matter of swapping out the equipment at both ends and the costs will drop sharply.
They are making money, it's just that internet is less of a profit center than wireless so they would rather put the money where they can make the higher profit.
Your plan falls apart when you have large groups of people who are willing to believe literally anything about some group they don't like and refuse to accept any evidence that they are wrong.
The number of people who believe Obama will bring in Sharia law or has the national guard preparing internment camps is outright staggering.
That's pretty interesting considering it was designed for servers to begin with. Servers are far more likely to have weird dependencies on boot such as root drive over the network or worse yet, boot drive over clustered file system over the network and where Debian said they are losing share due to not being able to support some of the larger server configurations.
For the embedded space, it either uses less memory than the current setup, or you are rolling your own init and don't care about systemd at all.
PfSense is a must if you are running ESXi topologies.
SystemD hatred is pretty simple. A large amount of untested, potentially unsecure, unaudited code was placed at the core of Linux's userland, and forced on end users (enterprise IT shops) without any real testing or feedback by end users.
RedHat has bet the farm on SystemD... if/when it has security issues (it has network connections, so in theory, it can be remote rooted), it can cause a mass flight from RHEL and downstreams. The gain? Little to none, from the end user point of view.
I am keeping fingers crossed, and hoping someone forks the cash for an audit of the code... Oracle and Microsoft are waiting in the wings for mainstream Linux distros to fall on their face if something does break.
You do realize that most of the systemd addon daemons run
1. As a completely separate process
2. With the minimum permissions need to do their job.
3. The stuff with network connections are definitely optional..
I know they have some network things that they optimized for containers but they don't seem general purpose so I don't run any of them on the servers I'm testing systemd on. So far the only actual Systemd issue I've had is that it screws up pulse audio on one of my machines (works fine on the laptop screws up on my desktop).
Plenty of performance and memory, never any issues. It makes me wonder why more router manufacturers don't use Linux or BSD derivatives for their firmware instead of writing garbage in-house.
Mainly because the market is very price sensitive and as a result routers tend to use some slow SOC with a minimal amount of RAM because it costs less. Linux or BSD wouldn't do you much good if every time someone fires up bittorrent, the NAT table fills because there just isn't enough RAM to handle it all. It has only been recently that I've seen routers with a decent amount of ram and even then that has been in the $150+ range while most people I know refer to spend $30 to $40.
A few years back my friend went to get his BMW from my garage where he had left it for the winter only to find a flat tire waiting. I thought "no problem" we can just use the spare just as my father taught me. We pull the jack out that came with the car and attempted to jack the car up but the jack actually started to collapse under the weight of the car. At that point we gave up and called CAA and when the guy arrives says "why did you guys try to do this yourselves?" It seems the jack was mostly decorative.
Throw in modern cars with diagnostic readouts proprietary to the car and you find a car that is simply not designed to be repaired by anyone other than the dealership so don't blame training or our generation for the problem.
You might want to reread that. It's not supporting it, it is just ignoring the certificate error and indexing the site anyways. On the plus side it will work by accident as long as you don't tell apache to redirect to an error page on SNI failure. So it's mostly good news.
Bing and Yahoo's web crawlers do not support SNI so you can enable it as long as you don't mind not being indexed on some search engines.
That said, GP nails it: the problem with SSL is not the tech, it's the that the CAs are money grubbing semi-competent boobs, and the trusted certificate lists are administered by either OS or browser producers leaving a huge open arena for politics and perverse incentives.
Which is why it was really sad when chrome backed off on supporting DANE
Uh no, the Linux kernel is monolithic because it runs the drivers as if they were a part of the kernel rather than running the drivers as separate processes.
It isn't in the actual init system, it is an optional daemon that uses the interfaces that systemd exports so there is nothing that actually forces anyone to use it. My Debian based firewall runs systemd with unbound without any problem.
Did it actually not boot or did it seem to hang and the guy resets it after a minute? I ask because my PC had exactly this problem. Ages ago I had a drive die in my system so I pulled it but missed one of the references in /etc/fstab and when I did the initial conversion to systemd it hung and I was about to pull my hear out but instead I left the room to clear my head and came back several minutes later to find my system booted with no explanation as to why the delay.
The systemd update a few weeks ago finally gave me a nice message on console to let me know that one of my fstab entries was timing out so I checked, found the entry and now everything boots faster.
And the criticism from those who are against systemd is extremely important to consider. The complaints are very sound, from a technological perspective. They're also based on decades of real world experience, which just cannot be ignored.
I'm not a total fan of every design feature of everything systemd has done but gave you actually read their supporting references? I'm most of the cases boycottsystemd has rephrased events to make the systemd folks look as bad as possible in ways that would make a Fox news reporter feel proud. A good example is their comment about requiring "bug for bug" compatibility with glibc was instead a use of a certain non posix flag needed for thread safety and complaining that it is tightly tied to Linux is about as helpful as complaining that udev is tightly tied to Linux.
At any rate, I find it very telling that they don't actually mention any of their supporters.
64bit... again, bragging points about how many bits you use, no functional difference to anyone. Its like when I gave the 32 bit version of Visual Studio to a colleague and he complained that he wanted the 64 bit version.... there is no 64 bit version because it isn't needed. Its just the typical knee-jerk reaction that 64 bits is somehow essential for everything, not just those programs that really do require it.
Not entirely true, x86 was famously register starved meaning you had to spend a lot of time swapping things into and out of the general purpose registers. When AMD designed the 64 bit extensions, they doubled the number of registers to 16 total, meaning software could spend less time moving things around and more time actually doing something useful.
Systemd will forward to syslogd if you want it to so you can still use your standard tools to view the logs if you want.
If gimp pulls in systemd libs then a bug should be filed there. There is no technical requirement it needs to be that way according to the gnome folks.
During that "lengthly consultation process", nearly all of the for systemd was based on the advantages that systemd, as an init system, offer over competing init systems. In the months since Debian committed to systemd, Poettering has been increasingly vocal that he wants systemd to be more than an init system. That is why there is a renewed call for debate.
This is what I mean by reading things for yourself. I've been reading about his plans but you are mistaking the systemd init system with the overall collections of things he is working on. It's not as if the high speed DHCP daemon he has just written will end up in PID 1. His proposals so far is that there will be more optional daemons that either work better and at some point in the future I wouldn't be shocked if there were to be a debate over whether his addons should replace existing daemons but we aren't there yet.
You do not have to install gnome3 on Debian, I don't. As for systemd, I suggest looking through Debian's extensive documentation detailing why they chose systemd over the alternatives. At any rate the time to argue systemd was last year when Debian had a very lengthily consultation process. I also suggest looking up the systemd documentation for yourself considering the huge amount of FUD being spread about it and I find it telling that neither the Debian fork website nor the boycott systemd websites don't actually name any of their supporters.
1. OpenBSD supports laptops, specifically Thinkpads, better than any other operating system not called Windows. Suspend/resume works, instantly.
That's less of a good thing considering how nasty Lenovo is to work with. Not only did they continue locking their mini pcie port against "unauthorized" wifi cards, they have double downed on their customer hating behaviour by refusing to charge third party batteries. Since that was written, they seem to have moved the enforcement into the firmware.
Legacy? 5 years ago we had to interface with a bank who used XML with EBCDIC fields.
This is news to me. My main PC (debian jessie) has four cifs mounts on startup and they all come up with no trouble. The only systemd issue I've had so far was a minute and a half hang on startup that I couldn't spot but that was fixed by the latest debian update making the startup process actually tell me what it was doing. Turns out I had a swap entry in /etc/fstab from an old drive I removed ages ago and systemd was giving it a full 90 seconds in case it was slow to initialize rather than not there.