Slashdot Mirror

Won't boot with a Xen hypervisor (eg. Amazon AWS)

You're paying for RedHat, for a single instance? What the actual fuck, creimer?

ISHYGDDT.

https://www.centos.org/

$49 per year = peace of mind

Who the fuck is creimer??

You're paying for RedHat, for a single instance? What the actual fuck, creimer?

ISHYGDDT.

https://www.centos.org/

You seem to be implying that FreeBSD is going to immediately port all their 3rd party software to any new GCC that gets released in the future during the support period, but that is not actually how FreeBSD versions work

I didn't mention GCC. The default compiler for anything that hasn't actively been marked as requiring GCC is clang. The ports framework has flags to indicate required features of a compiler. If a port is marked as needing C++14, then it will be compiled with either the system compiler (if it supports one), or one from ports if required. The infrastructure for doing this is used automatically by the package-building infrastructure, so a port that needs a newer compiler than the one shipped in the base system will automatically get the one from ports.

The actual reality is that FreeBSD will get most new versions later than even Centos!

An assertion without evidence. We run a few CentOS machines at work and getting anything that needs a newer C++ version than was available when the base OS shipped is a huge amount of pain. Let's look at available packages for CentOS 7 and FreeBSD 10 (both released 2014 and still supported). What's the latest clang version available for them? Actually, that doesn't seem to be a fair comparison, because CentOS doesn't seem to include clang packages (and LLVM is only packaged for MESA) but, for reference, FreeBSD 10 has packages for clang 3.8 to to the 5.0 release branch (5.0 isn't yet out, but there are packages for the latest snapshot from the release branch). Okay, let's make a more fair comparison: how about gcc, since that's the system compiler for CentOS? Well, the CentOS package list has a compat package for GCC 4.4 for compiling older stuff, and an up-to-date package for GCC 4.8.5 (released June 2015), which predates most C++14 features. So, as I said, compiling C++14 code on CentOS is a pain. Okay, let's look at FreeBSD. GCC isn't the system compiler and you've said it lags updates and is behind CentOS, so I guess it will be older? I see packages for GCC 4.6, 4.7, 4.8, 4.9, 5.4 (after 5.0, GCC changed its release numbering, so 5.x is a release series, previously 4.9.x was a release series), 6.4, 7.11, and the (unreleased) 8 release branch.

And no, they don't just slavishly follow the upstream release schedule, they actually couldn't do what you imply if they wanted to because so much of their 3rd party software gets local changes to make it more secure, which then isolates them from upstream and means new versions have to be basically back-ported. So you don't even get all the released versions.

Again, look in the ports collection (follow the svnweb link next to any port to see the history of files that have changed). Most ports have no patches, or trivial ones to change a couple of paths in the build system, and these typically don't change much between upstream versions other than being removed if they're upstreamed.

Stable is only useful if it's both stable and usable. The system ABIs across a stable FreeBSD release series are guaranteed to be compatible, but that doesn't mean that you can't run newer software and there's little use in a system with long-term support if support just means 'we won't change anything' - that's not support, that's atrophy.

When I install yum-cron and only select security updates, how is that not the same?

Doesn't work. The security updates are not tagged as such in those repos, that's a feature available only in paid versions of RH repos.

See this discussion for instance: https://serverfault.com/questi...
or
https://bugs.centos.org/view.p...

I don't know what exactly you see in your list but it's probably everything, not just security ones.

The only way to do it would be to piggyback on the updates in a valid RHEL subscription to pick & choose, but I'm pretty sure that would break the EULA.

What about RHEL 6.9 and CentOS 6.9? Most recent version with a heavily patched 2.6.32.

I looked it up a bit and it turns out on kernel 2.6.32-696 yes Kaby Lake pretty much does work.

https://www.centos.org/forums/...
https://www.centos.org/forums/...

What about RHEL 6.9 and CentOS 6.9? Most recent version with a heavily patched 2.6.32.

I looked it up a bit and it turns out on kernel 2.6.32-696 yes Kaby Lake pretty much does work.

https://www.centos.org/forums/...
https://www.centos.org/forums/...

"I've yet to see a linux distribution supported for even 7 years, let alone the 10 minimum guaranteed by MS."

You haven't heard of Red Hat, or CentOS?

RHEL5 reached end of standard support yesterday, after just over 10 years. Extended support is available for anothwr 2.5 years:
https://access.redhat.com/supp...

CentOS 5/6/7 have the same lifecycle:
https://linuxlifecycle.com/

  https://wiki.centos.org/About/...

  "Windows can guarantee you a decade of security updates for a platform. I have to get it the edge here."

Only because you seem uninformed or too lazy to do any research.

"Additionally, if you're hosting yourself, and you run VMs, once you've licensed data center edition on the basic hardware, you can spin up as many Windows VMs on that hardware as you need at no extra cost."

Red Hat has similar options, and subscriptions on their RHEV+unlimited supported VMs gives you the same capabilities as VMWare vSphere Enterprise for less than just the vSphere licensing/SnS (so you basically get unlimitrd supported VMs for free).

I didn't compare to HyperV because MS was anal enough about licensing a Windows VM for the vCenter server (must pay per CPU-month for every CPU that could potentially run the VM) that we migrated as soon as possible to the vCenter Server Appliance because we spent almost as much licensing one Windows VM as on vSphere for a 6-machine vSphere cluster.

Of course, if you don't need support, you can run ovirt (community version of RHEV) on CentOS (or Debian) with unlimited CentOS (or Ubuntu or Debian) VMs, for no software cost. Or there are other options for containet-based clusters.

The topic was not, how to obtain a compiler, but whether or not to compile an application — Firefox — from source. The compiler is part of the operating system — if it is any good, anyway

Thank you for pointing out another dimension of the actual debate: what constitutes the "operating system". By a definition of "operating system" that includes a compiler, everything in Debian main or Ubuntu main might be considered part of the "operating system". This includes everything recompiled by the distributor (Debian or Canonical) and shipped on the install disc, including Firefox. Others believe that the kernel is the "operating system" and the entire userspace is "applications".

If all you've got on your choice of OS is either using binaries somebody else compiled for you or a completely unaided manual rebuild, your choice was really poor...

The Debian and Fedora distribution families give users the option to download packages that contain source code instead of executable code, which can be compiled to a binary package and installed. Though the option is there, it's just rarely used by end users.

This isn't even extended support. CentOS 5 is in Extended support until March 31st 2017, 6 is mainstream until that date and extended until November 30th 2020, 7 is mainstream until that date in 2020 and extended support until 2024. See: https://wiki.centos.org/About/... for more info and the latest version of different software on the different releases.

https://www.centos.org/legal/t...
The CentOS Marks are trademarks of Red Hat, Inc. (âoeRed Hatâ).

That said, the source code is open and CentOS remains a "community project". RedHat could certainly legally close the doors of CentOS and the community could just reassemble under a different name.

Where did you pull 8 more years out of? CentOS6 only gets full updates through 2017. Security errata and SELECT mission critical bug fixes through 2020. That's emphatically NOT support for new hardware.

What have you had trouble finding? https://github.com/ansible/ans... http://vault.centos.org/ http://www.jboss.org/downloads... https://github.com/wildfly/wil...

Distinction is in "official" and "endorsed by", etc. But that's beside the point. You can say it's based on Linux, includes it, etc, but you can't claim to be Linux using their trademarks.

Closer comparisons are how CentOS can't claim to be Red Hat: https://wiki.centos.org/RedHat and the aforementioned Iceweasel project not claiming to be Firefox: https://en.wikipedia.org/wiki/...

The lines are less clear in cases where the organizations have granted permission to some groups to use their mark in other ways

Or, as usual, do the same thing with CentOS for free.

https://wiki.centos.org/HowTos...

I don't get the animosity towards RH. I haven't paid for their support in years and years, but when I did, it was so I could call somebody when something went wrong and get reliable help quickly.

I only ever had to call a couple times, but the support I got was better than I ever received from most companies.

Oracle? Oracle is on the opposite end of that list. I won't touch Oracle ever again if I can help it. I am aware of the things Oracle brings to the table but it's not worth the pain.

FWIW, it seems CentOS 6 was not updated (though there is an SRPM from RHEL for it).

The update is in the CR repo because of the preparations for the release of CentOS 6.7. Short explanation here (with the link to the page explaining how to enable the additional repo), and a couple of longer explanations further down the thread.

Right, it's because Centos 6.7 hasn't been released yet and Red Hat has't made upgrade for RHEL 6.6.

Thus if you had RHEL 6.6 and hadn't yet upgraded 6.7 you would have same situation.

But, fortunately there is a solution available, which you may choose to take. Upgrade to continuous release version and get upgrades from there before official point release is available.

What you need to do is simply

# yum install centos-release-cr

Make sure you have enough free space available for several hundred packaces (/var/cache/yum/) and doing 6.6 to CR-upgrade which is quite close to 6.7, then

# yum clean all
# yum upgrade

Then it's probably a good idea to boot after that, too get new kernel etc. stuff

Cheers,

ac

This kind of information is usually avalable from the mailing list & archives of the list for the release you use, as the case here too. There you have answer , check the thread and read CR wiki page pointed from that answer, please.

A heads up for those running CentOS 6.6. This issue is not patched by default (because CentOS is in the midst of the transition from 6.6 to 6.7). Sysadmins using bog-standard CentOS 6.6 bind will need to enable the continuous release (CR) repository and update bind using that.

See the CentOS 6 Security Support forum post CVE-2015-5477 patch for centos 6

Wondering if this issue is serious enough to warrant the CentOS folk putting some patched bind rpms in the CentOS 6.6 updates repo? My guess is that a lot of people might miss the patch otherwise.

FWIW, it seems CentOS 6 was not updated (though there is an SRPM from RHEL for it).
CentOS 5 and 7 both have the update. Example mirror:
http://mirror.atlanticmetro.ne...
http://mirror.atlanticmetro.ne...
http://mirror.atlanticmetro.ne...

I also checked the mirror status: http://mirror-status.centos.or...
And checked one that was JUST updated: http://mirror.millry.co/CentOS...
No update!!!

RHEL page on their 6.x update: https://rhn.redhat.com/errata/...

Unfortunately, many git authors refuse to use signed tags for a variety of reasons. For a large scale example of this as a matter of corporate policy, review https://git.centos.org./ This is now the official public repository for Red Hat Enteprise Linux 7 public source code. I'm afraid that they adamantly refuse to use "tags" for publishing particular software versions of their content and instead rely on the word "import" in their git logs to indicate the released versions of source code.

A great deal of similarly casual handling of git security is in use at github, at Sourceforge, and was in use at gitorious. Not all software authors are very careful about ensuring the security of their published code.

I'm not sure if this meets your expectation, but a test can be accomplished using the option ExecStartPost. This method is being used in the current Fedora package for MariaDB to test for active database using an additional script called mariadb-wait-ready.

ExecStartPre=, ExecStartPost=
Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=, except that multiple command lines are allowed and the commands are executed one after the other, serially.

If any of those commands (not prefixed with "-") fail, the rest are not executed and the unit is considered failed.

systemd.service

mariadb-wait-ready described as:

# This script waits for mysqld to be ready to accept connections
# (which can be many seconds or even minutes after launch, if there's
# a lot of crash-recovery work to do).
# Running this as ExecStartPost is useful so that services declared as
# "After mysqld" won't be started until the database is really ready.

The mariadb-wait-ready script uses the following command:

/usr/bin/mysqladmin --no-defaults --socket="$socketfile" --user=UNKNOWN_MYSQL_USER ping

I felt it was enough a problem to submit a bug report to the CentOS people: https://bugs.centos.org/view.p... -- the problem I see is that the documentation for systemd and the observed results are different. Further, there are no instructions on how to take a System V init and convert it cleanly to systemd. I don't have a Red Hat Enterprise support license, so I couldn't report the issue to Red Hat. One of the problem of using an alternate distribution.

To this developer's eye, the systemd documentation is not ready for prime time. Note that this bug was reported against 6.5, not 7. I'll be looking at 7 when I get a round tuit.

That is a upstart bug, not a systemd bug.

I felt it was enough a problem to submit a bug report to the CentOS people: https://bugs.centos.org/view.p... -- the problem I see is that the documentation for systemd and the observed results are different. Further, there are no instructions on how to take a System V init and convert it cleanly to systemd. I don't have a Red Hat Enterprise support license, so I couldn't report the issue to Red Hat. One of the problem of using an alternate distribution.

To this developer's eye, the systemd documentation is not ready for prime time. Note that this bug was reported against 6.5, not 7. I'll be looking at 7 when I get a round tuit.

So why is your bug filed against upstart?

I felt it was enough a problem to submit a bug report to the CentOS people: https://bugs.centos.org/view.p... -- the problem I see is that the documentation for systemd and the observed results are different. Further, there are no instructions on how to take a System V init and convert it cleanly to systemd. I don't have a Red Hat Enterprise support license, so I couldn't report the issue to Red Hat. One of the problem of using an alternate distribution.

To this developer's eye, the systemd documentation is not ready for prime time. Note that this bug was reported against 6.5, not 7. I'll be looking at 7 when I get a round tuit.

Per: http://lists.centos.org/piperm...

"= Given the popularity of the minimal install ISO in CentOS-6, we are
going to try and deliver a minimal install ISO for CentOS-7 as well.
One key challenge here is that the installer image has grown to nearly
360MB, and getting enough content into a CD size image is proving hard."

Dude, you must have taken your tin foil hat off .. I could see you for a second.

All those /// are coming from screwed up mirror/spider software (you probably wrote it) that is does not properly pay attention to robos.txt and does not properly query the tree. We didn't see it in testing becuase we queried the tree correctly. We are working with gitblit (the open source software git.centos.org is hosted with), to get this bug fixed and we will be rolling it in soon now that we have CentOS-7 released:

http://code.google.com/p/gitbl...

If you do a dig for the ipaddress and look at the location, git.centos.org is not hosted in a Red Hat datacenter.

You also must not have seen the more than 500 mirrors wrldwide that host CentOS content:
http://www.centos.org/download...

So, other than every single point of your post being wrong, it was a very well and thought out piece of writing.

That is only partially true .. RHEL 7 does not have an i386 version. However, CentOS does plan to have one as a secondary arch ... IF ... we can get it to build: http://lists.centos.org/piperm...

RHEL too, but that will cost you

I have downloaded before a full version, non-evaluation, fully working copy of RHEL before.... I believe this option still exists for those seeking it, but it is one of those well kept secrets and the link is burried deep somewhere at Red Hat's site. i.e. RHEL can be used for free, without support. It is possible Red Hat may have discontinued this for the "30 day evaluation" variety of free download, and that download link is gone forever, but regardless, Red Hat does not sell operating systems, they sell support, and that is what you pay for that costs. However, CentOS is identical to RHEL and is free to download and use, i.e. costs nothing. Oracle Linux is also RHEL, and also free to download and use, I believe. So no, if you don't pay for the support, using RHEL will cost you nothing.

It's actually a flipping nightmare. *EVERYTHING* based on SRPM management and building for testing or modifying components is now broken, effectively unannounced. The new git repository effectly has only "master" branches, and you have deduce and guess or cast a ouija board to figure out what the SRPM package name is from the published .spec file. And there are no GPG signatures associated with the new git repo, and no tags.

So, if you're anybody but CentOS, who have verifiable internal access to Red Hat's internal repositories to run checks against, you are *shit-out-of-luck* trying to do a verified RHEL rebuild. There is no structure apparent for segregating RHEL clean vendor versions and specific package versions, you just have to try and guess from .spac files, and *pray* that no changes in the source code were made to the git repo after the .spec file was last altered.]

