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

321–330 of 376 posts

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

#321

Post by pantalaimon »

Wowfunhappy wrote: post #318
pantalaimon wrote: post #300

Earlier quoted context omitted.

The sad part is that Gnome 2 had a whole ecosystem of third party software that integrated with it. Just a few of that got ported over to Mate (usually just s/GNOME/MATE/g) but it never gained the same traction.

Why did it need to be ported at all? Shouldn't it "just work"?

Mate had to change all “Gnome” strings to “Mate” so both could be packaged/installed in parallel and probably also for legal reasons.

This means all DBus interfaces need to use the new name, a nautilus plugin must now call caja functions instead and so on.

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

#322

Post by donkeybeer »

ooneeks wrote: post #172
sgt wrote: post #58

Earlier quoted context omitted.

A guy I know (relatively skilled) spent a whole week setting up Linux on his laptop the other day. So I don't think it's always as predictable as to say there's never a challenge involved in 2022.

Just install Ubuntu if you quite literally cannot grasp GNU/Linux. No, your "guy" is not "relatively skilled", that's an absurd claim when it took an entire week setting up Linux on a laptop. It has never, ever taken me more than an hour or two with mainstream distros, or more than 3 days max. for more complicated distros such as Gentoo or Arch - but the system would be minimally operational within a day, always. You…

Installation does not just mean finishing the setup from the livecd. We have to work at copying our apps, configs, etc and it can be a lot of "long tail" work to get things exactly as before.

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

#323

Post by allanjude »

eatbitseveryday wrote: post #295
nightfly wrote: post #178

Earlier quoted context omitted.

I've run into fun issues like FreeBSDs slab allocator not playing nicely with the ZFS/NFS workload on one specific server and having to drop down to having ZFS allocate memory in a different way that used about twices as much CPU to avoid random multi-second pauses on the whole system. Also had issues where kerberized NFS would get confused and something would crash so had to have random cron jobs to restart dying co…

I’ve noticed this myself but didn’t dig into the delays I’ve seen. Interesting to learn it appears for others. How did you have ZFS change how it allocates memory?

This was a bug in ZFS itself, and was resolved years ago: https://smartos.org/bugview/OS-6404

In FreeBSD 12.x and older, you could opt out of using UMA with: vfs.zfs.zio.use_uma=0, but that is not necessary

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

#324

Post by Wowfunhappy »

pantalaimon wrote: post #321
Wowfunhappy wrote: post #318

Earlier quoted context omitted.

Why did it need to be ported at all? Shouldn't it "just work"?

Mate had to change all “Gnome” strings to “Mate” so both could be packaged/installed in parallel and probably also for legal reasons. This means all DBus interfaces need to use the new name, a nautilus plugin must now call caja functions instead and so on.

...huh, well that's frustrating! Could this be solved with a basic compatibility layer?

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

#325

Post by batab »

I am understood the article. But my feelings are:

- it sounds like an perfect server os, but not am desktop os: i tried 3 times install gnome on freebsd inside kvm, i didn't make it.

- how about install on laptop? On arm laptop? How about power management?

i think linux is much better for workstation / desktop computers

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

#326

Post by josephcsible »

trasz wrote: post #207
josephcsible wrote: post #159

Earlier quoted context omitted.

Isn't the whole reason that the CDDL is a problem that it is viral too? Otherwise you could just distribute the whole bundle of ZFS+Linux as GPL and be fine.

It's not, CDDL explicitly states it doesn't apply to non-CDDL-ed source files. The problem is, GPL is claimed to be the other way around, so this would mean applying GPL to CDDL sources, and you can't do that, because CDDL gives you additional protections ("freedoms") GPL doesn't, and that's GPL-incompatible.

If I combined ZFS and the Linux kernel and licensed the result under the CDDL, I'd be violating the GPL. If I instead licensed the result under the GPL, then I'd be violating the CDDL. I'm not seeing how the licenses' differences actually cause an asymmetry here.

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

#327

Post by nmz »

astrobe_ wrote: post #271
nmz wrote: post #136

Earlier quoted context omitted.

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.

Guess I mispoke, if everyone adopted it, then that quality of software would become the new average. this software is just inferior, which in software usually means that its harmful.

Adj. 1. mediocre - moderate to inferior in quality; "they improved the quality from mediocre to above average"

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

#328

Post by bonzini »

jlawer wrote: post #238
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…

bhyve (a lightweight virtualization tech) vs kvm (really kvm/qemu) isn't really a like for like fight. If your looking for something lightweight on the linux side you would go with Firecracker (AWS developed for Lambda and Fargate).

Not necessarily; if a VM is properly configured userspace is out of the way as much as possible and performance is dictated almost entirely by the processor and the hypervisor, not by QEMU vs. Firecracker.

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

#329

Post by bonzini »

trws wrote: post #82
jeffbee wrote: post #70

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. What a completely bizarre claim. I have commercial linux/x86 binaries from the 90s that work perfectly well on my current PC running Linux 5.15.

I’m guessing the OP meant “where glibc is really horrible”, since bsd libc is rather more abi stable, largely because that’s where FreeBSD provides compatibility instead of the syscall layer. This is not to say you can’t use an old libc and fix up the loader paths or use a container and make it work, but it’s a different set of challenges.

> bsd libc is rather more abi stable

I am not sure about other BSDs, but at least OpenBSDs is all but abi-stable; when they wanted to introduce 64-bit time_t to fix Y2038, they just changed the typedef and declared a flag day.

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

#330

Post by atmosx »

nix23 wrote: post #280
atmosx wrote: post #171

Earlier quoted context omitted.

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.

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

That is true[^1]. Doesn't say much the two TCP stacks in 2022 though.

Netflix has built expertise around FreeBSD for years. Not just TCP stack optimisations. There's deployment, management, maintenance, etc. I don't expect them to jump ship easily, especially if the tool is good for the job - which obviously is.

However, even they reckon that FreeBSD _might_ be faster for _a specific_ workflow. Fifteen years ago there would be no comparison between the two in terms of top speed achieved on same hardware or latency, FreeBSD was far superior.

The trend is what's important here. Netflix choose FreeBSD in 2012, in 2022 it is certain that they would have gone with Linux and by 2032 my guess is that they'll be serving using Linux. I hope I'm wrong, the more the merrier.

[^1]: https://news.ycombinator.com/item?id=28584970

Post reply on HN