RAID 1 is *NOT* a backup, which I do incrementally, encrypted (with PGP), over network, every day. That's the only way to have my data safe, because even with 2 SSD, my laptop could burn or something... So no, the purpose of having RAID1 is not the same as backups, which I also do. RAID1 is for helping to keep the system up and running longer without disruption. If one hard drive fails, I know it does because I receive a mail telling me it did, and then it's up to me to decide what and when to act on it. I don't want my system to force me to do things when I don't want to. I just want RAID1 to do what it's suppose to do: make it so that my laptop continues to boot and run, even if one hard drive fails. By the way, if one SSD fails *after* the systemd boot process, no problem, my computer continues to work, as it is supposed to do.

Seems you don't get it. Running sysv-rc init doesn't have the issue. On both my laptop and the one of my wife, I had configured the USB device to be mounted where I wanted to (I didn't really enjoy the /media stuff). On both, upgrade performed perfectly, only systemd refused to continue to boot because it didn't like the entry in fstab.

This is *NOT* a problem by the sysadmin, this is a problem of change of behavior of the operating system caused by systemd. You will have a hard time convincing anyone that it's best to just stay stuck on an emergency shell rather than continuing to boot up to a point where the admin can do something with the compute.

I also had some very exasperating situation where systemd would refuse to boot because ... it couldn't see the 2nd HDD of a RAID1 array. I saw it multiple times, as the 2nd SSD was going away of its socket in the Thinkpad ultrabay (fixed after a few of these failures with ... a piece of paper to prevent it to move!). Now, explain to me what the point is to have redundancy, if it is just to double the chances of failure to boot? And then what happens when the HDD is really dead?

Systemd has some good point. But it goes too far in many area, and has many troubles, nobody can deny that. To me, it's still a PoC. Maybe it will be reliable in 5 to 10 years from now...

Devuan? Are you SURE? They pretended they were a fork of Debian, not a derivative. It took years to get their Jessie-based release out. Fast forward, they still didn't release anything more, and ... announced the Stretch-based release is coming. So suddenly, they become just-yet-another derivative of Debian. And what does it bring? Binaries not linked with libsystemd. That's it. No more, no less. In other words: completely useless, with very poor security support (unless someone dares Devuan has a better security team than Debian...). Not only that: there's almost nobody behind them but trolls like MikeeUSA (search the Debian lists, and you'll see what kind of nasty person that is...) and not even half a dozen other.

