FreeBSD saves the day

UPDATE - 2015-08-11: Frankly, at this point, I feel I made a mistake trusting FreeBSD for the important customer project I describe below. Now I'm stuck with this mistake, unable to put a more reliable OS on the server as it's almost 800 miles away from me.

UPDATE - 2015-08-23: FreeBSD is a really good OS although I encountered a serious issue with the Samba4 package in production. I apologize for the excess of emotion in my update above, and admit that the problem lies more with upstream and with the incompatibilities that can come up with some packages and the BSDs.

- - -
Original Post:

I just wanted to post a quick message about FreeBSD saving a project I was working on.

A customer wanted a secure server, running as an Active Directory domain controller with encryption on top of RAID mirroring. After the hardware assembly and testing was complete, I installed Ubuntu Server and did the configuration for mirroring and encryption.

After everything was set up and working, I noticed that a motherboard update was available and installed it before shipping it to the customer. Now Ubuntu started to force my CPU to the lowest possible speed and keep it there (even when it was set to 'Performance' in BIOS) and an even bigger issue; the system wouldn't reboot properly (it would get stuck right before it was supposed to reboot). Frustrated, I went ahead and flashed the motherboard again, thinking that the flash was somehow corrupt the first time. The two problems persisted. After some discouraged mumbling and grumbling, I went ahead and reinstalled Ubuntu again, only to face the same problems.

For much of last year (2014), I was a very unhappy camper when I tried FreeBSD. After months of testing and researching, I have finally found that devel/glib20 and x11-toolkits/gtk20 have problems which cause certain apps to abort, crash and so on during certain situations. Armed with this new information, I felt confident enough to migrate our company Linux file server to FreeBSD and have been very pleased with the performance and reliability (since it doesn't use x11-toolkits/gtk20 for server duties).

Pleased with FreeBSD's performance and reliability on my company server, I decided to try FreeBSD on this customer's server project. The first FreeBSD 10.1 install went fine, however Samba 4 appears not to work well with ZFS and ACLs. I found and applied workarounds for the ACL issues, but just could not get Windows client computers to work properly with it. I nuked the install and tried with UFS, then added RAID mirroring and encryption and everything appears to be working wonderfully now. No reboot issues and FreeBSD respects the CPU speed settings I set in BIOS.

Recently, I've been very happy with FreeBSD on the desktop, except for the reliability issues x11-toolkits/gtk20 causes. I'm really pleased that I could use FreeBSD on a customer project and I'm really hoping that it turns out to be a good decision in the long run. :)

Thank you, FreeBSD foundation, developers, moderators and even DutchDaemon! ;)
 
Last edited:
I'm sorry, I don't understand the reference :oops:

You're using the same kind of phrasing here. "FreeBSD foundation, developers, moderators and even DutchDaemon!", singling out Mr. DutchDaemon from the rest. I'm sorry, I have spent too much time reading TV Tropes...
 
Last edited by a moderator:
You're using the same kind of phrasing here. "FreeBSD foundation, developers, moderators and even DutchDaemon!", singeling out Mr. DutchDaemon from the rest. I'm sorry, I have spent too much time reading TV Tropes...
Oh, okay :p Yeah, DutchDaemon was a bit of a nemesis when I first signed up on the forums, but he's been kind to me lately. ;)
 
