I recently bought a NAS after a string of DIY fileservers, and I'm glad I did. It does a better job of taking care of the disks than I could, and has a nice web interface for managing volumes. The biggest thing it has going for it is hardware designed specifically for being a NAS; disks are easier to swap and ventilation is much better.
Sad to see that rather than making the decision: won't upgrade server distribution, leaving users with an older but still working version, the decision that was made is to "upgrade" while knowingly reintroducing old issues.
When the author was asked why his changes weren't merged upstream (which would have prevented his issues):
> "A lot of this kind of stuff differs wildly between the distributions, especially since no two distros share the same boot code. The simple fact was that the changes were sent upstream and rejected because they didn’t apply to Red Hat, and the RH way of doing things. Likewise they don’t apply to Debian since that uses sysvinit and (I believe) udev is still optional, etc"
For a project as large and as complicated as Ubuntu, I imagine custom patches like the author's get lost periodically between release cycles, especially if they no longer apply cleanly to the latest upstream version.
I guess I also find it hard to believe that the upstream maintainers (RH?) could not be worked with to get this eventually merged in. Difficult developers/teams do exist, but the difficulties in getting the patches accepted weren't really outlined in the post (so it's hard to know what happened).
I also wonder how many alternative distros are using the unmodified upstream version of the package in question, meaning that the author may run into the same issue on other Linux distros as well.
The thing is, there actually are cloud services that let you cheaply back up and restore terabytes. Crashplan is one of them, and they have a Linux client.
This is why you use OpenSUSE or CentOS for servers, not Ubuntu.
Also, if for some reason, you have a desire to contribute to Ubuntu, contribute to Debian instead. Your changes will probably end up in Ubuntu, and the Debian folks care about stuff like user privacy and free software.
For a complete beginner into server management, who is looking into setting up some servers in the near future, why should I not use Ubuntu for server? And use CentOS instead? Is there a solid reason for this?
Ubuntu is focused on trying to be easy to use, and so it does things like make the bootloader difficult to access, package a huge amount of stuff by default, and include relaxed security. In fact, the default configuration for Ubuntu is not even to have a password for root, but just to give unlimited access to the main user via sudo.
At the same time, Canonical (makers of Ubuntu) are not very interested in the server, at least compared to Red Hat and SuSE. So you get big regressions in server-related functionality like the one described in this article.
Things not to use on a server: Ubuntu, Fedora, Gentoo
Things to use on a server: CentOS, RHEL, SuSE, possibly Debian, any of the BSDs.
The realistic choice for servers today is either Debian or CentOS. This is what you'll find in pretty much any large deployment and for good reasons.
Ubuntu may be a distant third candidate due to its recent popularity, however it was never really meant for servers. Many of their policies are problematic in a server-env and most of the perceived popularity stems from inexperienced people who, by default, use on their server what they know from their desktop.
And please don't recommend SuSE. That is really just cruel.
SuSE has made a few questionable decisions, like being the first major distribution to call btrfs stable, and playing games with libc symbols in 10.x.
I was on board the Fedora train until recently, but I had to get off because it was changing from RHEL beta edition to... RHEL pre-alpha edition. I have a soft spot for SuSE, but I've never been a full-time sysadmin, so you have to take my recommendations with a grain of salt.
I'am also disappointed with Ubuntu (version 10.10 was the best but 12.04 the worst). I wanted to try Fedora but I was reading interesting Fedora 18 Spherical Cow review on HN yesterday: http://www.dedoimedo.com/computers/fedora-18-kde.html
What is the best Linux distribution (with Gnome 2) for Web Developers?
I said goodbye too recently. After dealing with slow performance, a lot of crashes and high memory usage on my machines I started looking around for other options. That also took care of the worries I had about the very questionable choices Ubuntu/Canonical made the last few years, but it's still quite sad to see it driving towards a cliff.
I have arch linux running now and while arch is not known for it's stability, I have far fewer applications crashing nowadays.
I'm using a AMD E450 based machine running FreeBSD and 5x2TB disks in a zfs zraid for network storage. While SSH access could be faster, it's certainly enough for streaming 1080p video.
24 comments
[ 3.3 ms ] story [ 58.0 ms ] threadHere is a basic unit, with a hardware encryption co-processor: http://www.synology.com/products/product.php?product_name=DS...
> "A lot of this kind of stuff differs wildly between the distributions, especially since no two distros share the same boot code. The simple fact was that the changes were sent upstream and rejected because they didn’t apply to Red Hat, and the RH way of doing things. Likewise they don’t apply to Debian since that uses sysvinit and (I believe) udev is still optional, etc"
For a project as large and as complicated as Ubuntu, I imagine custom patches like the author's get lost periodically between release cycles, especially if they no longer apply cleanly to the latest upstream version.
I guess I also find it hard to believe that the upstream maintainers (RH?) could not be worked with to get this eventually merged in. Difficult developers/teams do exist, but the difficulties in getting the patches accepted weren't really outlined in the post (so it's hard to know what happened).
I also wonder how many alternative distros are using the unmodified upstream version of the package in question, meaning that the author may run into the same issue on other Linux distros as well.
http://www.hanselman.com/blog/HowToSetUpCrashPlanCloudBackup...
Also, if for some reason, you have a desire to contribute to Ubuntu, contribute to Debian instead. Your changes will probably end up in Ubuntu, and the Debian folks care about stuff like user privacy and free software.
At the same time, Canonical (makers of Ubuntu) are not very interested in the server, at least compared to Red Hat and SuSE. So you get big regressions in server-related functionality like the one described in this article.
Things not to use on a server: Ubuntu, Fedora, Gentoo Things to use on a server: CentOS, RHEL, SuSE, possibly Debian, any of the BSDs.
The realistic choice for servers today is either Debian or CentOS. This is what you'll find in pretty much any large deployment and for good reasons.
Ubuntu may be a distant third candidate due to its recent popularity, however it was never really meant for servers. Many of their policies are problematic in a server-env and most of the perceived popularity stems from inexperienced people who, by default, use on their server what they know from their desktop.
And please don't recommend SuSE. That is really just cruel.
I was on board the Fedora train until recently, but I had to get off because it was changing from RHEL beta edition to... RHEL pre-alpha edition. I have a soft spot for SuSE, but I've never been a full-time sysadmin, so you have to take my recommendations with a grain of salt.
I have arch linux running now and while arch is not known for it's stability, I have far fewer applications crashing nowadays.