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.
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:
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...).
If you think you can learn no-sql, python and the cloud in 2 weeks, you're deeply mistaking. It took me months to get up to speed with OpenStack, and I still learn every day after years doing its Debian packaging. Sure, as it's something new, companies should take into account that their future employee will have to learn and wont know all of this. However, it isn't a reason why not posting needed skills for the job.
Please define "as quickly as desired". Debian was fixed on the 3rd of March which is the date of the Debian Security Advisory, that's pretty quick to me. I wonder exactly why this article pops up now, when it's been a long time we've been all patched.
In the debian-cloud list, we had a long discussion about wordings, which I also think is very important. It stroke me that you felt cloud was in essence non-free, and that you wanted everyone to stop using the word "cloud" which you (rightly) thought was too vague. But since there is also private IaaS (Infrastructure as a Service), I do think we may have fully free cloud systems.
I never knew if I was able to convince you that a completely free IaaS software was very important to keep our freedom, and would like to know what is your current feeling about it.
And by the way, there has never been a declaration that Debian will support *only one* init system. Just that systemd will be the default for Jessie. Nothing more, nothing less. Anyone willing to help the Debian OpenRC team is welcome to do so (by developing OpenRC, testing it in Debian, writing runscripts, etc.).
Stay with Debian, and install OpenRC on it. I will do what I can so that it will be ready for Jessie. Tests and feedback welcome. FYI, it already works on both kFreeBSD and Hurd, so it cover all Linux and non-Linux ports of Debian.
Well, I do find it extremely useful. Especially in Debian & Ubuntu, we have multi-arch support. For some specific workload using interpreted languages, it just reduces the memory footprint by a half. For example, PHP and Perl. If you once ran Amavis and spamassassin, you certainly know what I mean: it takes double the amount of RAM on 64 bits. Since most of our servers are running PHP, Amavis and Spamassassin, this would be a huge benefits (from 800 MB to 400 MB as the minimum server footprint), while still being able to run the rest of the workloads using 64 bits: for example, Apache itself and MySQL, which aren't taking much RAM anyway compared to these anti-spam dogs.
As an EU citizen you could try to change the institution.
Are you one of these scumbags paid by the European Parliament to troll on forums? Of course one can try though with the current system, it's doomed to failure.
BTW: France is part of the EU as much as Germany or the Netherlands, therefore it is only fair to summarize all these countries with the EU flag, just like US states are all summarized by the US flag. Yes we are not that one country as the US is, but it is very close.
This is not the united states of Europe. Nobody wants that in Europe (I mean, as in, the people doesn't want this, at least anymore). There's more and more sovereign movements raising, and they will get even stronger as time passes. So, it has never been, and never will be fair to replace the flags of individual countries (did you notice I didn't use the word state?) by the European flag.
Slashdot Mirror
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.
... 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?
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
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...).
If you think you can learn no-sql, python and the cloud in 2 weeks, you're deeply mistaking. It took me months to get up to speed with OpenStack, and I still learn every day after years doing its Debian packaging. Sure, as it's something new, companies should take into account that their future employee will have to learn and wont know all of this. However, it isn't a reason why not posting needed skills for the job.
Please define "as quickly as desired". Debian was fixed on the 3rd of March which is the date of the Debian Security Advisory, that's pretty quick to me. I wonder exactly why this article pops up now, when it's been a long time we've been all patched.
Anyone who can't get into the trap of the OpenSSL non-advertising licensing issue which is not compatible with the GPL license.
Hi, Richard!
In the debian-cloud list, we had a long discussion about wordings, which I also think is very important. It stroke me that you felt cloud was in essence non-free, and that you wanted everyone to stop using the word "cloud" which you (rightly) thought was too vague. But since there is also private IaaS (Infrastructure as a Service), I do think we may have fully free cloud systems.
I never knew if I was able to convince you that a completely free IaaS software was very important to keep our freedom, and would like to know what is your current feeling about it.
OpenRC is in Debian: https://packages.debian.org/ex...
And I will upload it to Sid soon.
And by the way, there has never been a declaration that Debian will support *only one* init system. Just that systemd will be the default for Jessie. Nothing more, nothing less. Anyone willing to help the Debian OpenRC team is welcome to do so (by developing OpenRC, testing it in Debian, writing runscripts, etc.).
Stay with Debian, and install OpenRC on it. I will do what I can so that it will be ready for Jessie. Tests and feedback welcome. FYI, it already works on both kFreeBSD and Hurd, so it cover all Linux and non-Linux ports of Debian.
Well, I do find it extremely useful. Especially in Debian & Ubuntu, we have multi-arch support. For some specific workload using interpreted languages, it just reduces the memory footprint by a half. For example, PHP and Perl. If you once ran Amavis and spamassassin, you certainly know what I mean: it takes double the amount of RAM on 64 bits. Since most of our servers are running PHP, Amavis and Spamassassin, this would be a huge benefits (from 800 MB to 400 MB as the minimum server footprint), while still being able to run the rest of the workloads using 64 bits: for example, Apache itself and MySQL, which aren't taking much RAM anyway compared to these anti-spam dogs.
Is there still a lot of people like you believing in this stupid left-right paradigm? We're well passed that, aren't we?
As an EU citizen you could try to change the institution.
Are you one of these scumbags paid by the European Parliament to troll on forums? Of course one can try though with the current system, it's doomed to failure.
BTW: France is part of the EU as much as Germany or the Netherlands, therefore it is only fair to summarize all these countries with the EU flag, just like US states are all summarized by the US flag. Yes we are not that one country as the US is, but it is very close.
This is not the united states of Europe. Nobody wants that in Europe (I mean, as in, the people doesn't want this, at least anymore). There's more and more sovereign movements raising, and they will get even stronger as time passes. So, it has never been, and never will be fair to replace the flags of individual countries (did you notice I didn't use the word state?) by the European flag.
This is why users should use open source software and run their own web sites.