The hate is real (and has been discussed to death already), but the list of alternatives is depressingly small. Linux Distros are a necessary component of the Linux ecosystem with updates and fixes. If the options are between a distro with an init system you don't like, or some obscure/niche distro which doesn't have extended support options, the decision has been made for you. And unfortunately systemd has reached that level of penetration.
And THAT is why additional distros coming along without systemd is newsworthy... (Well, by slashdot standards I guess).
Honestly, in today's world of 1080p monitors, why does 'ss' default to trying fill my screen horizontally and padding the fields out accordingly?
And when I say "by default", I mean "external hacks are required to stop it". Use "ss | cat" to make it better.
Otherwise I find the rest of iproute2 to be good. It's a necessity in today's Linux IP stack with network namespaces, policy routing, and other advanced routing decisions like preferring a specific IP address for outbound traffic.
I agree intermittently with other people. Though the new tool needs to be installed by default, the old tool shouldn't be thrown away just because there's something newer. "New" doesn't mean "better". (Lately that's been increasingly true)
"What matters" varies from person to person. These things have impressive endurance for their sizes and consistent low latency. There are uses for that.
I don't need them, but I'm sure someone else does. Let them buy it and go grab a 950 for yourself.
Again, wrong. RAID-2 might have ECC, but mdadm doesn't support it. You got RAID-1, 5 and 6 (4 is identical to 5 with parity being distributed rather than on a single disk). But that's not a checksum, it's parity. It recovers from a drive outright failing, not from errors returning incorrect data but not detected as bad. I have seen it happen. RAID-5 can only tell you there's an inconsistency, not which disk has the bad data. The RAID controller's consistency check usually just updates the parity under the assumption that parity is at fault if that happens.
Oh it can be "checked" by RAID controllers. The question is, how do you know which copy is correct? In the case of a RAID-1, if the 2 disks don't have identical data, which do you assume is the right data? ZFS has checksums to figure out which is right. MDADM doesn't.
And if there is an API to allow you to ask for data from a specific disk rather than letting the RAID driver pick one, I'm interested.
Yes, there is a lot of duplicated code in ZFS for Linux, such as an SHA256 implementation, RAID parity, compression, and lately a whole crypto library.
The reason is either the kernel doesn't reliably support this natively or the implementation isn't usable. Linux doesn't allow non-GPL modules to access a lot of features (eg: the crypto library) or some features are version-specific (eg: LZ4 (de)compressor). The simplest solution is to import the Solaris versions.
But they've improved. SSE and AVX instructions are available for many of the above. And if ZFS does get re-licensed to GPL, then sure maybe we can make use of some of that stuff natively. Until then, ZFS on Linux has to deal with the reality of a non-GPL non-Linux driver on a GPL Linux kernel.
ZFS manages the whole stack for a reason. Its first priority is data safety. With checksums everywhere it can detect corruption and repair it.
That last bit is important. If ZFS doesn't have a way to put its hands into the RAID, it can't attempt to rebuild known corrupted data. Until mdadm and hardware RAID controllers allow you to issue a "read, but try to give a different result" operation you can't do this. (Said operation would attempt to use parity even on a healthy array in an attempt to give a different block content by pretending a disk is dead). BTRFS does the same thing as ZFS - handles the RAID internally, and can repair corruption all on its own.
And yes, "first priority" means exactly that. ZFS has some design decisions that negatively affect performance in the name of data protection.
Muting's not good enough. As someone with a slow(-ish) internet connection with a meter on it, why am I being forced to download and play a video I clearly don't want?
As a tendency hardware H.264 encoding is inferior in terms of quality and bitrate compared to software encoding, even when comparing high quality hardware settings to medium quality software. H.265 will likely continue this trend, especially this early in its life relative to H.264.
I expect that big names like Netflix, Apple, etc are going to want to serve video in high quality and are willing to put up the resources for that quality improvement, which is what this article is talking about.
No, wrong problem. DKIM and SPF are to prevent joe jobs where someone sends email address faked to be sent from you as a malicious act. This is about a user whose email address is the recipient resulting from (presumably) user incompetence.
No, logs are preserved by shipping them off to another system over the network. Binary logs are harder to forge, but not impossible. Faking wtmp entries is a thing, for example.
The original question I replied to stated they were thinking about IoT devices and embedded systems like routers. There tends to not be many officially supported distros for those kinds of markets, rendering everyone's discussion on distro support policies moot.
If the password in question is required to login to the system in the first place, you have a chicken-and-egg problem. External devices like cellphones and post-its are the workaround, sure, but look which one people choose.
I've been using unix (ie. only Linux but we'll pretend that counts) for over 15 years now. Not quite the "old" you may think of but old enough.
I gave systemd a try. It actively fought me and I cannot accept that. It has too much of a "my way or the highway" mentality that you just can't fix without major C hacking and recompiling. If you don't like its way of doing things then too bad.
sysvinit scripts may be slower to boot and have fewer automatic/behinds-the-scenes features you want, but I can make any arbitrary change to them with minimal effort. I can run them with line-by-line tracing using "set -x" and find out exactly why it's hanging. I can rescue it with *any* install media even if it doesn't have systemd and '/etc/init.d/servicename start' will actually work.
systemd is fine for desktops run by people who think Firefox is the only app they really need to Surf The Net. sysvinit is designed for people who want control of their systems and want to be able to inspect what it's doing. And I'm sorry, I NEED the latter to do my job properly.
Remember back when IE 6 refused to die because corporations had ActiveX stuff that prevented upgrading? NPAPI has become like that as well. I can't upgrade because I have apps that run as Java applets and I'll lose them. I already can't use Chrome...
So, here's to vendors migrating away from Java and issuing updates I guess...
(And I find it ironic that Flash gets some kind of exception even though even Adobe wants it dead.)
It does require root if you want it to run a private port 80/443 service to do the authentication for you and/or to install the certificate into your apache config on your behalf. A nice feature for less capable users (ain't that a scary though)
But if you are using an existing web server and are okay with manual certificate installation/configuration and have a long command-line full of path overrides (eg. no using/etc for storing the generated certs) then it runs just fins as a normal user. I did it during the closed beta.
There's a few other little kinks to worry about like reloading apache on an updated certificate but I think you're capable of dealing with that.
I hate to reply to myself, but I realized a technical error or two. You can use/dev as tmpfs with extra effort, but if you read systemd's standpoint on containers they talk about dropping mknod support being discourage/unsupported. Unprivileged containers aren't allowed to use mknod so that's already out the window.
It's not a matter of the init scripts. It's not that my apps are not compatible with systemd. Systemd is not compatible with my system.
Systemd depends on features which I can't give it in my environment. My environment is an unprivileged container. In this environment you CANNOT have use of prctl for security isolation (kinda sucks, yeah), you CANNOT have/dev as a tmpfs, and you CANNOT have access to the control groups at the kind of granularity. Systemd will not work without these features - I've tried. Were this a sysvinit system I'd just edit the init script to remove the bits I don't need. With systemd I need to recompile a binary and deal with the troubleshooting that results.
Now, these are based on my usage of CentOS 7 which is already 2 years old on top of the release delays. I'm sure newer versions make the situation better. But at this very moment systemd has made a VERY bad first impression (there's more, but I'm not going to go into that) and left me with no practical solution. All the other things like "binary logging" just make me even more irritated.
I keep saying it, systemd not an init system. KDE and GNOME should not depend on an init system. Why does the desktop care who's booted it up?
More specifically, systemd is Linux-only. The devs have explicitly stated that they are making good use of Linux-specific features. Fine, but if third party software becomes dependent on it then that implies they won't work on *BSD at all. Right? So now there's no Gnome or KDE on anything but Linux.
So really, choice is being taken away clear across the board. Either that or I'm missing something really big which implies systemd is not a strict dependency.
Busybox is also a pretty weak substitute for most of these applications. Reduced command-line options, fewer features, terse output, etc.
But on a system where memory is limited - even moreso than a Raspberry Pi, for example - this is an advantage. You could put busybox into an emergency recovery boot ramdisk and be able to work reasonable well. That's the objective - it's small and used in specific situations only. If you don't need it, good for you.
As someone already said most servers don't actually use busybox day to day. It's available in the event something goes wrong and you need it.
My own impressions of 5.0 haven't been too good. The lockscreen doesn't give you the unlock input (eg: PIN) without pushing a button to ask for it, the animations have been stepped up -- the kinds of animations you can't turn off from the Dev menu -- and it generally looks copmletely childish. That's not what I personally want.
If you're running 4.4 check out all the new Google apps from the store. That's what you're getting from Lollipop, but also with the launcher, etc. No. No no no. I uninstalled the gmail update as fast as I could.
This is the trend in tech - things become more colourful, flat and generally dumbed down. I don't mean dumbed down from a user knowledge point of view, I mean "UI designed in MS Paint" down.
In the embedded scenario the owner retains control. Frankly said owner should simply disallow embedding and let the embedder look like an idiot until they realize what they did.
Slashdot Mirror
I disagree.
The hate is real (and has been discussed to death already), but the list of alternatives is depressingly small. Linux Distros are a necessary component of the Linux ecosystem with updates and fixes. If the options are between a distro with an init system you don't like, or some obscure/niche distro which doesn't have extended support options, the decision has been made for you. And unfortunately systemd has reached that level of penetration.
And THAT is why additional distros coming along without systemd is newsworthy... (Well, by slashdot standards I guess).
Honestly, in today's world of 1080p monitors, why does 'ss' default to trying fill my screen horizontally and padding the fields out accordingly?
And when I say "by default", I mean "external hacks are required to stop it". Use "ss | cat" to make it better.
Otherwise I find the rest of iproute2 to be good. It's a necessity in today's Linux IP stack with network namespaces, policy routing, and other advanced routing decisions like preferring a specific IP address for outbound traffic.
I agree intermittently with other people. Though the new tool needs to be installed by default, the old tool shouldn't be thrown away just because there's something newer. "New" doesn't mean "better". (Lately that's been increasingly true)
"What matters" varies from person to person. These things have impressive endurance for their sizes and consistent low latency. There are uses for that.
I don't need them, but I'm sure someone else does. Let them buy it and go grab a 950 for yourself.
Can confirm, I got the same thing. And I haven't used a startcom cert in several years now.
Again, wrong. RAID-2 might have ECC, but mdadm doesn't support it. You got RAID-1, 5 and 6 (4 is identical to 5 with parity being distributed rather than on a single disk). But that's not a checksum, it's parity. It recovers from a drive outright failing, not from errors returning incorrect data but not detected as bad. I have seen it happen. RAID-5 can only tell you there's an inconsistency, not which disk has the bad data. The RAID controller's consistency check usually just updates the parity under the assumption that parity is at fault if that happens.
Oh it can be "checked" by RAID controllers. The question is, how do you know which copy is correct? In the case of a RAID-1, if the 2 disks don't have identical data, which do you assume is the right data? ZFS has checksums to figure out which is right. MDADM doesn't.
And if there is an API to allow you to ask for data from a specific disk rather than letting the RAID driver pick one, I'm interested.
Yes, there is a lot of duplicated code in ZFS for Linux, such as an SHA256 implementation, RAID parity, compression, and lately a whole crypto library.
The reason is either the kernel doesn't reliably support this natively or the implementation isn't usable. Linux doesn't allow non-GPL modules to access a lot of features (eg: the crypto library) or some features are version-specific (eg: LZ4 (de)compressor). The simplest solution is to import the Solaris versions.
But they've improved. SSE and AVX instructions are available for many of the above. And if ZFS does get re-licensed to GPL, then sure maybe we can make use of some of that stuff natively. Until then, ZFS on Linux has to deal with the reality of a non-GPL non-Linux driver on a GPL Linux kernel.
That last bit is important. If ZFS doesn't have a way to put its hands into the RAID, it can't attempt to rebuild known corrupted data. Until mdadm and hardware RAID controllers allow you to issue a "read, but try to give a different result" operation you can't do this. (Said operation would attempt to use parity even on a healthy array in an attempt to give a different block content by pretending a disk is dead). BTRFS does the same thing as ZFS - handles the RAID internally, and can repair corruption all on its own.
And yes, "first priority" means exactly that. ZFS has some design decisions that negatively affect performance in the name of data protection.
Muting's not good enough. As someone with a slow(-ish) internet connection with a meter on it, why am I being forced to download and play a video I clearly don't want?
As a tendency hardware H.264 encoding is inferior in terms of quality and bitrate compared to software encoding, even when comparing high quality hardware settings to medium quality software. H.265 will likely continue this trend, especially this early in its life relative to H.264.
I expect that big names like Netflix, Apple, etc are going to want to serve video in high quality and are willing to put up the resources for that quality improvement, which is what this article is talking about.
No, wrong problem. DKIM and SPF are to prevent joe jobs where someone sends email address faked to be sent from you as a malicious act. This is about a user whose email address is the recipient resulting from (presumably) user incompetence.
No, logs are preserved by shipping them off to another system over the network. Binary logs are harder to forge, but not impossible. Faking wtmp entries is a thing, for example.
The original question I replied to stated they were thinking about IoT devices and embedded systems like routers. There tends to not be many officially supported distros for those kinds of markets, rendering everyone's discussion on distro support policies moot.
There is. 2.6.32 had around 6 years of support. Looks like 3.16 will be supported until 2020. Longer would be nice, sure, but 5-6 years for long term seems reasonable for a not-paying-for-it product.
If the password in question is required to login to the system in the first place, you have a chicken-and-egg problem. External devices like cellphones and post-its are the workaround, sure, but look which one people choose.
I've been using unix (ie. only Linux but we'll pretend that counts) for over 15 years now. Not quite the "old" you may think of but old enough.
I gave systemd a try. It actively fought me and I cannot accept that. It has too much of a "my way or the highway" mentality that you just can't fix without major C hacking and recompiling. If you don't like its way of doing things then too bad.
sysvinit scripts may be slower to boot and have fewer automatic/behinds-the-scenes features you want, but I can make any arbitrary change to them with minimal effort. I can run them with line-by-line tracing using "set -x" and find out exactly why it's hanging. I can rescue it with *any* install media even if it doesn't have systemd and '/etc/init.d/servicename start' will actually work.
systemd is fine for desktops run by people who think Firefox is the only app they really need to Surf The Net. sysvinit is designed for people who want control of their systems and want to be able to inspect what it's doing. And I'm sorry, I NEED the latter to do my job properly.
Remember back when IE 6 refused to die because corporations had ActiveX stuff that prevented upgrading? NPAPI has become like that as well. I can't upgrade because I have apps that run as Java applets and I'll lose them. I already can't use Chrome...
So, here's to vendors migrating away from Java and issuing updates I guess...
(And I find it ironic that Flash gets some kind of exception even though even Adobe wants it dead.)
It does require root if you want it to run a private port 80/443 service to do the authentication for you and/or to install the certificate into your apache config on your behalf. A nice feature for less capable users (ain't that a scary though)
But if you are using an existing web server and are okay with manual certificate installation/configuration and have a long command-line full of path overrides (eg. no using /etc for storing the generated certs) then it runs just fins as a normal user. I did it during the closed beta.
There's a few other little kinks to worry about like reloading apache on an updated certificate but I think you're capable of dealing with that.
I hate to reply to myself, but I realized a technical error or two. You can use /dev as tmpfs with extra effort, but if you read systemd's standpoint on containers they talk about dropping mknod support being discourage/unsupported. Unprivileged containers aren't allowed to use mknod so that's already out the window.
It's not a matter of the init scripts. It's not that my apps are not compatible with systemd. Systemd is not compatible with my system.
Systemd depends on features which I can't give it in my environment. My environment is an unprivileged container. In this environment you CANNOT have use of prctl for security isolation (kinda sucks, yeah), you CANNOT have /dev as a tmpfs, and you CANNOT have access to the control groups at the kind of granularity. Systemd will not work without these features - I've tried. Were this a sysvinit system I'd just edit the init script to remove the bits I don't need. With systemd I need to recompile a binary and deal with the troubleshooting that results.
Now, these are based on my usage of CentOS 7 which is already 2 years old on top of the release delays. I'm sure newer versions make the situation better. But at this very moment systemd has made a VERY bad first impression (there's more, but I'm not going to go into that) and left me with no practical solution. All the other things like "binary logging" just make me even more irritated.
I keep saying it, systemd not an init system. KDE and GNOME should not depend on an init system. Why does the desktop care who's booted it up?
More specifically, systemd is Linux-only. The devs have explicitly stated that they are making good use of Linux-specific features. Fine, but if third party software becomes dependent on it then that implies they won't work on *BSD at all. Right? So now there's no Gnome or KDE on anything but Linux.
So really, choice is being taken away clear across the board. Either that or I'm missing something really big which implies systemd is not a strict dependency.
Busybox is also a pretty weak substitute for most of these applications. Reduced command-line options, fewer features, terse output, etc.
But on a system where memory is limited - even moreso than a Raspberry Pi, for example - this is an advantage. You could put busybox into an emergency recovery boot ramdisk and be able to work reasonable well. That's the objective - it's small and used in specific situations only. If you don't need it, good for you.
As someone already said most servers don't actually use busybox day to day. It's available in the event something goes wrong and you need it.
Using the binary driver has been fine for me.
Not much more to say on the matter. ffmpeg + x264 make use of it nicely.
My own impressions of 5.0 haven't been too good. The lockscreen doesn't give you the unlock input (eg: PIN) without pushing a button to ask for it, the animations have been stepped up -- the kinds of animations you can't turn off from the Dev menu -- and it generally looks copmletely childish. That's not what I personally want.
If you're running 4.4 check out all the new Google apps from the store. That's what you're getting from Lollipop, but also with the launcher, etc. No. No no no. I uninstalled the gmail update as fast as I could.
This is the trend in tech - things become more colourful, flat and generally dumbed down. I don't mean dumbed down from a user knowledge point of view, I mean "UI designed in MS Paint" down.
In the embedded scenario the owner retains control. Frankly said owner should simply disallow embedding and let the embedder look like an idiot until they realize what they did.