I'd like to go over to the telecommuting desks the CentOS guys are using and slap them upside with a cluebat, chanting "learn to use tags! learn to spell GPG! learn to separate your code from upstream". The CentOS crew has *never* been good about making clear which components are built from clean RHEL SRPM's, and which are built from their modified SRPM's, they've always casually kept them in the same directory of published source, and it is *nasty* to sort out the modifications.

The switch to git based publication is helpful to CentOS friends and community members, since in theory they'll get a better look at the change logs for CentOS modifications. But it has *none*, *zip*, *zero*, *nada* of the upsream RHEL git history, it's based on a pure "grab a copy of the files from upstream, import them into git". That cuts off git history, and is an undocumented process, so no one outside knows how the CentOS folks actually did it, or whether it was prone to git history errors. (Ideally, it would have been done form RHEL SRPM's, not from a git export, to avoid version skew.)

This is causing screaming among the folks who do RHEL rebuilds. It's understandable that RHEL need not make life easy for us, and the freeware and open source nature of RHEL have sometimes been abused and proprietized. (I'm staring at you and your "UnPatchable Linux", Oracle!!!) But this this approach was designed by a committee led by a pointy-haired boss.

And do not get me *started* on that user interface at https://git.centos.org/. It violates every single one of the design guidelines of Eric Raymond's guidelines on open source interface, "The Luxury of Ignorance", parts I and II.

