For the easiest install and friendliest desktop environment, you're probably better off with something like PC-BSD or GhostBSD than other options. PC-BSD is the more mature of the two, comes with an interesting alternative software installation and management system called PBI, and uses KDE by default. GhostBSD uses GNOME by default. I know that PC-BSD is based on FreeBSD, and I'm pretty sure that GhostBSD is as well. Neither is really to my taste, so I'm not too terribly familiar with either of them, but PC-BSD really is FreeBSD, just with extra tools, a default environment ready to install, and a different installer -- which, by the way, will actually let you install FreeBSD more directly than the slightly modified PC-BSD variant. In fact, I'm getting ready to use the PC-BSD installer to install a vanilla FreeBSD system in the near future (more on that in a moment).

QUOTE: Apotheon: WoW. You wrote two excellent articles in one response.

Thanks for the compliment. If CBSi had not decided to stop letting me contribute articles to TR for bureaucratic reasons, I would probably have submitted a couple of real articles -- better organized, more broadly useful in their final forms, more fully linked and otherwise referenced, and so on -- for publication by TR directly. C'est la vie.

QUOTE: I certainly would be better off learning the inner workings of BSD

That depends on a lot of things, and obviously you are best qualified to determine that. There are some things that may suit you better about certain Linux distributions.

In fact, I have been using a Linux distribution pretty heavily for almost exactly one year, because of lack of driver support for Sandybridge graphics architecture on FreeBSD. There has been work on that, though, paid for by the FreeBSD Foundation. Experimental support for the new GEM/KMS stuff needed to get the graphics architecture in my primary laptop working with FreeBSD has been included in a new PC-BSD installer, and I'm making preparations to install it on this laptop. Because of some local issues (e.g. my backup server is *full*, without any room for more drives, so I'm setting up a new server so I can back up the laptop in question before using the PC-BSD installer to install yet another OS on it -- FreeBSD, of course), there are some things I need to do before installing FreeBSD on the laptop, finally. I'm looking forward to it.

Vanilla FreeBSD is in many ways comparable to the major Linux distributions in much the same way the major Linux distributions were to MS Windows a decade ago: more stable, easier to fix if something goes wrong down the road (but much less likely to have such problems -- see "more stable" earlier in the sentence), and more easily and fully tweakable to suit your specific preferences if you have the technical knowledge, but sometimes requiring more technical know-how to get things set up to satisfy your preferences and needs. That last item sometimes proves more prohibitive than tolerable for some people's situations. I had been using Debian for a while, doing minimal installs then building up my environment from there using apt-get, when I started using FreeBSD in 2005; with that experience, I found FreeBSD only slightly more work to learn to use effectively than what would have been required for another major Linux distribution at the time. Things are of course a bit different now, in that switching Linux distributions for many people means just learning how to click around in a slightly different GUI environment. This is why PC-BSD or GhostBSD might be a better choice for many people -- people who have probably not had the same kind of experience with minimalist installs of some Linux distribution like Debian was then, like I used "back in the day". No reason not to give some kind of BSD Unix system a whirl, though; learning is always good, and if you stick with it you might find you like it more than whatever you had been using before that.

QUOTE: All the major distros have daily build development projects and a lot of users running their production machines with it.

This is true -- and, now that I think about it, I suppose some of those Linux community developers might end up with a feeling that it's okay to push alpha-quality software into production releases, or even lose the ability to meaningfully differentiate between alpha-quality software and release-quality software if they aren't careful (if they ever had that ability). I wonder if there is a newer generation of Linux community developers who simply never learned to differentiate meaningfully, having cut their teeth on alpha-quality software in the first place.

I don't know if this is related, but I know that a Drupal developer of my recent acquaintance has mentioned some troublesome differences between "old guard" developers and a new generation of open source developers, where the latter is very consciously "culturally sensitive". This later generation seems to be made up of people who expect everyone to notice they're female, or Pakistani, or gender dysphoric, or whatever, and value that as a contribution to the development community; the former (the "old guard") generation, meanwhile, had grown into a community that until recently valued people who could hack code well, and everyone tended more to leave his or her differences at the door. According to this Drupal developer's commentary -- and I find that this matches some of my own experience -- it used to be normal to regard other developers with whom one collaborates online as a username and a set of skills, with nobody pushing their non-coder labels on others expecting acknowledgement of them, but now the opposite seems to be increasingly true. I think such shifts are, however, slower to affect the BSD Unix community.

QUOTE: Once there is a frozen 'official' release developers would naturally be less than enthusiastic about looking backward to squash bugs.

I kinda get the impression that there's less of an impulse toward mentoring in open source software than used to be prevalent, for the most part. I think bug squashing used to be more commonly used as a way to mentor new developers in the community, pointing them at bugs to fix then reviewing their work, so that both old and new developers were involved in the bugfixing process. Now, it seems like nobody's interested in the mentoring process any longer. New developers want immediate recognition as top-quality contributors, and old developers want to work on stuff they find interesting in and of itself rather than fixing bugs and helping new developers. There are always exceptions, of course, but it seems like this is the case, and the new developers -- lacking the practiced discipline of auld -- are writing code from scratch to try to contribute something both because of the perception this will be worth more to them in terms of reputation and because they find it easier to embark on a brand new hair-brained scheme than to take the time to learn about someone else's code well enough to hunt down bugs and fix them. They're right, too; it's easier to write new code than tackle the complexities of old code when there's nobody available to help them out along the way. I suppose I might just be misreading the trail, though.