51–60 of 82 posts
Keeping software up-to-date on FreeBSD sucks. That's my one and only complaint. If that got comparably easier, I'd be switching from Ubuntu/Debian on servers back to FreeBSD. I still run FreeBSD 8.4 on one production system, and recently decommissioned a FreeBSD 5 box that had been happily humming away in a colo for 10 years. I learned FreeBSD before Linux and prefer almost everything else about it...except that part…
Keeping software up-to-date on FreeBSD sucks. That's my one and only complaint. If that got comparably easier, I'd be switching from Ubuntu/Debian on servers back to FreeBSD. I still run FreeBSD 8.4 on one production system, and recently decommissioned a FreeBSD 5 box that had been happily humming away in a colo for 10 years. I learned FreeBSD before Linux and prefer almost everything else about it...except that part…
It's a lot easier these days with the new pkg tools.
Some reasons I could think: - It's easier and cheaper to find Linux sysadmins than BSD ones - There's more commercial software supported on Linux - There's more companies offering support for Linux - Linux is more portable than BSD - Linux is one of the standard server OS offered by providers, BSD isn't
How is Linux more portable than BSD?! NetBSD has been ported to nearly every platform known to man, even toasters. I'm surprised that more embedded devices don't run some sort of BSD because they wouldn't have to release code. The PS4's OS is FreeBSD, which they did release a lot of code in return, but they don't have to open source or release all their code (i.e. DRM and other "Security" based stuff) if they don't w…
Linux runs on all these platforms and more - that toaster only had an ARM board sticked to it
Earlier quoted context omitted.
> Honestly, what changed was Ubuntu. Being able to have a fairly robust server on the cheap and maintain it fairly well with just a few apt-get commands was a huge game changer. That hurts to read. Debian (upon which Ubuntu is based) has been around for decades (literally: it's 22 years old), and has been providing an extremely stable server, for free, with just a few apt-get commands. > What used to be hours each we…
> Or you could switch to Debian and get the same ease-of-use with better security. Honest question: In what ways is the security story on debian better than the security on ubuntu?
All that said, I've used Ubuntu on and off since it launched, and they've been a great benefit to both Debian and Linux in general. There were some issues in the start, with not handling cooperating and resource sharing very well, there were a few sore people as a result of that -- but as far as I can tell most of those growing pains are well behind us now.
I personally sneer a bit reflexively when people mention Ubuntu on the server, but frankly that's an issue with me, and not with Ubuntu. I got burned by Ubuntu doing stuff like changing gid/uid numbers for system groups/users and little incompatibilities that made it hard to maintain services across Debian old-stable, stable and a couple of Ubuntu LTS releases at the same time for a while (the typical incompatibilities which generally have plagued Linux for as long as there have been more than one distro).
My impression is that since Ubuntu 12.04 pretty much all the major kinks got worked out, including avoiding issues with LTS -> LTS release upgrades - and Ubuntu is now as solid an OS as pretty much anything else.
As for the security bit, I think Ubuntu still comes with more out of the box, both on the server and on the desktop than Debian does. Like eg. the ssh daemon, maybe some bonjour networking stuff. Ever since OpenBSD forced everyone to re-examine what "runs by default" I prefer a cleanly installed OS to not listen to neither UDP or TCP at all out of the box. In that sense, Debian might possibly be considered "more secure" -- but I don't have the impression that there's a big difference in patch rates etc between the two.
Ubuntu/Canonical has gone to great lengths to make Ubuntu for Desktop and Server work out-of-the-box for the great majority of users -- and I honestly think they've done a great job with it. I still prefer Debian, but I also accept that it's a matter of preference not some strict criteria of superiority or the like.
Oh, and I have a special place in my heart for Debian/kFreeBSD even if I've yet to actually get to play with it: https://wiki.debian.org/Debian_GNU/kFreeBSD
Phew. Apologies for the long post - hopefully it has a few interesting nuggets.
Some reasons I could think: - It's easier and cheaper to find Linux sysadmins than BSD ones - There's more commercial software supported on Linux - There's more companies offering support for Linux - Linux is more portable than BSD - Linux is one of the standard server OS offered by providers, BSD isn't
I'm confused by what you mean by "more portable." Do you mean that it runs on more CPU architectures and platforms? Or do you mean more driver support, etc.? BSD can run a rather diverse set of platforms: http://www.netbsd.org/ports/
In the early 2000's, I had to set up a dedicated CVS server for my 10-person startup. I was the dual hat "dev & admin" guy. We were small, but had good desktop machines with good SCSI disks in them (top of the line Seagate, if I remember right).
I set up both a Linux and a FreeBSD dedicated CVS server. We were all happy to try one server for a day, copy the repo to the other one for a day, and try things out.
Well, FreeBSD was a bitch to set up compared to Linux and was easily 10X slower in every way measurable. Like, "cvs up" would take 5 seconds from the Linux server compared to a minute on FreeBSD (yes, same repo...). Hopping on to the FreeBSD box locally showed that every kind of disk activity was way slower than Linux.
I went to the FreeBSD newsgroups and got laughed at. Not a single piece of helpful info. I did get several large words thrown at me about how I didn't understand the benchmarks and the performance shouldn't be noticeable to the end users. At least one guy took to emailing me directly about how I shouldn't be comparing Linux to FreeBSD.
After 2 or 3 days of wrestling, I powered off the FreeBSD box, installed Linux on it, and never considered FreeBSD again.
After 18 years of running FreeBSD on my servers, my $0.02: Politics/marketing: * Most "unix" admins only know linux and will advocate for it vigorously because it is so much better than.. "what do you use again? Fedora? Ah, FreeBSD, something with F, I knew it!" * Management not always listens to reason but just wants a discussion go away, so they listen to the loudest advocates. Knowledge/Community: * It is easier t…
> most hosting companies won't even list FreeBSD as an option (though in most you'll find some unix geek who'll happily connect KVM or IPMI and insert the install-CD for you). Some of my datacenter clients use freeBSD for various bits, and I have been that guy. In the end they're migrating away because it's incredibly hard to find experienced engineers. What you describe as "reading docs is hard" can be equated to "m…
> What you describe as "reading docs is hard" can be equated to "my team will be slower for negleglible gain."
Yes, but only from a very short-sighted point of view. I cannot count the "devops"-meetings I had to attend as a consultant during which I hacked a command line that solved the problem the meeting was supposed to make a plan for and estimate costs... I dare to argue that letting the ops learn the ropes on company time would have been much cheaper than my fees plus costs for working time employees spent on that meeting. But I understand this is very hard to quantify and that in a startup culture people don't want to think beyond the point where the financing is used up.
My fav. test for sysop/devop candidates: "Tell me how large the home directory of all users who use [t]csh as a login shell is on that machine; no, you cannot install anything, there is no perl, ruby or python. You have 90 seconds.". 99% fail. I've even interviewed people who applied for a sysop/devop positions who could not set up a host if not through puppet because they know sh1t about the target OS.
PS: Thanks for being "that guy" who allowed me to use a mature OS. People like you allowed me to have a 336 day uptime as the lower limit. Most of my machines have more than a thousand days of uptime :)
Earlier quoted context omitted.
I actually ran FreeBSD as a "desktop OS" on more than a few IBM Stinkpads for years. It worked well, driver support -- well, wifi was always fun, but if you knew enough, you could get them going (orinoco cards for the win). That said, I never saw FreeBSD as anything other than a Server OS. So I wouldn't say the "desktop" comparison really ever fit in.
>if you knew enough, you could get them going (orinoco cards for the win) I think that right there was the problem.
Earlier quoted context omitted.
Many of the "points" mentioned therein are misleading, at best, if not outright wrong. There was a nice discussion / rebuttal of this article somewhere , although I can't remember where at this moment. Unfortunately, I'm just about to leave but I'll see if I can find it later.
Which points are misleading or wrong?
After 18 years of running FreeBSD on my servers, my $0.02: Politics/marketing: * Most "unix" admins only know linux and will advocate for it vigorously because it is so much better than.. "what do you use again? Fedora? Ah, FreeBSD, something with F, I knew it!" * Management not always listens to reason but just wants a discussion go away, so they listen to the loudest advocates. Knowledge/Community: * It is easier t…
> It is easier to copy a solution to a linux problem from stack overflow than to read the FreeBSD handbook, understand the problem and fix it. I'm (a little) ashamed to admit tech support via trolling. Linux sucks because you can't even [whatever]. It is nice to get a quick response of "it's just [whatever], noob". Although, that was a last resort. I've met a couple of people that reread man pages every year, i've ne…
Indeed, it is. But one won't learn anything of value. One just learns the solution to a very specific problem. If one chooses to learn the basics, more often than not one will decide that it is quicker to dive into the problem and fix it than to "troll" tech support.