I was going to the FTP site to look at the sources, but apparently they have moved.

Current sources for Red Hat Enterprise Linux 7 have been moved to the following location:

https://git.centos.org/project...

That's a bit cool actually.

RHEL updates are available:

https://rhn.redhat.com/errata/RHSA-2014-0376.html

CentOS updates are available:

http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html

Fedora updates are available, hitting the mirrors, but you can get it earlier, instructions here:

https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html

https://lists.fedoraproject.org/pipermail/announce/2014-April/003206.html

On a personal level, I have always liked the NX Protocol. It's easily installable on Ubuntu or CentOS. You can choose between the free and open source route, or for an enterprise roadmap, NoMachine reigns supreme in my experience.

NoMachine packages its free client/server solution for what seems to be any gnu/linux distro. Its IOS and Android clients are due for release in the coming months and can solve the original poster's "problem". I have no affiliation with nomachine other than being a bit of a fan due to their community commitments.

In all reality it becomes a matter of servers, clients, and protocols that fit within your network's architecture with varying degrees of comfort and performance.

I've suggested previously, even before the post-Snowden cloud/privacy concerns, that Microsoft could be in a very strong position if they swam across the current a little and promoted private clouds.

That is not a significant strength for Microsoft. There is no philosophical advantage to closed-source infrastructure compared to freedom-respecting software. Microsoft might win a bunch of sales because of their tight integration and simplified controls, but if you're worried about privacy, then Microsoft is not the way to go.

