Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Slashdot Deals: Prep for the CompTIA A+ certification exam. Save 95% on the CompTIA IT Certification Bundle ×

Comment Re:Startup management subsystem (Score 1) 416

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.

Comment Re:Systemd, pass II (Score 1) 187

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. ;)

Comment Re: Thanks Linus! (Score 1) 187

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.

Comment Re: Thanks Linus! (Score 1) 187

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.

Comment Re:No, they just need reliable Linux distros. (Score 5, Interesting) 187

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.

Comment Re:Visible controllers (Score 1) 105

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.

Comment Re:"stealing just like stealing anything else" (Score 1) 408

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.

Comment Re: You are quoting losers, so yeah. (Score 2) 950

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.

Comment Re:and kill CGT (Score 1) 125

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.

Comment Re:Single case anecdote. (Score 1) 469

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.

Comment Re:systemd fast? (Score 1) 442

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.

Comment Re:systemd fast? (Score 1) 442

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.

A commune is where people join together to share their lack of wealth. -- R. Stallman