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.

I take it back. Deleting the video element didn't stop the download, as I just realised when I restarted my browser.

Adding ooyala.com as an untrusted source in NoScript worked fine.

To stop it, I had to use Firebug to select the video element, and dynamically delete it off the page.
Otherwise, it was sucking up my bandwidth pre-downloading the video. Definitely annoying.

I could write a Greasemonkey script to automatically stop this in the future. We'll see how often it happens.

You get a kernel panic, once a month, on Debian Testing?! That's _very_ unusual. I've run Testing on a dozen or so different systems, for over a decade, and have never had a kernel panic. Not once.

Are you using the Debian sourced kernel, or compiling your own? Compiling any third party drivers into it?

Anyway, whatever works for you. If FreeBSD is stable for you, and does everything you need, then go for it!

Feels the same with me and housework. I guess I can sympathise with him.

Spoken like a true anonymous coward. I certainly wouldn't want to sign my id alongside that sentiment and mistruth.