Hacker News Reader

Comment by colechristensen | Hacker News Reader

>This seems to sum up the biggest pain point that drives people away from OSS. Not knowledge, not skill, not price, but the total experience of a nice piece of software that lets you get the work you actually want to get done... done.

This is why I continue to be fascinated by FreeBSD, I don't use it for much but when I do, what I'm trying to do almost always works right out of the box.

My point is that is all comes down to packaging, which is done everywhere. Docker is so popular because debian-style/rpm-style/etc packaging systems and the maintainers of said packages do a pretty uneven job of making things work without luck or fiddling (or having to have package specific knowledge about how to do something obvious). Docker doesn't really do a great job either, but it has a different set of problems and having the old ones gone is nice.

View on HN

What are you using FreeBSD for? I imagine it's quite good at some things, but isn't that range kind of limited? You need to have the precise set of hardware that's well supported and then use it for precisely the thing it supports well.

In my experience of using FreeBSD for twenty or so years, for the most part, if it's a major vendor and a few years old then it's supported.

It is true that FreeBSD is slower to get new hardware support but I actually like that, it's one of the major reasons why things just work in FreeBSD. You put the work in upfront, select the right hardware and FreeBSD will serve you well for years with very little effort.

They aren't chasing some imaginary/political/technological dream they are delivering high quality software using tried and tested methods.

> What are you using FreeBSD for? I imagine it's quite good at some things, but isn't that range kind of limited? You need to have the precise set of hardware that's well supported and then use it for precisely the thing it supports well.

No you don't? You can throw it on a random commodity desktop and expect it to work. I imagine laptops are harder if you want suspend etc. - it feels pretty similar to how Linux was a few years ago. (If anything support for old hardware tends to be better than Linux because they don't keep changing the kernel interfaces, so a barely-maintained driver from 5 years ago is probably still usable). You don't need to use it in some particular way, it's fine for a daily-driver desktop or home server. I used mine for a little bit of everything until recently - ordinary KDE desktop, fairly normal web hosting environment running some stuff I wrote in Python with WSGI, database server, home VPN server... all the usual stuff.

I have come to the conclusion that the only reason why things like flatpak and snap exist is because the ergonomics for creating and maintaining .deb packages is so awful.

Pacman FTW

Not just that. Application sandboxing is important too. The traditional unix approach of any process run by your user can access all your files is at odds with modern security concerns.

Sandboxing is an issue, though I would argue that sandboxing and packaging are orthogonal concerns, so a new format should not have been needed just for the sandboxing use case. That said, if you are developing sandboxing from scratch pretty much no sane person would choose to use the .deb workflow as their UI for packaging.

I found out when experimenting with it that Snap inherited most of the .deb cruft. As someone less experienced in .deb packaging, I found it very confusing with all the Ubuntu-specific package separations and archaic requirements. If I don’t have a man page, for instance, I shouldn’t have to create one and learn format naggles to meet an aggressive linter’s specs.

Reply on news.ycombinator.com