Date: Tue, 24 Jan 2012 23:14:33 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: atom@smasher.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <201201250714.q0P7EXth060018@gw.catspoiler.org> In-Reply-To: <alpine.DEB.2.00.1201171333550.21214@oreo.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 Jan, Atom Smasher wrote: > thanks john. > > i've been a long-time (10+ years) freeBSD user (desktops, laptops, > servers, and anywhere else i can run it) and advocate (encouraging others > to at least check it out) and also a long-time satisfied johnco customer. > > my freeBSD days seem to be coming to an end. > > i bought myself a LENOVO T510 when it first came out, around early 2010. > it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i > STILL can't run xorg properly with it. linux has run fine with it since i > opened the box. last i checked, freeBSD will be support this GPU in R9... > or maybe R10...? > > i really like freeBSD's robustness, especially compared to linux, among > other things. i like that freeBSD is genetically a "real" unix... what's > the real difference between BSD and linux? BSD was developed by unix > hackers porting the OS to PC hardware; linux was developed by PC hackers > trying to make their own version of unix. these origins are still very > apparent, if one knows where to look. > > i like that i can set up a freeBSD bare-bones (eg secure) mail-server or > web-server in an afternoon. > > but none of that matters if the damn thing just doesn't work. > > over the last two years, and it pains me to say this, i've been running > linux on that T510. but it gets worse... i've been finding that i'm simply > more productive on that machine, and spending more time in front of it, > and more time getting useful things done. > > i understand that it's ultimately a matter of manpower and resources, and > linux seems to have more momentum and "sex appeal", but i'm finding myself > in a real crisis of faith... the OS that i've been using and loving for > 10+ years seems to be dying, from any real usability perspective. > > and for now, i'm slowly and reluctantly migrating towards linux. My experience has been pretty much the opposite. I've been using FreeBSD since 2.1 both as part of my job and also for personal use. I've been using Linux for work for about the last ten years. I'm currently running FreeBSD 8.2-STABLE for my personal computing needs. My experience is that the base system has been very solid and the only problems that I run into have been with the ports. The last major problem that I had with the base system was USB printer support in 7.x, which was incomplete and flakey and then deteriorated to the point of being unusable. This motivated me to migrate to 8 which has a rewritten USB implementation. At work, our major software vendor only supports their software on Red Hat Enterprise Linux and SUSE Linux Enterprise. Since our budget is tight, we run CentOS, which is essentially a repackaged version of RHEL. We've been running CentOS 4.x, but are switching to CentOS 5.x now that 4.x has been EOLed. My experience with CentOS is that new features and support for recent hardware lags quite a bit. A few years ago I had a motherboard that I liked a lot that ran Fedora just fine, but CentOS lacked support for. It took a very long time before CentOS supported NFS over TCP. This was especially painful because we rely heavily on NFS across a WAN to support access to the same data from diferent sites. In addition our WAN is implemented using IPSEC tunnels, which have a smaller MTU, and Linux doesn't support manually setting the MTU on a per-route basis (and I wasn't able to get PMUTD to work). What I observed was that the NFS packets would first be fragmented to the default 1500 byte MTU and then the firewall would fragment each of those packets into one large packet followed by a tiny one. This, along with the lack of TCP's congestion control, was not beneficial to NFS performance ... Bugs are also slow to get fixed. For a very long time I had problems with gam_server running away. I'd frequently start top and see gam_server pegged at 100% CPU, stealing time from my simulations. If I killed it, it would get respawed, and would then behave itself for a few days before running away again. This bug eventually got fixed, but there's a kwin bug in CentOS 4 that still hasn't been fixed. Every now an then, kwin will stop working and I can no longer move windows around my desktop. I'm pretty sure this is fixed in a newer version of KDE, but RHEL/CentOS tend to stick with one major version of their "ports" forever, so I probably couldn't expect to see this fixed until I upgrade to the next version of CentOS. Things might be different if I was a paying RHEL customer and was able to motivate Red Hat into back porting patches for particular bugs. Another "feature" that I get to enjoy on a daily basis is that the kernel in CentOS 4 does not like my KVM switch. When switching to my CentOS machine, I have about a 50% chance that any mouse movement will cause the cursor to fly all over the screen and spew random mouse clicks all over my desktop. This typically causes a bunch of windows to pop up, and it also usually causes parts of email messages to get pasted into my shell windows. That causes a lot of command not found messages as well as the creation of a bunch of unwanted files because of the > email quote character. I can fix the mouse problem by switching to a text vty and running a script to reset the mouse, but if I try to do this proactively and the mouse isn't in a confused state when I run the script, that also confuses the mouse and the only means of recovery is to unplug the mouse and plug it back in. The same KVM switch works flawlessly with both FreeBSD and older Linux kernels. Supposedly the code that someone inserted into the Linux kernel to detect the problem and automagically reset the mouse got yanked out, with the suggestion to buy better KVM switches. I also run Fedora 14 on one machine at home for MythTV. Hardware support is a lot quicker to show up in Fedora than it is in CentOS, but it still isn't great. A recent example is that I tried to expand my storage this last weekend by adding an external enclosure containing a couple of drives plugged into an ESATA port multiplier backplane. I had to plug a new ESATA HBA into one of the PCI Express slots in the motherboard to drive it. The first HBA I tried uses the Asmedia 1061 controller. It's BIOS was able to communicate with the port multiplier and find both drives, but once the Linux kernel took over, it reset things a bunch of times, complained about not being able to clear an error, and gave up. Just for grins, I plugged this same card into a FreeBSD box running 8.2-STABLE and was able to see both drives. I also happened have another HBA with a Marvell controller. I tried that in the Fedora box, but the drives never showed up. After much head scratching and Googling, I finally figured out that the controller was a Marvell 9128, which didn't get Linux support until the 3.x kernel. Looks like I'll have to upgrade to Fedora 16 for that ... The downside to the faster hardware support in Fedora is the very rapid turnover of its major releases. There are new major releases per year and each release gets EOLed when version N+2 is released, so it's necessary to upgrade major releases way more than I'd like. In addition to new features and new hardware support each major release seems to come with its own set of "surprises" as well. The first one that bit me with the upgrade to Fedora 14 was the overly agressive nouveau driver, which didn't like my Nvidia graphics card and resulted in a black screen once it grabbed the card. Even putting rdblacklist=nouveau on the kernel boot line didn't help. I was finally able to get things installed in text mode, but for normal operation I always had to rebuild initramfs without this driver by messing around with dracut. Definitely not user friendly. This finally seems to have gotten fixed (rdblacklist getting obeyed?) with the last kernel update since I didn't have to mess with dracut. I also had a lot of initial stability issues with Fedora 14 and after much time digging with Google and much experimentation (much of which didn't help or made things worse) I finally got things working with the nohz=off highres=off boot options. Definitely not user friendly ... When I get around to moving my MythTV frontend and backend to separate machines, I'm actually thinking of switching the backend to FreeBSD so that I can take advantage of the native ZFS support. So how do I achieve your level of Linux computing nirvana?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201250714.q0P7EXth060018>