Well, it wasn't a suggestion for every single person in the US. I'd imagine that it'd be quite difficult raising hens in a studio apartment, or any apartment, for that matter. Given enough backyard space, though, it's feasible for anyone to do. Especially if you cook at home and produce a good amount of green waste.
From what I've read, systemd has seen a number of code audits. Not only from numerous individuals, but from Redhat as well. Redhat also regularly run it through code analysis software.
The network connectivity in systemd is a simple inetd-like setup. No network data is processed by systemd code. It only listens on the port, starts up the service and hands it the socket. Yeah, you could argue that you may as well use inetd instead, but then you're missing out on the features that systemd provides for managing services.
If there's a way to attack systemd, I'd be quite confident that its simple network code will not provide a vector.
Also, systemd isn't a huge blob of code. It's actually a suite of programs; the init system being just one component. It's a common misconception.
Excellent! It's nice to get a decent response from someone on this issue, instead of the usual emotive decry that seems to be typical of many systemd detractors.
The controversy with systemd is pretty interesting. There's a fair bit of misinformation flying around, which does muddy the water. I think this misinformation seems to be the source of many people's objections to it. Unfortunately, the only way I can see to solve this is to get people using it.
What's so great about systemd? Well, going from your post, you seem to be in product development. I would think you'd be all over systemd! No need to load a shell for the boot process. That there is an immediate security improvement, as well as an improvement in memory use. Integration with CGroups makes it possible to tighten up resource allocation for subsystems, ensuring that your device doesn't crash/become resource deprived due to a runaway process. An API! Surely you can't object to an API for systemd.
How do you _know_ precisely that something is a secure system? You could do a personal security audit, I suppose, but even then, you may miss something which ends up being a security issue. Time can be a good indicator of secure software, but there are plenty of examples of time proven software which has turned out to be insecure. Even with presumably security conscious packages like libssl. You could run code auditing software on the source, but that's precisely what Red Hat do. You could release it as an open source, controversial, high profile package, and let thousands of eyes pick the code clean... nah, that'd never work.
Logging to syslog, or the binary database, or both, is a simple config option. You're in control here.
Geez, I throw in one line in jest, and I get shot down as making a joke of the issue, and being symptomatic of what is supposedly wrong with systemd. Yep, the whole kit and kaboodle. Can't please everyone, I suppose.;)
Sure, no problem. If you dislike systemd that much, it certainly makes sense to move to a different software platform. I just disagree with your arguments. Your reasoning is flawed, and I believe this is about feeling. Which is fine; needing to enjoy the OS you use is a valid reason for changing.
Your Snowden argument isn't particularly applicable in this instance, as you have access to the full source code for systemd. If you're not comfortable looking through C code, then any init system would be a problem for you.
The configuration for systemd isn't buried. It's there for all to see and change, in plain text. Logging in binary form is _optional_. You can choose to direct logged messages to syslog, or use both syslog and binary, to have the "best of both worlds", albeit with the best of disk usage. Entangling diverse processes into an interlocking mass is what operating systems are all about!;)
If you think that porting your laptop, home servers and desktops to a completely different operating system is less effort than learning how systemd works, then I can only conclude you haven't tried to learn how systemd works. Or you've severely underestimated the work involved in moving to another OS.
Don't mind me, I'm not trying to convince you to give up on the BSDs. Far from it. I like the idea of OS diversity. Used FreeBSD myself at one point, and though I wasn't convinced to stick with it, it certainly has a quality kernel. I just think your arguments against systemd need some more work.
Gosh, well, thanks for the enlightening response. I guess those who really understand Unix don't feel the need to produce a well reasoned and rational argument.
How did I guess that replies to this article would be dominated by systemd?! Always guaranteed to stir up a shit-storm of comments. Can be quite entertaining.
Anyway, I digress. Advantages of systemd are:
* Starting services in parallel, making for a more efficient bootup. * Automatic dependency handling of services. No more need to manually change the order via symlinks. * Monitors started services, and will automatically restart them if configured to. * Centralised management of logged messages. No need to hunt through a multitude of different log files any more. * Logs bootup messages. Did you see that error message flash past when you booted your systems? Couldn't scroll up because the tty login overwrote part of the console buffer you were interested in, or the message scrolled off the top of the buffer? This situation is no longer a problem with systemd. * Completely binary init system, so less resource intensive on bootup. Maybe not a big deal for regular systems, but embedded systems will love it. * Integrated with the Linux Cgroups feature, allowing fine tuning of resource usage for individual services or service groups. * Services don't need to start on bootup. They can start via socket based activation. * Can trigger services to start on system events.
That's a list off the top of my head. There's probably more.
The systemd config file INI-like syntax irks me a bit. Takes a little getting used to its way of doing things. Otherwise, it works well. You're welcome to join the BSD camp, if you feel the need. If you dislike systemd that much, it's only going to get more painful in the future.
Long time Linux system admin here, of over 20 years experience. Systemd is both stable and an improvement over sysv. The only instability I've ever heard of was through upgrading a system from sysv to systemd, and even then, it was only for certain edge cases. That is the fault of the upgrade process, not the end system. So, while systemd is stable, the upgrade process is still being tweaked. I presume this is why Debian still has sysv in their stable release.
I'm happy to run my production systems with systemd. In fact, I do already for some. They work reliably all of the time. Systemd works, and it works fine.
As for the dislike of systemd, I think it is partially rooted in the loss of a scriptable init system. The move from a scripted system to a binary system makes working around certain problems harder to manage. Of course, you can still use scripts to start up services, but it's not core to the process any more.
I agree that if you're going to use a physical controller, you should hopefully see a virtual representation of it as well. It would make the experience of virtual reality less jarring.
The combination of the Xbox, Oculus, and the Kinect could be an interesting one though. The Kinect provides a method to control virtual reality through voice and gestures. No physical controller needed. It may be the way to work with virtual reality, and Microsoft have everything in place to take advantage of it. Done right, it could be a winner, and may even make me consider getting an Xbox.
They aren't "stealing" anything. How can one "steal" information? That's like stealing the number 4 or the color blue.
Well, the English language being as it is, you can have multiple meanings attributed to a single word. In this case, the word "steal" can certainly be applied to this situation. It is possible to "steal" an idea, data, attribution, and other intangible things. You can even steal a show, if you're a performer. The definition of the word supports this. As much as I dislike the rhetorical use of the word with copyright violations, it is valid.
If your life revolves around video games, by definition you're a shallow person.
Mayhap you need to generalise that a bit more. Video games per se aren't all that bad. I've struck up a few conversations with younger women about video games.
Say instead that "if your life revolves around only one particular activity, by definition, you're a shallow person".
To which I certainly agree. Be it video games, shopping, facebook, football, clothing, gym, programming, or clubbing, anything can be taken to excess. Also, it's fun to try something different every so often. My recent craze is slacklining. Great fun, and I genuinely believe most people are capable of it with practice. Age is not an excuse.
I assume this was an investment property that you sold. You don't pay any CGT if you sell your place of residence, assuming it's always been your residence since you purchased it.
In which case, tough luck. Your paying a tax on the profit you made on an investment property. I assume you didn't complain when you reduced your past tax bills through negative gearing and investment property expenses. If those benefits are removed, then you can complain about the CGT.
Sun, DEC, SGI, et al. They went the way of the financial dodo by having high-priced products and not being able to adjust quickly to the marketplace. Sun less so, but still to a certain extent.
That can't happen to Linux. Besides, you can't really compare an open source project to a commercial offering. The latter is driven by profit. The former is driven by community interest. As long as the community is active, Linux will stay alive and well, and will continue to flourish.
I agree that they abused "debug" in the kernel command line. Though that's a whole other can of worms, and you could argue that the term "debug" is generic, and should apply to all systems, not just the kernel. Using "kernel.debug" and "systemd.debug" would be more specific ways of flagging what system should enable debug messages on boot, and would be specific enough to avoid all the confusion that lay at the root of this problem.
The use of "nofail" here does fulfil a purpose though, even if it does cause some people headaches when changing init systems. But, like I said, this should probably be handled by the upgrade process, not by systemd itself.
If you don't want systemd to panic about a failed USB automatic mount on startup, then you have a number of options.
* Specify "noauto" in fstab
* Specify "nofail" in fstab
* Install an automount system, and delete the entry from fstab.
* Use the systemd automount feature, and delete the entry from fstab
Look, systemd is different. It's not a complete drop-in replacement for sysv init, though it can work as such 99% of the time. Accept that it can be different, and work from there. Moaning about it just makes you sound like an overprotective old man with his lawn.
This seems to be a common problem with changing from another init to systemd.
Basically, you have to mark your non-essential, auto mount on bootup, fstab entries with the option "nofail". It does make sense, as you can have essential parts of your system mounted on other partitions.
I would hope that this issue is handled by the upgrade process to systemd. Inform the person doing the upgrade to add the option, or automatically add the option to the fstab file for non root partitions.
It could be Apple hate, or, it could just be showing weaknesses in the Apple ecosystem. It could be self-righteousness, or it could just be reporting the reality of a situation. Don't be so quick to conclude one way or the other.
Apple have done some great things in the past, I'm sure we can all agree. You've certainly mentioned a few. It doesn't mean they're perfect, nor any other system out there. They've still got problems, and this Fear of Apple appears to be one of them. It can only lead to the downfall of Apple, so it's actually in their best interest to air the issue and possibly get a resolution out of it.
As for The Linux Desktop, technically speaking, it's ready. Been that way for years. Gnome and KDE deliver on the Desktop Experience well enough, I'd be comfortable recommending them to my parents. In fact, I have. My father uses a Gnome desktop, and he's fairly below average when it comes to computer literacy. The one thing holding back the Linux Desktop is marketing. That's where open source is the weakest. Convincing others that they need this product... it's where open source fails, and Apple reigns supreme. Unfortunately, I don't see it changing any time soon.
So the majority of your Steam collection comes from Humble Bundles? Well, I have good news for you, then. The majority of Humble Bundles have Linux support! Certainly the majority of indie games in Humble Bundle. Check it out. You may be pleasantly surprised.
As for Windows, I don't mind it too much. It has its place. I use Linux as my home and work interface, because it suits the way I like to work. I use the Enlightenment window manager, as it is extremely customisable, allowing me to tweak it to exactly how I like. Microsoft generally have a different mind set. They want you to work the way they deem the "right" way. So in using Windows, I have to adapt my workflow to the Microsoft mindset, rather than be able to adapt my environment to my mindset. That's probably a good thing for most computer users, but it annoys me.
That, and when things go wrong, Windows can be a pain. It tends to want to hide details, whereas Linux is usually excellent in supplying all sorts of details on an issue. I manage both Windows and Linux servers, and from my experience, troubleshooting is much easier in the Linux environment. When both systems work, they both work well. When problems hit, I'd rather be on a Linux system.
You only need to block the "ooyala.com" domain through NoScript. I allow scripts in general, but specifically block domains. That helps to stop breakage.
The post I replied to was talking about SystemD listening on network ports. In that context, socket activation _is_ everything. Any bug in the network listening code of SystemD cannot be triggered, if the software ain't listening in the first place.
Honestly, kids these days. I blame the music they listen to. Turns the brain to mush.
Actually, it's pretty simple to stop SystemD from listening on network ports. It's called "socket activation". Look it up. It's pretty neat. All you need to do is stop the specific socket service, and then edit the appropriate socket file.
You'll also be interested to know that the Debian install of SystemD doesn't use socket activation by default. Not yet, anyway.
As for systemd security auditing, from what I've heard, the people at Redhat run the source code through various tools designed to pick out bugs. Also, I've read of at least one person doing an independent audit of the code. I presume there would be many more than that. So, as far as security testing is concerned, it's far from having nothing done.
Slashdot Mirror
Well, it wasn't a suggestion for every single person in the US. I'd imagine that it'd be quite difficult raising hens in a studio apartment, or any apartment, for that matter. Given enough backyard space, though, it's feasible for anyone to do. Especially if you cook at home and produce a good amount of green waste.
Raise your own hens? Or buy eggs from someone who has hens and is not associated with the egg lobby?
Honestly, if you went to your local farmer's markets, you'd probably find someone with eggs pretty quickly.
If someone paid me 2 billion, I'd be a huge fan of them as well.
From what I've read, systemd has seen a number of code audits. Not only from numerous individuals, but from Redhat as well. Redhat also regularly run it through code analysis software.
The network connectivity in systemd is a simple inetd-like setup. No network data is processed by systemd code. It only listens on the port, starts up the service and hands it the socket. Yeah, you could argue that you may as well use inetd instead, but then you're missing out on the features that systemd provides for managing services.
If there's a way to attack systemd, I'd be quite confident that its simple network code will not provide a vector.
Also, systemd isn't a huge blob of code. It's actually a suite of programs; the init system being just one component. It's a common misconception.
Excellent! It's nice to get a decent response from someone on this issue, instead of the usual emotive decry that seems to be typical of many systemd detractors.
The controversy with systemd is pretty interesting. There's a fair bit of misinformation flying around, which does muddy the water. I think this misinformation seems to be the source of many people's objections to it. Unfortunately, the only way I can see to solve this is to get people using it.
What's so great about systemd? Well, going from your post, you seem to be in product development. I would think you'd be all over systemd! No need to load a shell for the boot process. That there is an immediate security improvement, as well as an improvement in memory use. Integration with CGroups makes it possible to tighten up resource allocation for subsystems, ensuring that your device doesn't crash/become resource deprived due to a runaway process. An API! Surely you can't object to an API for systemd.
How do you _know_ precisely that something is a secure system? You could do a personal security audit, I suppose, but even then, you may miss something which ends up being a security issue. Time can be a good indicator of secure software, but there are plenty of examples of time proven software which has turned out to be insecure. Even with presumably security conscious packages like libssl. You could run code auditing software on the source, but that's precisely what Red Hat do. You could release it as an open source, controversial, high profile package, and let thousands of eyes pick the code clean ... nah, that'd never work.
Logging to syslog, or the binary database, or both, is a simple config option. You're in control here.
Geez, I throw in one line in jest, and I get shot down as making a joke of the issue, and being symptomatic of what is supposedly wrong with systemd. Yep, the whole kit and kaboodle. Can't please everyone, I suppose. ;)
Sure, no problem. If you dislike systemd that much, it certainly makes sense to move to a different software platform. I just disagree with your arguments. Your reasoning is flawed, and I believe this is about feeling. Which is fine; needing to enjoy the OS you use is a valid reason for changing.
Your Snowden argument isn't particularly applicable in this instance, as you have access to the full source code for systemd. If you're not comfortable looking through C code, then any init system would be a problem for you.
The configuration for systemd isn't buried. It's there for all to see and change, in plain text. Logging in binary form is _optional_. You can choose to direct logged messages to syslog, or use both syslog and binary, to have the "best of both worlds", albeit with the best of disk usage. Entangling diverse processes into an interlocking mass is what operating systems are all about! ;)
If you think that porting your laptop, home servers and desktops to a completely different operating system is less effort than learning how systemd works, then I can only conclude you haven't tried to learn how systemd works. Or you've severely underestimated the work involved in moving to another OS.
Don't mind me, I'm not trying to convince you to give up on the BSDs. Far from it. I like the idea of OS diversity. Used FreeBSD myself at one point, and though I wasn't convinced to stick with it, it certainly has a quality kernel. I just think your arguments against systemd need some more work.
Gosh, well, thanks for the enlightening response. I guess those who really understand Unix don't feel the need to produce a well reasoned and rational argument.
How did I guess that replies to this article would be dominated by systemd?! Always guaranteed to stir up a shit-storm of comments. Can be quite entertaining.
Anyway, I digress. Advantages of systemd are:
* Starting services in parallel, making for a more efficient bootup.
* Automatic dependency handling of services. No more need to manually change the order via symlinks.
* Monitors started services, and will automatically restart them if configured to.
* Centralised management of logged messages. No need to hunt through a multitude of different log files any more.
* Logs bootup messages. Did you see that error message flash past when you booted your systems? Couldn't scroll up because the tty login overwrote part of the console buffer you were interested in, or the message scrolled off the top of the buffer? This situation is no longer a problem with systemd.
* Completely binary init system, so less resource intensive on bootup. Maybe not a big deal for regular systems, but embedded systems will love it.
* Integrated with the Linux Cgroups feature, allowing fine tuning of resource usage for individual services or service groups.
* Services don't need to start on bootup. They can start via socket based activation.
* Can trigger services to start on system events.
That's a list off the top of my head. There's probably more.
The systemd config file INI-like syntax irks me a bit. Takes a little getting used to its way of doing things. Otherwise, it works well. You're welcome to join the BSD camp, if you feel the need. If you dislike systemd that much, it's only going to get more painful in the future.
Long time Linux system admin here, of over 20 years experience. Systemd is both stable and an improvement over sysv. The only instability I've ever heard of was through upgrading a system from sysv to systemd, and even then, it was only for certain edge cases. That is the fault of the upgrade process, not the end system. So, while systemd is stable, the upgrade process is still being tweaked. I presume this is why Debian still has sysv in their stable release.
I'm happy to run my production systems with systemd. In fact, I do already for some. They work reliably all of the time. Systemd works, and it works fine.
As for the dislike of systemd, I think it is partially rooted in the loss of a scriptable init system. The move from a scripted system to a binary system makes working around certain problems harder to manage. Of course, you can still use scripts to start up services, but it's not core to the process any more.
I agree that if you're going to use a physical controller, you should hopefully see a virtual representation of it as well. It would make the experience of virtual reality less jarring.
The combination of the Xbox, Oculus, and the Kinect could be an interesting one though. The Kinect provides a method to control virtual reality through voice and gestures. No physical controller needed. It may be the way to work with virtual reality, and Microsoft have everything in place to take advantage of it. Done right, it could be a winner, and may even make me consider getting an Xbox.
Well, the English language being as it is, you can have multiple meanings attributed to a single word. In this case, the word "steal" can certainly be applied to this situation. It is possible to "steal" an idea, data, attribution, and other intangible things. You can even steal a show, if you're a performer. The definition of the word supports this. As much as I dislike the rhetorical use of the word with copyright violations, it is valid.
Mayhap you need to generalise that a bit more. Video games per se aren't all that bad. I've struck up a few conversations with younger women about video games.
Say instead that "if your life revolves around only one particular activity, by definition, you're a shallow person".
To which I certainly agree. Be it video games, shopping, facebook, football, clothing, gym, programming, or clubbing, anything can be taken to excess. Also, it's fun to try something different every so often. My recent craze is slacklining. Great fun, and I genuinely believe most people are capable of it with practice. Age is not an excuse.
Whatever works for you. I'm a fan of headache porn. The phrase "I have a headache tonight" gets me going every time.
I assume this was an investment property that you sold. You don't pay any CGT if you sell your place of residence, assuming it's always been your residence since you purchased it.
In which case, tough luck. Your paying a tax on the profit you made on an investment property. I assume you didn't complain when you reduced your past tax bills through negative gearing and investment property expenses. If those benefits are removed, then you can complain about the CGT.
Sun, DEC, SGI, et al. They went the way of the financial dodo by having high-priced products and not being able to adjust quickly to the marketplace. Sun less so, but still to a certain extent.
That can't happen to Linux. Besides, you can't really compare an open source project to a commercial offering. The latter is driven by profit. The former is driven by community interest. As long as the community is active, Linux will stay alive and well, and will continue to flourish.
I agree that they abused "debug" in the kernel command line. Though that's a whole other can of worms, and you could argue that the term "debug" is generic, and should apply to all systems, not just the kernel. Using "kernel.debug" and "systemd.debug" would be more specific ways of flagging what system should enable debug messages on boot, and would be specific enough to avoid all the confusion that lay at the root of this problem.
The use of "nofail" here does fulfil a purpose though, even if it does cause some people headaches when changing init systems. But, like I said, this should probably be handled by the upgrade process, not by systemd itself.
If you don't want systemd to panic about a failed USB automatic mount on startup, then you have a number of options.
* Specify "noauto" in fstab
* Specify "nofail" in fstab
* Install an automount system, and delete the entry from fstab.
* Use the systemd automount feature, and delete the entry from fstab
Look, systemd is different. It's not a complete drop-in replacement for sysv init, though it can work as such 99% of the time. Accept that it can be different, and work from there. Moaning about it just makes you sound like an overprotective old man with his lawn.
This seems to be a common problem with changing from another init to systemd.
Basically, you have to mark your non-essential, auto mount on bootup, fstab entries with the option "nofail". It does make sense, as you can have essential parts of your system mounted on other partitions.
I would hope that this issue is handled by the upgrade process to systemd. Inform the person doing the upgrade to add the option, or automatically add the option to the fstab file for non root partitions.
Actually, according to the Microsoft Technet article linked in the story, kernel caching is enabled by default in IIS 7.
It could be Apple hate, or, it could just be showing weaknesses in the Apple ecosystem. It could be self-righteousness, or it could just be reporting the reality of a situation. Don't be so quick to conclude one way or the other.
Apple have done some great things in the past, I'm sure we can all agree. You've certainly mentioned a few. It doesn't mean they're perfect, nor any other system out there. They've still got problems, and this Fear of Apple appears to be one of them. It can only lead to the downfall of Apple, so it's actually in their best interest to air the issue and possibly get a resolution out of it.
As for The Linux Desktop, technically speaking, it's ready. Been that way for years. Gnome and KDE deliver on the Desktop Experience well enough, I'd be comfortable recommending them to my parents. In fact, I have. My father uses a Gnome desktop, and he's fairly below average when it comes to computer literacy. The one thing holding back the Linux Desktop is marketing. That's where open source is the weakest. Convincing others that they need this product ... it's where open source fails, and Apple reigns supreme. Unfortunately, I don't see it changing any time soon.
Actually, if it ran windows, it would be a PSVista .
So the majority of your Steam collection comes from Humble Bundles? Well, I have good news for you, then. The majority of Humble Bundles have Linux support! Certainly the majority of indie games in Humble Bundle. Check it out. You may be pleasantly surprised.
As for Windows, I don't mind it too much. It has its place. I use Linux as my home and work interface, because it suits the way I like to work. I use the Enlightenment window manager, as it is extremely customisable, allowing me to tweak it to exactly how I like. Microsoft generally have a different mind set. They want you to work the way they deem the "right" way. So in using Windows, I have to adapt my workflow to the Microsoft mindset, rather than be able to adapt my environment to my mindset. That's probably a good thing for most computer users, but it annoys me.
That, and when things go wrong, Windows can be a pain. It tends to want to hide details, whereas Linux is usually excellent in supplying all sorts of details on an issue. I manage both Windows and Linux servers, and from my experience, troubleshooting is much easier in the Linux environment. When both systems work, they both work well. When problems hit, I'd rather be on a Linux system.
If only they had called it the High-repetition-rate Advanced Petawatt Laser Emission SyStem.
You only need to block the "ooyala.com" domain through NoScript.
I allow scripts in general, but specifically block domains. That helps to stop breakage.
My turn to say "huh?"
The post I replied to was talking about SystemD listening on network ports. In that context, socket activation _is_ everything. Any bug in the network listening code of SystemD cannot be triggered, if the software ain't listening in the first place.
Honestly, kids these days. I blame the music they listen to. Turns the brain to mush.
Actually, it's pretty simple to stop SystemD from listening on network ports. It's called "socket activation". Look it up. It's pretty neat. All you need to do is stop the specific socket service, and then edit the appropriate socket file.
You'll also be interested to know that the Debian install of SystemD doesn't use socket activation by default. Not yet, anyway.
As for systemd security auditing, from what I've heard, the people at Redhat run the source code through various tools designed to pick out bugs. Also, I've read of at least one person doing an independent audit of the code. I presume there would be many more than that. So, as far as security testing is concerned, it's far from having nothing done.
There's always a workaround. Even for SystemD.