Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical reasons to choose FreeBSD over GNU/Linux (2020)

unixsheikh.com

Post reply on HN
Print view View original

271–280 of 376 posts

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#271

Post by astrobe_ »

nmz wrote: post #136
stingraycharles wrote: post #90

Earlier quoted context omitted.

From a technological perspective, everything you say is true, and FreeBSD is better in so many regards. But, compatibility and community support is just a deal breaker. The jails vs docker argument is a good example: while technically better, Docker (or rather, cgroups and image distribution) have been standardised and have tremendous community adoption. FreeBSD cannot tap into any of this at all. Yes, jails might be…

Nobody ever adopts it because nobody wants to support it, ergo nobody ever adopts it and nothing ever improves. Gotta love this little cycle of mediocrity the software world has going on.

This type of circular argument sometimes hit a nerve when it about a thing cares about, but lets remember that the literal sense of "mediocre" is "middle" or "average", so its kind of a tautology to say that in general, software is average.

It takes true nerds (or "geek" in the sense it had around 2000, when it was still a bit derogatory and not yet a fashionable identity marker) to go off the beaten path.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#272

Post by raverbashing »

frostwarrior wrote: post #246
matheusmoreira wrote: post #230

Earlier quoted context omitted.

> backward compatibility, this is where linux is really horrible, there was an article about compiling binary on freebsd 2 and running it on freebsd 10. Try this on linux, binaries are not compatible even on minor versions. Linux userspace is considered unstable. It's not a cohesive system like the BSDs but lots of independent projects all doing their own thing. The Linux kernel is capable of running binaries compile…

I even say that instability of the Linux desktop was a considerable contributor to the decline of Linux powered workstations. People were getting used to the old reliable Gnome2 and the Windows-esque KDE desktop. But there's always some team of developers thinking they are Apple and completely throw years of progress out the window by breaking compatibility because of some usability "feature" their own selfish concep…

I wouldn't say "instability" as much as lack of focus

Especially as with some evolution it seems it's always a mix of people complaining new change means some X program made in the 70s will break and people who wants to redo something made in the last 6mo because it is "old" already and meet the newfangled thing which is 50% breaking changes 50% barely new things

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#273

Post by inopinatus »

old-gregg wrote: post #170
stiray wrote: post #62

I am using freebsd since version 8 for all my server needs (was using linux, but got repelled by its chaos which I dont care about on my laptop, but it pisses me off on server). Some more points: - bhyve, developed by netapp, they ditched all old technologies support and it works faster on my i5 server than kvm on my i7 laptop. Snapshoting using ZFS is not a feature to discard either. - FIBs, absolute miracle routing…

Remember, you're comparing Linux and FreeBSD in 2022 but BSD lost to Linux much earlier, many years ago. Back when I was looking into them (long time ago, excuse me for not remembering the details), BSD felt more pleasant and coherent. But at the same time it had limitations on scalability, performance and compatibility with hardware and also with userland software. In every benchmark, especially on multi-core, multi…

Not sure what you could mean by “lost”, when BSD family operating systems are so widely adopted. I have more devices at home running such than I do Linux, not even counting Apple’s Mach hybrid. My internet traffic passes through more BSD-based than Linux-based devices as it crosses the globe, and my data resides on a variety of platforms that include both (and more besides).

These systems aren’t busy trumpeting their presence. Maybe the originators just don’t have fragile egos.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#274

Post by nix23 »

toyg wrote: post #223
cesarb wrote: post #182

Earlier quoted context omitted.

> The more common explanation was that Linux got a head start by a few years by being a clean-sheet implementation My favorite theory for why Linux got a head start is in this (long) comment I found some time ago here: https://news.ycombinator.com/item?id=21420338 Some excerpts: "With Linux, I just booted from a Linux boot floppy with my Linux install CD in the CD-ROM drive, and ran the installation. With BSD...it co…

IDE was one of many hardware issues that just took too long to be solved. For a long time, BSDs didn't seriously try to support consumer-grade hardware - be it because of lack of manpower, conservative attitudes, or "commercial" choices. OpenBSD still doesn't support Bluetooth... On the other side, the Linux community fought hard to get everything to work, creating positive loops: the more hardware it supported, the…

>OpenBSD still doesn't support Bluetooth

OpenBSD supported Bluetooth but they threw out the whole stack because of security concerns. I think it's the right decision for OpenBSD.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#275

Post by Gordonjcp »

SoftTalker wrote: post #123
intothemild wrote: post #84

Earlier quoted context omitted.

I love FreeBSD and i love Jails, but you're right. Docker won because of simplicity. Dockerfiles make it super simple. There is similar stuff for jails but you need a jails frontend that use it. A few years ago i wanted to build the Jailfile equivalent, call it Warden, and have Warden manage the jails. But honestly i doubt it would get traction outside a small community.