If you're doing a cloud deployment and you're worried about privacy, then the only real solution is to go to some open-source cloud system.

I have no idea whatsoever why this is modded insightful. Maybe you can shed some light on what newer packages does centos have that rhel doesn't? Looking at http://mirror.centos.org/centos/6/ and http://wiki.centos.org/AdditionalResources/Repositories centosplus, contrib, and extras barely have more than a handful of packages together. Even testing is mostly just autocorr and libreoffice...

I have no idea whatsoever why this is modded insightful. Maybe you can shed some light on what newer packages does centos have that rhel doesn't? Looking at http://mirror.centos.org/centos/6/ and http://wiki.centos.org/AdditionalResources/Repositories centosplus, contrib, and extras barely have more than a handful of packages together. Even testing is mostly just autocorr and libreoffice...

Spacewalk (which is the 'upstream' version of RH's Satellite, btw) and puppet aren't exactly intended to do the same things, AFAIK. Google has some useful results, inc. http://www.brightprocess.com/?p=306 and http://lists.centos.org/pipermail/centos/2009-November/085138.html . I'm no expert on the field (I'm much more down at the duct tape end) but it looks like people actually tend to use both together.

iptables can be fantastically complex and powerful to protect enterprise networks from all manner of attack. It is also fast and easy to do a simple, basic, strong setup which will provide a powerful firewall to secure a server.

Some useful iptables tutorials and references:

1) From CentOS, but iptables runs the same way regardless of OS. This one creates a pretty solid simple iptables ruleset to protect a server.

