Live data from Hacker News

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

unixsheikh.com

221–230 of 376 posts

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

#221

Earlier quoted context omitted.

This is exactly the kind of gatekeeping that holds FreeBSD back. Users asking about missing features being snarkily put down with things like "go use Linux then, we're doing just fine without feature X". This kind of toxic attitude is what pushed me away from FreeBSD in the end. They're so childish about constructive criticism sometimes, it's downright embarassing considering these are supposedly adults. Edit: It's c…

Quoted post unavailable.

You didn't really explain anything. You waved your hands a bunch. You didn't address the fact that FreeBSD already accomplished this, then stopped maintaining it, you conveniently ignored the fact that Illumos had it even later than FreeBSD, mostly from scratch. Your tone was overly dismissive. Now you start calling me names. Grow up. I'm sorry I misunderstood your point of view, but you did sound exactly like certain FreeBSD community gatekeepers, and you're responding to a post about FreeBSD project decisions, so is it really so strange or "idiotic"?

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

#222
post #185

Earlier quoted context omitted.

That's only with Wayland. If you don't use Wayland, the situation has been fine for a decade.

It’s the other way around. Wayland supports different scale factors on different monitors; X doesn’t.

Works on my machine, anecdotally; no Wayland, and an X window manager that hasn't been updated in a decade. Automatically resizes windows when I drag them to fit each monitor's DPI settings.

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

#223
post #182

Earlier quoted context omitted.

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…

> 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 more people could get it to work on their hobby hardware, the more they'd become familiar with it and push for adoption at work.

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

#224

Earlier quoted context omitted.

I think one of the biggest mistakes the FreeBSD team made(in terms of more widestream adoption) was abandoning the Linux syscall table layer. It's still there, but it's stuck on 2.6.x last time I looked. It's a lot to maintain, yes, but it would help secure a lot more users like me, who are highly technical, potential contributors, who like a lot of the features(jails, better ZFS integration, easy to set up dtrace su…

Is cuda support decent on BSD? Drivers for niche stuff seem like they would be an issue as well.

No idea, never needed it. At some point I decided I had no use for dedicated GPUs that justified dicking around with atrocious driver blobs. That might change in the future if I get more into ML though.

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

#225

Earlier quoted context omitted.

Is cuda support decent on BSD? Drivers for niche stuff seem like they would be an issue as well.

No idea, never needed it. At some point I decided I had no use for dedicated GPUs that justified dicking around with atrocious driver blobs. That might change in the future if I get more into ML though.

I get that, mostly I use them for dsp for software defined radios. The drivers for those are probably hard to compile as well. Depedencies on libusb often. Or dpdk for the nice ones.

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

#226

Earlier quoted context omitted.

This is exactly the kind of gatekeeping that holds FreeBSD back. Users asking about missing features being snarkily put down with things like "go use Linux then, we're doing just fine without feature X". This kind of toxic attitude is what pushed me away from FreeBSD in the end. They're so childish about constructive criticism sometimes, it's downright embarassing considering these are supposedly adults. Edit: It's c…

It isn't gatekeeping to point out that maintaining Linux syscall compatibility is impractical, especially citing the fact that Microsoft tried and gave up after sinking tons of resources into it; and FreeBSD has also already tried and gave up as you pointed out yourself.

Thanks for not calling me an idiot, at least.

I'm not sure how relevant Microsoft is here given how much more different from Linux NT should be compared to FreeBSD. It's also kind of a different calculus for Microsoft in terms of it being worth the effort for what they wanted to do with it. Microsoft already has its own thriving ecosystem, the Linux support is just a bonus to attract people from a niche market. For FreeBSD the situation is more or less the exact opposite. The SmartOS people did it too, and even ported over KVM. But Joyent was acquired by Samsung and I'm not sure what happened to SmartOS after that.

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

#227

Earlier quoted context omitted.

No idea, never needed it. At some point I decided I had no use for dedicated GPUs that justified dicking around with atrocious driver blobs. That might change in the future if I get more into ML though.

I get that, mostly I use them for dsp for software defined radios. The drivers for those are probably hard to compile as well. Depedencies on libusb often. Or dpdk for the nice ones.

I'm still holding out hope that Intel will put out a decent dGPU with a strong ML story within a few gens, with gloriously open source drivers.

Recent news coming out of Intel the last week or so haven't been encouraging though. But I will remain a dreamer.

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

#228

I use FreeBSD on servers instead of Linux for one reason: ZFS. It's really that much better than anything that is currently available on Linux. BTRFS is not even close. Yes I know it's available on Ubuntu but everything else about Ubuntu is just so messy.

I don’t have a lot of SRE/sysadmin/etc. experience, so this is probably just ignorance on my part, but I find it hard to imagine a scenario where the filesystem on my servers matters at all (as long as we’re not talking about something super ancient like FAT). What are some workflows that ZFS enables for you on servers that you couldn’t do with ext4 or stock FreeBSD FFS ?

Pretty much

* data compression - say midsized 1.6TB mysql db compressed into 400Gb => allows to run replica servers on cheaper hardware (smaller drives)

* hot data set caching - depending on case can be 5-100 times better performance

* single pool but different settings per FS - say block sizes 16k for DB and 256kb for file storage

* snapshots. Instant snapshots

  * coming back to db replication case, this helps to test db scheme migration on close to production env and prepare better planning/downtime window. Once tests done - rollback snapshot and enable replica back without full reclone.

And so on

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

#229

Earlier quoted context omitted.

Have you not ever used a Linux distro? I haven't had an issue with monitors since before Ubuntu 8. Seems ridiculous you're going to claim that Linux, which dominates the phone/handheld industry, would have issues in regards to using high resolution/high DPI monitors along with lower spec ones concurrently. I think of all OS's, my bet would probably be that this is a way bigger issue on Windows than on Linux or Mac.

What you’re saying is probably valid for a desktop (especially if it doesn’t use Nvidia), but laptops (especially Nvidia ones) are still far from perfect. Personal experience with Ubuntu on a recent Thinkpad: * When using Wayland, until VERY recently (latest nvidia drivers), the entire system would freeze when hooking up an external monitor. Okay, no problem I’ll use X. * Hygrid graphics just completely doesn’t work,…

> Personal experience with Ubuntu on a recent Thinkpad:

Well, that's your first problem. How does FreeBSD or OSX do on it? Maybe you should buy a Linux laptop to run Linux instead of slapping Linux on a Windows laptop and expecting it to work correctly.

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

#230
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…

> 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 compiled in the 90s. Breaking changes in the kernel-userspace binary interface makes Linus Torvalds scream at people on the mailing list.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Post reply on HN