Why laptop support, why now: FreeBSD's strategic move toward broader adoption(freebsdfoundation.org) |
Why laptop support, why now: FreeBSD's strategic move toward broader adoption(freebsdfoundation.org) |
I actually think the structure of BSD projects could be better suited to building laptop support than something more fragmentary like Linux. It doesn't have the same resources, but it can wield those resources in a more concerted manner to support specific models very well, in a way that the structure of the Linux project doesn't facilitate nearly so well.
Could be interesting if handled well.
Only a month or two back I gave up on compiling Samba myself (mostly worked w/o issues in the past just with ./configure && make), relying on package/ports instead.
Modern dotnet versions are finally available (but the compilation instructions looked headache inducing), node.js filesystem watching seems broken/nonexistant (using webpack -w i had to enable some polling mode).
I love FreeBSD but Linux has EEE'd the OSS ecosystem. (Embrace, Extend, Extinguish)
What improvements are you looking for on the server side?
Seems to me this money will do wonders for the client side, while on the server side, FreeBSD is already miles ahead of the competition.
I agree, we often overlook the fact that virtualization made enormous progress in the last decades on consumer hardware.
So if I want to run FreeBSD on my laptop I might have to boot Linux first (I know...). Simply because few OS can afford the luxury of broad hardware support nowadays.
FreeBSD is still a very competitive OS but it might start lagging is some aspects behind the most innovative Linux distributions such as NixOS.
My wish would be some work on configuration management and automation since it might be a low hanging fruit for such an integrated OS developed by a single entity.
I really like FreeBSD, but I do not have time for it anymore. I really think FreeBSD is important, and I appriciate all the great work. But it needs to help me save my time.
I think spending effort and money on getting it to run better on laptops will not help adaptation. We have macs, which are a lot better than anything else at the moment. Even Linux on a laptop is a painful experience.
I don't understand all of the pressures on vendors in the Linux case, but at least one of them is that they can't upstream their drivers (and thus unload some of their maintenance burden on the Linux kernel team) unless they license them in a way that's considered suitable by upstream. If they don't do that, they're more likely to be broken by Linux changes, and it makes distributing their drivers more annoying because they have to do that on their own. I also vaguely recall that there are some other ways that proprietary drivers have more limited access to the Linux kernel, of access more liable to get broken by upstream, but idrk.
But isn't the biggest incentive for releasing your drivers as F/OSS (so you can upstream, making maintenance easier) still there in the FreeBSD case?
So the idea is that having no drivers is better than having proprietary drivers? Seems like a perfectly reasonable and sensible approach..
What is the story there? I've heard nothing about it. It would be an incredible development.
Since they have no license issues they should focused on:
- zfs crypto root (native or geli, does not matter) by default, supported in the installer;
- boot environments support with zfs clones, as normal way to update the system;
- zfs integrated jails for software development (like IllumOS zones) focused on exposing a controlled set of package in a local cloned FHS to offer the equivalent of NixOS/Guix shell;
- easy creation of custom images, as easy as NixOS;
- curated minimalistic desktop offer (Emacs/EXWM, i3 or another tiling WM, fluxbox with ALL relevant modern desktop stuff (like dunst already there for notifications, udiskie for manage removable storage, a nice network manager GUI of some kind, ...) and a good XFCE setup by default. There is no need for more, but there is a big need of sane defaults and meta-packages selections.
These would be the real "basic stuff we need to succeed" like the SUN OpenSolaris Indiana move back then, ditching from the old SXDE/SXCE model for a modern FLOSS familiar one, but with the best tools GNU/Linux do not have.
I love FreeBSD but cannot really use it in a production environment until I can deploy containers on it as that is pretty much the defacto for our workflow.
Maybe it is impossible.
Apart from laptop support, FreeBSD is missing important things on server side suck as lack of support for Kubernetes. This is hindering FreeBSD adoption, too.
Currently - up to 14.x - the freebsd-update(8) command is used for upgrades - and yes - it can require manual intervention - but one can also use it in unattended mode like that:
# env PAGER=cat freebsd-update fetch
# env PAGER=cat freebsd-update install
[1] https://wiki.freebsd.org/PkgBase
[2] https://vermaden.wordpress.com/2023/12/09/personal-freebsd-p...
The Plasma desktop is now a breeze (literally ;-)). Battery is surprisingly long lasting, too (7 year old Thinkpad X1, easily 7-8h of battery).
It just works.
My family have a secret holiday destination. It has unspoiled beaches, friendly locals, cheap beer, amazing restaurants. When people ask where we went for summer we lie. "Oh we went to Ibiza again". Some things are best kept for yourself, not to be popular. We don't want "those sorts" dragging the whole show down to the lowest common denominator.
So listen to the parent poster, and trust me, BSD is a piece of crap. It barely works. the documentation sucks. And it definitely is no use for servers, desktops, laptops or embedded systems.
Go where the crowds are! Linux has something for everyone, with over 8 million lines of code in the kernel! You never know, you might even meet a celebrity like Lennart Poettering hanging around your hotel.
Yeah or Ricard ask you to clean he's feet at the pool.
And absolutely with you, please Linux user don't try FreeBSD it's terrible, no device drivers, no docker and ZERO Linux compatibility, and as Linus himself said: ZFS is really not that special. Dear Fedoras and Arch-Fellas, just don't touch it ;)
Forcing hardware vendor to disclose all information necessary to build drivers is something that is perfectly plausible to enact for example in the frame of a right to repair/maintain the hardware customers buy.
Note that it doesn’t need to be forcing to open source the vendor own implementation of any driver.
You can't, no, but that is looking at the wrong end of the problem.
What you can do is say, "we are the government of $X and we buy $Y billion of $currency of equipment per year, every year, and we will only buy from vendors who make all their drivers and firmware FOSS."
Then vendors will fall over one another in their haste to get a slice of that pie.
This is how we got desktop power management: the US Gov't Energy Star initiative.
This is why A/UX happened and how Apple got into UNIX: the US Army required POSIX as a condition of purchase.
Result, indirectly: OS X.
Also hurting it was that the Docker story on FreeBSD is had attempts to make it "native", through the Linux emulation layer with ZFS native functionality to handle the VFS parts and while that could have been elegant it required cutting edge and afaik never got really production ready (There's apparently docker port now via VirtualBox).
I find using FreeBSD jails to be extremely straightforward.
That’s a design decision, Linux maintainers decided to not have a stable ABI because they’d rather have no drivers at all than proprietary ones.
the kernel needs to keep evolving, and the maintainers will keep your code updated for free - you just have to open source it.
It's also more or less a given that first-party code will be better-integrated into an OS than third-party code is. That was a prevailing element of the discourse surrounding the outage CrowdStrike induced on Windows weeks ago, for instance. That's not a proposition unique to open-source operating systems. Indeed, what is unique to open-source is that is possible for outside vendors (or individuals) to put their code through a process that eventually gets it that maximal level of integration.
So, uh... no?