2) An Ubuntu tutorial, again simple and informative.

3) From the netfilter/iptables project homepage. Good primer on network concepts too.

4) Deeper information, but very useful. Another good discussion of network concepts.

I recommend typing in a simple text file with the iptables commands, the chmod'ing it so that it is executable. Then execute it ("./myrules"). This works for a small, but powerful list of rules that can protect a server. Some of the tutorials talk of rulesets with thousands of lines. There are different, more efficient ways to load those.

Quick overview of iptables:
1) There are three default chains (containers which sets of rules) called INPUT, FORWARD and OUTPUT.

2) Each of these can have a default policy of ACCEPT or DROP. Input should have a default policy of drop. IMPORTANT - while you're first playing with iptables, make sure input has a default policy of Accept ("iptables -P INPUT ACCEPT") or you may well lock yourself out of your machine. Once you've got the rules set up as you'd like (you view the rules with "iptables -L -v"), then you can do "iptables -P INPUT DROP".

3) Always set these three "housekeeping" or basic rules (prefacing with a '#' is a comment):

# For the loopback interface 127.0.0.1, accept everything. Append to input chain.
iptables -A INPUT -i lo -j ACCEPT
# For ICMP packets, accept pings only
iptables -A INPUT -p ICMP --icmp-type echo-request -j ACCEPT
# For established connections, accept everything, using the older state module
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

