As a long term FreeBSD user (since 2.0) and advocate, my view is that FreeBSD should focus on its niche as a rock-solid server operating system. For most developers buying a MacBook and SSH-ing into a server is probably the right answer (or running a VM if you really need something local). The level of effort to match the MacBook user experience feels like a lost cause (Linux has been trying to do this for decades with significantly more resources) and it would feel more useful to use this funding to focus on the server side.
The ability to daily drive an operating system on the machine sitting on your desk helps get contributions that also help it be a better server operating system.
I'm so much on the cliff on this, whilst they should focus it's becoming more painful by the year to run stuff on FreeBSD since there is so may Linux:isms in most opensource projects today that it's almost as hard to compile on FreeBSD as it was to compile on Windows 20 years ago.
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)
Kind of, on embedded space, other kernels and FOSS operating systems are shaping up, none of them using GPL derived licenses.
As another long term FreeBSD user(4.6), you can pry FreeBSD from my lap/desktops from my cold, dead, fingers.
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.
On my bubble it is more like buying Windows laptops.
For the last 5 years, I have replaced FreeBSD on servers with Linux. The main reason is that Linux, is a lot less work. The time spent on upgrading for example Debian is significantly less than FreeBSD which has a cumbersome process which requires some manual human interaction a few times during the process. Another thing is that behaviour of some applications I write are different on FreeBSD compared to Linux. One pain point I recently struggled with was RocksDB with Rust, data got corrupted.. But the same code works great with Linux.
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.
FreeBSD upgrade and packaging will change a lot in 15.0.
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
But the FreeBSD 15.x will use PKGBASE concept [1] and [2] and parts of the system will be 'just' pkg(8) packages and also maintained by pkg(8) - so FreeBSD
Base System upgrades will be just pkg(8) commands - just like now with non system packages.
[1] https://wiki.freebsd.org/PkgBase
[2] https://vermaden.wordpress.com/2023/12/09/personal-freebsd-p...
Switching (back) from om Mac to Linux, I can definitely say that the painful experience was with the Mac, I just got used to it along the years.
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.
Did you create an issue about this data corruption?
Agreed. I used to run FreeBSD as a desktop OS way back when (early 2000s), but there's really no reason other than cachet to use it instead of Linux. It is a nicely coherent system with good documentation, but it also has its share of bonkers idiosyncrasies (e.g. root and other users having a different shell by default, and both of these defaults being awful).
For what it's worth, the default root shell is now /bin/sh instead of csh. I think that's true as of 14.0. /bin/sh is also a better interactive shell than it used to be, though yeah, I don't use it to do anything other than install my preferred shell.
Right, but isn't the default non-root shell still tcsh? Zsh and ksh are both under BSD(-compatible) licenses, and it would be a huge usability upgrade if they could just set one of those as the default shell for everyone.
So true!
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.
>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 ;)
Yeah, that’s just, like, your opinion, man. For me, FreeBSD is rock-solid server and workstation OS. Documentation is very good, the Handbook is great, and most of the time the manual pages is all that you need. The ports collection is large and it’s not very hard to package your own software as a port. The OS is predictable and this is something I value highly.
You might want to read the comment you're replying to again.
Oh, didn't I get the sarcasm of the comment I replied to... Thank you for making me reread it, really.
I think that a major problem is that you can't legally force vendors to open source the drivers they distribute. Most importantly wifi drivers which are critical to making an operating system that people can actually use.
> you can't legally force vendors to open source the drivers they distribute
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.
Isn't Android plagued by all manner of proprietary dependencies for hardware support?
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?
> . If they don't do that, they're more likely to be broken by Linux changes, and it makes distributing their drivers more annoying
So the idea is that having no drivers is better than having proprietary drivers? Seems like a perfectly reasonable and sensible approach..
having no drivers and having drivers that no longer work because the source isn't available and the maintainers can't update them is functionality identical.
Maybe they should stop breaking them then?
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 only decision to be made there is when to break them, not if. Linux went with "sooner than later".
if you prefer to have security vulnerabilities, you can always pin your kernel version?
the kernel needs to keep evolving, and the maintainers will keep your code updated for free - you just have to open source it.
Laws come and go.
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.
Yes, this is very plausible considering laws are in the making that forbid bricking of a device by stopping software support or remotely disabling it etc. Seems the only way to fix that is providing enough info to maintain yourself.
> organizations prioritizing endpoint security increasingly look to FreeBSD for its secure and stable environment
What is the story there? I've heard nothing about it. It would be an incredible development.
Many organisations build FreeBSD firewalls. I don’t know how it’s now, but for example the Swedish armed forces were using a software called Färist which was based on FreeBSD. I helped set it up during an exercise when I was a wee conscript.
I could be alone in this, but I think getting containers (OCI, Docker) running on FreeBSD seems like a better direction - I totally get that Docker is a Linux kernel thing but the idea of a file system with layers, registries etc could be a thing right?
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.
FreeBSD has supported containers since the 90s.
It would, however, be immensely useful to complete the work to run containerd with OCI images on top of jails, to the point that it's just a `pkg install`.
Laptops are the new desktops for many organisations, so this is actually quite relevant.
Apart from some console/game dev, I haven't had my main computer be anything other than a laptop for almost 25 years at this point.
For me the transition took place in 2002 privately, and since 2006 at work.
Can / does asterisk-BSD share many hardware drivers with Linux? IMHO that's the only way asterisk-BSD is to have any hope of catching up in the laptop space.
FreeBSD already uses GPU drivers from Linux and also starts to use Linux WiFi drivers.
Personally, I think this is a good call. People have a tendency to go with what they know and feel competent in. As people move more and more toward using laptops as their primary or only workstation device, the chances that admins or enthusiasts will choose FreeBSD as their go-to server diminishes if FreeBSD isn't what they're doing their primary computing through. Constant context switching is also made more difficult when you're using a very similar, yet oh so slightly different system, where many familiar commands are present, do basically the same thing, but take different arguments, have the same arguments do different things, or behave in very subtly different ways from your main computing device. Of course, I'm assuming the admin or enthusiast is using Linux on their main machine.
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.
Microsoft triumphed back than because it try to conquer students, desktops, old big-iron Unix players fall because they ignore it, so the move is logic but the main issue for FreeBSD are not much laptop/wifi but mere modern iron generic support and power management just for the hw, for the software the issue is that maintaining a FreeBSD desktop means more work to keep the system up to date than Arch.
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.
$750000 seems very little amount for this task. I think they should somehow attract companies to invest in FreeBSD development.
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.
FreeBSD has jails if you need lightweight vms. The kubernetes monoculture is a horrible thing for long term.
Jails are akin to containers, not kubernetes. The value of k8s over just docker or whatever container runtime is in the lifecycle management, service mesh, scaling, monitoring, etc.
Even without Kubernetes this kinda was indicative of the FreeBSD community missing the point, jails are neat but docker added a lot of ease of use above the how you basically managed jails manually (at least according to official instructions), people just kept mentioning that the capability had been there but missed that the ease of use was what charmed developers.
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).