Devuan is a joke (one which isn't even funny): stay away.

The point is, we don't want static binaries 2.0. Just like Linus was saying "there's no way to do CVS the right way" (or something like that), the same way, there's no way to do static blobs the right way either.

By the way, why on earth isn't Spotify simply providing a source tarball, and let distributions pick it up and package it? The value of Spotify is in the service they do, not on the source code they write.

Except that wheezy (with sysv-rc) -> jessie (with systemd) runs fine, but jessie (with systemd) -> stretch (with systemd) is where the bug appears... Exactly how are we supposed to guess that systemd becomes a dick on upgrade? Or are you writing here that we're suppose to read ALL of systemd docs, just because we may come into some surprise? Come on...

The exact same thing happened to me. Yes, it's not uncommon to write extra stuff in the fstab for it to mount usb devices where we want. No, it's not acceptable to refuse to boot because of such a bad entry. And no, it's not right either to point at the documentation for such a DEFECT in systemd. Yes, you've read correctly, I consider this a bug. This has nothing to do with debugging or so. Plus, the OT is right, you're beeing hostile just for the fun of it...

Have you heard about a tool in Debian, called apt, used to install and replace things in your system? It's convenient you know. I even was told that it could remove systemd and replace it with sysv-rc if you like ...

Excuse me, but the "nobody on the Debian side cared to give it a try" is just plain wrong. First, I was the person that ported OpenRC to Debian, and made it work on kFreeBSD and Hurd. So I did spend a large amount of time on it. Then, the tech committee members, who made the actual decision of making systemd the default, did actually try. It's written in clear text, available for anyone, in the tech committee bug (do your research yourself if you want to check).

The reason why OpenRC hasn't been chosen, is because at the time, it was lacking a lot of features (that systemd had for a long time), like monitoring processes it starts and such things. That also is in the same entry in the Debian bug tracker.

Also, you are making a too good picture of OpenRC. It clearly lacks a good boot dependency solver, and as of writing, this part of OpenRC is still very buggy and problematic. When I first tried, it simply could not boot Debian because of such cyclic dependencies written in Debian's sysv-rc scripts. Yes, the sysv-rc scripts were wrong, but that's not what I'm debating here: OpenRC should have been able to cope with that to begin with. How such a so important thing not yet well implemented is beyond my understanding.

Yes, OpenRC is great, and I would have loved to have it be the default in Debian for many reasons (like being able to use it on any kernel types). But please be honest and paint it the correct way: it lacks lots of things too.

Last thing: OpenRC is STILL an option in Debian: apt-get install openrc, reboot, and you're running it...

Same over here. I haven't used Windows since 2004 and never used any Apple product (and use Linux since it existed), I barely use a Facebook account to read an article (yes, article, not stupid "posts") once a year, I use OpenStack and not AWS, and I could well shop somewhere else on Amazon (I already shop on taobao.com / alibaba). The only thing I use is Google search and maps, but really, I could go with duckduckgo and OSM. I wouldn't miss any of these these big companies if they stopped.

I fully agree with you. There's a big problem with the Universe repository.

Advising your users to use your own repository is not a satisfying answer. If there's a package in Debian, then it should be fine using it. It should as well receive (security) updates if needed. Now, it's looking like you didn't choose to have your package "synced" in Ubuntu universe. It just happened just like with many other software. My advice then would be to explicitely ask that the owncloud package is not synced again in any future release of Ubuntu, so you don't run into the same trouble again.

As for updating packages in Ubuntu, my experience is that it's not that hard. Just prepare a new package, and send the link to the Ubuntu security team, and basically, they can take care of the rest.

The point is: the Debian maintainer never asked for taking the burden of maintaining his package in Ubuntu, he just maintains it in Debian. It just happened automatically. But security updates aren't automated. Now, are you saying that he must be forced to also maintain it in Ubuntu, otherwise they will forever keep some flowed packages? Man, he didn't choose the situation, and probably he simply doesn't want to do the work in Ubuntu. Why then just keeping his package there?

Not getting updates for features is perfectly fine. What is a problem is not getting security fixes, and having the security team of Canonical not caring at all about that.

When someone maintains a package in Debian, he may care about it, and provide sound security updates once the stable release is out. Though what's unexpected, is that the same package, while well maintained in Debian, may not be fixed in Ubuntu, because you know... it's "Universe"... The security team from Canonical will not take the time to get the updated package from Debian, unless someone carefully prepares the update and do the work for them.

The final result is that the Ubuntu universe repository is full of security issues unless someone "from the community" (understand: the Debian package maintainer) cares doing it, which often doesn't happen.

Don't use Ubuntu on your servers, it's simply not safe.

Of course it makes sense: this is Ubuntu. When they say "it's from universe", you should understand: "we synced from Debian, and we wont do any more work on the package, as we don't give a shit about what we ship".

I think it's more than time that everyone understand Ubuntu is not a good fit for running a server, unless you remove nearly all software from it (that is: everything that is "synced from Debian"). So then, why not using Debian in the first place?

Another way would be to show them existing free software like Canonical "summit", which was used for last Debconf 14 in Portland. It's available from here:

http://anonscm.debian.org/cgit...

There's also Penta, but it's quite old, and maybe summit is better.

So, if that non-profit thinks SaaS solutions aren't good, tell them they are right. But also tell them that starting from scratch is silly (to say it nicely) when there's already nice free software they can contribute to (for these features that they think nobody has...).