4) Your input chain, which deals with incoming packets, will have a default policy of drop. Only ports which are then specifically allowed will be open:

# Accept SSH on port 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Accept HTTP on port 80
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Accept HTTPS on port 443
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

5) You're not using your box as a router, so your FORWARD chain should not get any activity. I leave the policy as Accept, so if there is any traffic logged here, I know something unusual is going on:

# Otherwise, accept all for FORWARD
iptables -P FORWARD ACCEPT

6) Finally your output chain should just allow everything:

# Accept everything:
iptables -P OUTPUT ACCEPT

7) Check your iptables ruleset with "iptables -L -v". If everything looks good, set your default input policy to drop with "iptables -P INPUT DROP"

And that is a spiffy, powerful way to block all ports but 22 (ssh), 80 (http) and 443 (https) by using iptables.

And more to the specific technical point, there's no easy, supported migration path from 5.x to 6.x.. The Centos Wiki howto page states with discouraging repetetiveness "A fresh install is generally strongly preferred over an upgrade. "

This, plus a host of not-very-specific "gotcha" warnings, and the entire guide ending with "Good luck", pretty much guarantees only the masochistic or the suicidally brave will undertake an upgrade-in-place to 6.x, rather than just staying with 5.x and picking up the point updates for security and reliability updates.

For myself, I'm running 5.x on my household server, and I'll be yum-updating to pick up 5.9. I'll migrate to 6.x when I do a full server hardware refresh, in which case it'll be a turnkey replacement with the possibility of limited parallel ops and fallback if it all goes sideways.

Their rpm announcements were all back dated.

They didn't release any of the 5.9 rpms on the dates they are making public.

You mean the packages that were released prior to the 5.9 install media in the Continuous Release repo? Perhaps you should review this page - http://wiki.centos.org/AdditionalResources/Repositories/CR

What other manufacturer provides quick fixes for a decade old OS that is now three versions out of date? Red Hat and CentOS https://access.redhat.com/support/policy/updates/errata/ http://wiki.centos.org/

I don't see any indication that a) this has any relation to the size of the directory

The cited bug points out a problem with readdir(). This manifests itself as failures with other software, including dovecot (where maildir is used) and bonnie++. Some of those other bugs were reported and marked as duplicates, some weren't.

Ultimately it boiled down to a flaw in Linux NFS that was fixed by Trond Myklebust and was still perculating through distributions over a year later.

Never in years has it given me one problem, but hey, that's just me.

Yeah, that's just you. Me? I've been watching hapless administrators discover NFS flaws since the 90's and I have long since abandoned NFS as a serious tool for production operations. It's fine in most cases as a file share for interactive use (/home and ad hoc shares) and not much else. Under certain conditions with extremely good NFS implementations (netapp, for example) you can pull it off. The other 99% of the time it's just a mistake.

It's not Tuttle, Oklahoma is it?

with good old GNOME 2.32 to at least 2017

2020 according to this:
http://wiki.centos.org/FAQ/General#head-fe8a0be91ee3e7dea812e8694491e1dde5b75e6d

Gee. Isn't life tough. As I remember from eons ago, Windows is AT LEAST as wrenching. If you're REALLY serious about stability, reliability and freedom from bloat a la systemd, udev, plymouth, la de da, and are willing to invest time up front in return for that continuing stability, allow me to suggest trying out FreeBSD or its desktop friendly derivative, PC-BSD. This would require some real dedication to learn the idiosyncracies. Just to clear one thing up, FreeBSD isn't rocket science to install a DE on. I was doing it a decade ago without much trouble. It doesn't hold your hand and automate everything like PC-BSD does, though.

If you mostly just want a linux desktop that doesn't put you through effing with big changes every year to stay supported, you could do what I did. Install Redhat Enterprise 6 or any of its free derivatives (notably CentOS, Scientific Linux, PUIAS Linux). That way you're good to stay on the same major release, fully supported, hardware-and-feature-back-ported, bug-fixed, and security-updated with good old GNOME 2.32 to at least 2017. I'm a little worried about what RHEL 7's default desktop will look like when it rolls out maybe some time during 2014, but I'm very confident you'll just be able to choose Xfce (as you can now in 6), and anyway there's really no need to make the jump from 6 to 7 until 2017.

