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.

> 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.

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.

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.

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.

Pacman FTW