"Simple" is subjective. Have you ever looked at what Docker puts in your iptables? I challenge you to understand what's happening with your networking after that. If you want containers, lxc command line and a bit of configuration for a bridge interface is all you really need.

> Have you ever looked at what Docker puts in your iptables?

Some forwarding rules.

> I challenge you to understand what's happening with your networking after that.

They're incredibly simple forwarding rules, to make sure that only the containers that you specify can connect to the Internet, and all the others in a particular group can only connect to each other.

> If you want containers, lxc command line and a bit of configuration for a bridge interface is all you really need.

Yes, assuming you never need to maintain it, or run more than one project per server.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#276

Post by Gordonjcp »

SoftTalker wrote: post #133
ajross wrote: post #128

Earlier quoted context omitted.

> If you want containers, [...] is all you really need. And that is the attitude embraced by jails (to be clear: rather more cleanly and attractively than the expression of the same ideas in linux), and precisely why it lost. No one wants "containers". They want docker . They want to be handed something that looks no more threatening than a mid-80's build script and have it magically be it's own little world with all…

The voodoo is what bothers me. As the person responsible for the server, when things go wrong I will get blamed. In that situation, I at least want it to be my fault.

What "voodoo"?

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#277

Post by jsiepkes »

greggyb wrote: post #212
jsiepkes wrote: post #162

Earlier quoted context omitted.

> If anything IS a problem here it is violating the terms of the GPL, not the CDDL. The CDDL terms are violated because you can't re-license code that is under the CDDL (in contrast to for example the BSD licenses). The GPLv2 is a strong copy-left license that puts the CDDL files under GPLv2. Even the creators of the CDDL themselves have stated that the CDDL is probably incompatible with the GPL [1]. [1] https://lwn.…

You cannot relicense BSD code. In general, you cannot change anything about the copyright or license for any work that you do not own the copyright to. Perhaps you mean the BSD licensed artifacts are "compatible" with copyleft licenses?

Relicense might not the best word but compatible also doesn't cover it in this context.

Saying you can "assimilate" BSD licensed code in to a GPL project might be more appropriate. Since rights such as "Redistribution and use in source and binary forms" which the BSD gives you no longer apply after the code is in a GPL project [1].

You can't do this with CDDL licensed source code.

[1] https://softwarefreedom.org/resources/2007/gpl-non-gpl-colla...

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#278

Post by nix23 »

heinrichhartman wrote: post #165
GekkePrutser wrote: post #126

Earlier quoted context omitted.

> Compared to those workflow improvements, nobody cares if the guts suck. Some people care, this is why FreeBSD is still around :) And it's not really relevant if you build your own images anyway. And in fact within the scope of FreeBSD jails offer very similar features, one of the things that's very common to do is make a base image with ZFS and then base all your jails off it. This means you just have to update you…

I would like to be on the jails train, but the build/deployment story always felt inferior. I have never seen anyone build jail-images from CI and deploying them to fleets of FreeBSD hosts. This may be technically feasible with zfs send/recieve but in practice people I know distributed packages (not images) to 10s of FreeBSD jails/hosts. I want to deploy container images to a cluster - not install a package in a zone…

I want to deploy container images to a cluster:

Here you go:

https://bastillebsd.org/

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#279

Post by stingraycharles »

tannhaeuser wrote: post #257
stingraycharles wrote: post #90

Earlier quoted context omitted.

From a technological perspective, everything you say is true, and FreeBSD is better in so many regards. But, compatibility and community support is just a deal breaker. The jails vs docker argument is a good example: while technically better, Docker (or rather, cgroups and image distribution) have been standardised and have tremendous community adoption. FreeBSD cannot tap into any of this at all. Yes, jails might be…

> Docker (or rather, cgroups and image distribution) have been standardised Cgroups, namespaces have been implemented once, in Linux, by Google for their own needs. Not standardized in any meaningful interpretation of that word, just like "web standards" aren't. With now a generation of developers raised by big media and fake grassroots and staged march of progress stories, I'm wondering if that generation will be ab…

Yeah, you’re right of course; my point was more that somehow we ended up with a “standard” format to store and distribute images, have plethora of tools that are able to run it, but they’re all using the same kernel fundamentals (cgroups).

But all that would be a distraction from the point I was trying to make, so I simplified it a bit.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#280

Post by nix23 »

atmosx wrote: post #171
stjohnswarts wrote: post #68

Earlier quoted context omitted.

I use Linux all day long and none of this is an issue for me, so I guess that's the counterpoint. I'm just a desktop/server user/developer though and not a guru by any stretch.

Comparing Linux to FreeBSD is like comparing a Mercedes to a custom-made trackday car. Docker, kubernetes et all was the nail in the coffin. BSDs are amazing for universities, OS classes and some outliers in the industry here and there. The one thing FreeBSD had was network stack performance. Linux supports higher throughput for a while now.. so even that ship sailed.

> Linux supports higher throughput for a while now

Really that's new...because netflix thinks otherwise.

Post reply on HN