I used to be fearful, about 5 years ago. The first step is to make sure you have a really solid backup plan. I have a home server which I use rsnapshot to to store rsync diffs. This can be performed as often as I like (hourly, once per boot, weekly, etc), or even automated (I don't as I don't want the hassle of having to wait for a backup to finish before I shutdown/hibernate).

Once you think you have a solid backup plan, pretend you just lost your hard drive. The best method is to have a second system (or second hard drive, and swap out your real one) to which you will restore to and not touch your original. Once you truly know you have everything backed up and don't need anything from the original system, move to encrypting your disk.

Oh, and what good is encrypting your disk if you don't encrypt your backup? Naturally you want to trust your backup to be solid (especially during system upgrades/migrations when the originaal is at risk), so you're going to want to have two backup devices. Server + external USB hard drive is a nice solution. I'm a big fan of offline storage (only servers have to have the key in memory and thus have the encrypted data available), so I have two external USB hard drives which I rotate. Fire or other disasters may happen, so I rotate that external hard drive to work, then bring the one at work back home. Worst case I may lose 2 weeks of data (which would be minimal, as any major changes of data trigger a home/work external hard drive swap). Take a step further and have a third hard drive you keep off site at a family member's house 30+ miles away (thinking flood plains here). Rotate taking a drive to that location and bringing it back on family visits.

Ok, sorry to digress. Now, when I install, since I know I'm not going to lose any data, I do full encryption on all newer systems that aren't "budget" boxes. I've got a number of hand-me-down laptops (P4, other pre-Intel Core processors, etc.) that the family uses, which still work just fine for simple school research, writing a report, etc. For these systems, I partition things out and encrypt: /home /tmp /var/tmp swap. The rest is part of / and not encrypted for performance reasons.

I've been doing this for 5 years and a dozen laptops and 5 external USB hard drives and never had a problem due to disk encryption. Many of my laptops don't detect the battery power accurately any more, so I've had a handful of sudden "off" situations where the system shutdown uncleanly. Never been a problem and once the disk is decrypted ext4 does it's thing and I keep going.

I have had a failed hard drive in that time. I typically keep the OEM OS and resize it and keep it set to dual-boot so I can "troubleshoot" with the manufacturer. The nice thing about having all my personal data encrypted is that when I had a failed drive, I had no worries sending it back to them as I knew they could not access anything.

I too have run into the issue with Linux not wanting to automatically re-mount the drive when I plug it back in. I also have manual scripts to do all the LUKS scripts (for this reason, and also on my servers which have no GUI, or when using a recovery CD where I want to know exactly how to access my data), and those will work in cases like that.

Here are the rough notes:
# http://wiki.centos.org/HowTos/EncryptedFilesystem

losetup /dev/loop7 /dev/sdb1
cryptsetup luksOpen /dev/loop7 secretfs7
# password prompt here
cryptsetup status secretfs7

#/dev/mapper/secretfs7 is now active:
# cipher: aes-cbc-essiv:sha256
# keysize: 256 bits
# device: /dev/loop7
# offset: 2056 sectors
# size: 3907021946 sectors
# mode: read/write

mount /dev/mapper/secretfs7 /mnt/usb7/

#########
umount /mnt/usb7/
#cryptsetup remove secretfs7
cryptsetup luksClose secretfs7
losetup -d /dev/loop7

RHEL and Centos are not affected by this issue:

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-2122

http://lists.centos.org/pipermail/centos/2012-June/126719.html

I mean, outside of fedora, Ubuntu, Xubuntu (maybe Mint) and Slackware, what's the point?

How about, "I want something like Fedora, but which does not require a yearly upgrade that will inevitably break things?" Now, where might I find such a disto, without having to pay for it...

http://www.centos.org/

(In reality, I use ScientificLinux, but both basically follow RHEL)

Distros are not forked just for fun. Sometimes there are real disagreements over how packages should be managed, what new features are important, what patches are worth applying, etc. I do not need the latest eye candy and I do not really have the time for things to mysteriously break, but other people want the latest eye candy and are willing to fix broken things.

Hundreds of distros may seem excessive, but a lot of those are just small communities of people with similar enough aims.

Red Hat doesn't operate like an "open source" company.
  They're making money precisely because they operate as close to a proprietary company as possible without violating the GPL.