Last edited by a moderator:
UPDATE - 2015-08-11: Frankly, at this point, I feel I made a mistake trusting FreeBSD for the important customer project I describe below. Now I'm stuck with this mistake, unable to put a more reliable OS on the server as it's almost 800 miles away from me. Lesson learned, eh? :(
Why do you feel like you made a mistake?
 
Why do you feel like you made a mistake?
Savagedlight I feel the mistake was trusting the quality of packages for FreeBSD to run a crucial server for an important customer.

The FreeBSD base is super-solid and reliable, however the quality of the packages (ports) is worrisome compared to the same packages on many Linux distros. Unless you're doing straight NFS or SSH, you need to add packages to the base.

It's pretty hard to use any operating system without some extra packages, so the FreeBSD server I set up for a customer is using samba4 and all of its dependencies. I have been having a plethora of issues with FreeBSD packages ever since the first time I tried FreeBSD almost ten years ago and even more so now. Despite good quality and tested hardware, I've had samba4 hiccup on me, as well as crashes, hangs and other issues that appear to originate from the mess that is devel/glib20.

Because FreeBSD's base is so solid and due to better security, I've been wanting to switch my business workstation completely over to FreeBSD for quite a while, but even after submitting problem reports, upstream developers aren't as concerned about making their packages work well on the BSDs.

So it's not so much a base FreeBSD issue, it's that the FreeBSD project appears to tolerate lower standards for FreeBSD ports than projects like Debian.
 
So it's not so much a base FreeBSD issue, it's that the FreeBSD project appears to tolerate lower standards for FreeBSD ports than projects like Debian.

Any quality standards there are for FreeBSD ports come from the individual port maintainers. It's a real stretch even to say that the FreeBSD project is doing any management in the area of FreeBSD ports other than in the /usr/ports/Mk infrastructure. That should be enough to tell you that there will be very few standards if it's left to people who in most cases are not coordinating (unwilling, incapable, no time or otherwise) their efforts with others. At least, that's how it has been for the last fifteen or so years. Things have been changing though lately with the new people in the portmgr@ team who have done some very significant improvements in this area by finally creating some proper QA procedures and tools for FreeBSD ports. It's a mammoth task though after years of neglect. The progress has been slow so far because the you can't just suddenly rewrite the whole ports infrastructure and push it to unsuspecting users to test, it has to done little by little.
 
kpa Thanks for that. It explains a lot.

I really didn't want my edit to be a huge rant against FreeBSD, mostly just frustration that I had 'bought in' to FreeBSD for a customer project and it has turned out less than favorable for the customer, and me.

And to the earlier remarks about me 'fumbling', I do mess up from time to time, but it would do little good to rage against FreeBSD because of my own mistakes. Any mistakes I might have made during configuration were identified and corrected before the server ever left my business. The server worked fine for a while until one day, out of the blue, samba4 decided to blow up and took my customer's productivity with it. Not fun for them, or me.

kpa, your remarks make me a bit sad as I really had hope of moving completely over to FreeBSD for my main workstation. If the package/ports situation is as you say, it looks like I'll be 'stuck' for a while with Linux until the situation improves.
 
The biggest problem with FreeBSD ports in my opinion is that there are way way too few people working on the ports as maintainers. There's also a huge pile of unmaintained ports (indentified by ports@freebsd.org maintainer) that are in danger of being deleted if the portmgr@ team decides to pull the plug on them. The state of the ports infrastructure is one part of the problem, the amount of work required to maintain something like www/firefox is just enormous and I don't understand myself how the guys (https://wiki.freebsd.org/Gecko) manage to do it.

Debian and other popular Linux distros manage their better quality in packages by sheer numbers of people working on them and of course there are much more people using them resulting in quicker and more sizable feedback when problems arise.
 
The biggest problem with FreeBSD ports in my opinion is that there are way way too few people working on the ports as maintainers.
That is unfortunate. I'm decent at C and C++, but certainly not of the 'rock star' developer status necessary to be a good maintainer, otherwise I'd be happy to help.
 
That is unfortunate. I'm decent at C and C++, but certainly not of the 'rock star' developer status necessary to be a good maintainer, otherwise I'd be happy to help.

That makes you qualified already :) Maintaining ports isn't that hard once you pick up the basics and your ports aren't the most popular ones.
 
I wonder if FreeNAS or even TrueNAS could have been potential ready-to-go solutions for your customer. Both are based on FreeBSD and are used by many businesses for rock solid samba / NFS filers and the like. Just thinking aloud here as I've used FreeNAS with quite good experiences and TrueNAS is designed more for an enterprise setting.
 
willbprog127 Like most complainers on this board, you talk about one thing while meaning another. First you say, just four weeks ago, "FreeBSD saves the day!" cause it's so reliable. Now you say it's an unreliable OS. But, today, you say your complaint is about some ports created by outside parties which FreeBSD maintainers have to "fix" in order to be usable! And in the same post you state how stable and secure FreeBSD is which contradicts your previous post.

Even then, your complaints do not reflect anything you said since January though you claim you've been using FreeBSD for 10 years and you couldn't get it working even back then.

So you're all over the place with your complaints and I'm questioning your abilities. I am probably the least knowledgeable person on this board, being a jack of all trades web developer, but I have none of the problems you seem to have issues with after 11 years of using FreeBSD exclusively for servers and desktops.

If you think FreeBSD is unreliable, I suggest you ask the Netflix people why they switched to FreeBSD for all their video traffic from Linux.
 
First of all I think it's not FreeBSD which is to blame here: in my opinion this was caused by allowing yourself to be ill prepared for your project. I don't "trust" that something is going to work, I make sure that it does before telling my customers that it will. I also make sure that I know what I'm talking about. I don't mean any offense by that last comment but I strongly get the impression that you let your like of FreeBSD get the better of you and your judgment.

In the end this is still dealing with open source projects which usually are in constant development. Meaning so much that bugs can (and sometimes will) find their way into those projects along the way. That is something which has nothing to do with any package maintainer at all, but with the way open source projects in general work. If you rely on open source for mission critical stuff then this is something you have to keep in mind. That's called risk management.

So about those packages which you claim might be not that good. You do realize that all a package does is download the original tarball, apply a patch to it and then use that? Meaning two things: in the end you can always resort to grabbing the original software package (link to current stable ZIP file of Samba 4.2.3) yourself and install that manually yourself. No need to rely on package maintainers, and rolling it into a native package also doesn't have to be that hard.

The second issue is that this also means that you can rely on Google (and other sources of information) to investigate up front if there are any issues with a certain software package. Like searching Google for issues with Samba and ZFS ACL's. Sure, you don't get any ready to use manuals which explain everything, but you do get a lot of information and opinions (and experiences!) from other people regarding the subject. Though you may need to dig through things.

That should be a good way to draw some conclusions of your own.

In my opinion you're now blaming something for your own shortcomings. Of course I can't really comment on your project because I don't know what it is about, but the combination of Samba and ZFS doesn't have to turn into a disaster. I've replaced several Windows 2003 servers with FreeBSD utilizing ZFS, Samba and Mono and quite frankly it simply works. Which in itself doesn't mean all that much because no project is the same, but you almost make it sound as if FreeBSD wouldn't be up for the challenge per definition. And I'd like to dispute that point.

(Edit)

One other small point of criticism:

So it's not so much a base FreeBSD issue, it's that the FreeBSD project appears to tolerate lower standards for FreeBSD ports than projects like Debian.
Are you aware of the Debian OpenSSL disaster? Now, I will admit that this was an incident, but still one which had a huge impact. And the main cause for the problems was the package maintainer who messed with the package. It's not as if nothing bad ever happens on Linux either.

Sorry for maybe bringing up the obvious here, but the only reason I still remember this is because I had to do a lot of overtime to fix a lot of stuff when this came out.

Thing is: I don't blame Debian for that, I blame the dimwit who made those changes.
 
ShelLuser Thanks for your post.

You are correct in a lot of ways, but in others, you're making incorrect assumptions.

I am very aware of the risks of open-source software. Linux has been my main workstation's operating system for quite a long time, and I have been bitten by many bugs through the years. I am aware of the Debian OpenSSL disaster, which really was pretty bad. I know open-source has its own set of problems, however some projects are consistently better at doing packages right. Again, I'm not trying to flame FreeBSD (I use it (when it works) on my main workstation), I'm just frustrated by the quality issues of FreeBSD's ports. Again I also admit that it's mostly upstream where the problem lies.

I'm not a Debian fan-boy, so I'm not saying Debian is better than FreeBSD (it's not). I'm simply saying that packages like samba4, gtk+2, glib2, pcmanfm, Firefox, etc. appear to work much better on Debian (and most other Linux distros) than on FreeBSD. In the case of samba4, it's NOT a configuration problem as it was running fine for a good period of time until one day it decided to melt down and take my customer's productivity with it. I am not using ZFS with samba because of the ACLs issue. Yes, I actually took time to test the system before I shipped it out the door! ;) I also do a lot of testing in VMs before I commit something to bare metal. So I wasn't carelessly slapping some OS onto a computer, installing the packages and kicking the box out the door.

At any rate, I think my biggest mistake was posting that update to my original post, which I will remedy shortly.
 
The problem with GNU centrism (and subsequently Linux) is just that, GNU centrism; which causes a lot problems with other open source platforms. Platform agnosticism isn't something the GNOME/GTK+ world takes into consideration. Blaming the lack of stability of GNU centric packages on FreeBSD is like blaming a pen for misspelling a word. The maintainers can only do so much.


Ken Moore is trying to solve this problem with Lumina; so I'd suggest helping him with development.
 
Back
Top