Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Clarification regarding backports (Score 1) 126

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.

Comment Re:Why not allow the update into the repos? (Score 1) 126

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?

Comment Re:Why not allow the update into the repos? (Score 1) 126

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.

Comment Re:Packages can't be removed? (Score 1, Interesting) 126

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?

Comment Re:How? (Score 1) 104

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

Comment Re:And still they won't hire (Score 1) 52

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.

Comment cloud and freeness (Score 3, Interesting) 480

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.

Comment Re:Whats wrong with init? (Score 1) 279

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

Comment Re:I agree (Score 1) 279

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.

Comment Re:no (Score 4, Insightful) 262

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.

Slashdot Top Deals

Another megabytes the dust.