Um, yes it does.

The source code for all their stuff is available for free here: http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/.

They don't have to do that. They are only obligated to provide the source on request for a reasonable copying fee to people to whom they distribute binaries to. Instead, they make it freely available to anyone who wants it, without charging a cent for the bandwidth.

Speaking of cents, you can get CentOS, which is identical to RHEL minus the branding entirely for free because RedHat make the sources available freely. Also, redhat make the sources avaialble for non GPL software which they simply don't have to do.

So, the claim that they are as proprietary as possible is simply false.

I don't have any problem with you switching distros for any reason, but wouldn't it be a little more constructive to at least have a LOGICAL and VALID reason? In 12.04, as for any version since a long time ago, you can just install the xubuntu variant, or (not QUITE as clean) just apt-get install the xfce desktop environment. It just isn't so that with the release of 12.04 you will be "forced" to either use gnome3 or switch distros.

PS - I'm not a ubuntu guy myself (I don't particularly like any of the debian camp), and I realize you can readily construct a logical and valid reason to abandon it - but you didn't mention such a reason.

PPS - what I am using is an RHEL6 free repackaging - PUIAS in my case, but CentOS or Scientific Linux is just as good - and I am good with Gnome2 until 2017. Or I could just as well be running Xfce or KDE on it. I really cannot recommend this set of distros enough.

There are good and valid reasons why Centos is currently falling behind RHEL in doing updates. Red Hat is making it more difficult for Centos to keep up. This may not be intended to target Centos, but rather Oracle who has been using Red Hat's own work to sell a competing tech support service.

However, Centos gets caught in the crossfire. This email from Johnny Hughes lays out some of the issues that Centos now has to deal with that were never an issue before.

Here is what he has to say:

QUOTE:
Yes, and NOW the release process is MUCH harder.

Red Hat used to have an AS release that contained everything ... we build that and we get everything. Nice and simple. Build all the packages, look at it against the AS iso set ... done. Two weeks was about as long as it took.

Now, for version 6, they have:

Red Hat Enterprise Linux Server (v. 6)
Red Hat Enterprise Linux Workstation (v. 6)
Red Hat Enterprise Linux Desktop (v. 6)
Red Hat Enterprise Linux HPC Node (v. 6)
Red Hat Enterprise Linux Workstation FasTrack (v. 6)
Red Hat Enterprise Linux Server FasTrack (v. 6)
Red Hat Enterprise Linux Desktop FasTrack (v. 6)
Red Hat Enterprise Linux Scalable File System (v. 6)
Red Hat Enterprise Linux Resilient Storage (v. 6)
Red Hat Enterprise Linux Load Balancer (v. 6)
Red Hat Enterprise Linux HPC Node FasTrack (v. 6)
Red Hat Enterprise Linux High Performance Network (v. 6)
Red Hat Enterprise Virtualization

They have the same install groups with different packages based on the above groupings, so we have to do some kind of custom generation of the comps files to things work.

They have created an optional channel in several of those groupings that is only accessible via RHN and they do not put those RPMS on any ISOs ... and they have completely changed their "Authorized Use Policy" so that we can NOT login to RHN and use anything that is not on a public
FTP server or on an ISO set ... effectively cutting us off from the ability to check anything on the optional channel.

Now we have to engineer a compilation of all those groupings, we have to figure out what parts of the optional channels go at the point release and which ones do not (the ones that are upgrades). Sometimes the only way to tell is when something does not build correctly and you have reverse an optional package to a previous version for the build, etc.

We have to use anaconda to build our ISOs and upstream is using "something else" to build theirs .. so anaconda NEVER works anymore out of the box. We get ISOs (or usb images) that do not work and have to basically redesign anaconda.

We can't look at upstream build logs, we can't get all the binary RPMs for testing and be within the Terms of Service.

And with the new release, it seems that they have purposely broken the rpmmacros, and do not care to fix it:

https://bugzilla.redhat.com/show_bug.cgi?id=743229

So, trust me, it is MUCH more complicated now than it was with previous releases to build.

With the 5.7 release, there were several SRPMS that did not make it to the public FTP server without much prompting from us. And with the Authorized Use Policy, I can not just go to RHN and grab that SRPM and use it. If it is not public, we can no longer release it.

So, the short answer is, it now takes longer.
END OF QUOTE