Myths about FreeBSD
wiki.freebsd.org
wiki.freebsd.org
> FreeBSD supports a wide range of network cards (including an increasing number of 802.11n chipsets)
Is this out of date or should I not even try installing on a laptop with an ac chipset?
For example see the CAVEATS section here: https://man.openbsd.org/iwm.4
Yes since three years without any outcome....that's why the critique toward the foundation and NOT the project.
https://i0.wp.com/itsfoss.com/wp-content/uploads/2020/08/fre...
[0] https://cgit.freebsd.org/src/log/sys/contrib/dev/iwlwifi [1] https://cgit.freebsd.org/src/log/sys/compat/linuxkpi
FreeBSD is my go-to distro for any server,desktop OS. The kernel is strong, network is great and jails are decent and with bHyve happily taking everything I throw at it, I can't fault it. To me, it feels solid unlike Linux which has always had a flakey-cobbled like feeling. If I had to choose for distro it would be Slackware.
With FreeBSD 13, you can now assign dedicated network interfaces to jails, grant bHyve to create virtual machines within the jail leading to isolated VM-Jails. Which is an amazing secure & cool concept as if your Virtual Machine becomes vulnable. Your worse case is a breaking out in to the jail rather then the host OS.
This world which is becoming more limited, I'll happly stand by FreeBSD to help it continue to exist in the monolithic reality we all currently live in.
This nostalgia is justified - see:
And, RE the point about "that's fixed in -current", I'm reminded if a talk from Netflix engineering about how they just run -current in production.
Do we know why ? It seems a lot of them left post Steve Jobs era.
this is a half-answer at best and not really relevant. the point of virtualization is that the OS doesnt really care or know its being virtualized in the first place. supporting the virtualization of BSD is a moot point as it really doesnt concern the OS. bhyve (for all its worth currently) isnt mentioned, but it would be nice to see peoples experiences with it to date. props for not flogging jails as a solution however, as quite a few BSD purists will cheerlead this as virtualization.
>The BSD License Means Companies Don't Contribute Back
the real issue here is with license purists and the philosophy of open source. BSD gifts companies with an easier path to turning your work into a cloistered and proprietary part of their code, whereas GPL at least makes an effort to keep them honest about their appropriations. plenty of companies to date still do skirt the GPL though. ultimately whether or not a company gives back to an OS community is a matter of business prerogative and not entirely license.
> the real issue here is with license purists and the philosophy of open source. BSD gifts companies with an easier path to turning your work into a cloistered and proprietary part of their code, whereas GPL at least makes an effort to keep them honest about their appropriations. plenty of companies to date still do skirt the GPL though. ultimately whether or not a company gives back to an OS community is a matter of business prerogative and not entirely license.
But there's a difference between "giving back to the community" and "releasing your changes under the GPL". The only actual requirement is that the modified source code be 1) made available to the people to whom you give binaries, and 2) it be licensed GPL. There is no requirement even to send the code to the upstream project; and there's certainly no requirement to engage with the maintainer / review process to get the new code into suitable shape that the upstream project actually wants to take it.
Without engaging with the maintainers of the upstream project, there is virtually no chance that anything other than trivial patches will be in an upstreamable state in the vendor's patchqueue; and so virtually no chance that someone receiving the GPL'd patches could actually apply them upstream without doing a significant amount of work to make them so. I know of very few cases where people have the appetite to that sort of work.
So the result is that, in practice, companies contribute back to GPL-licensed projects for the same reason they contribute back to BSD-licensed projects: because they want to be able to pull in new code from the upstream, and having to rebase a patchqueue every time they want new upstream features is more expensive than engaging with the maintainers to contribute their own code back.
The main difference is in the small cases where there is enough community interest to actually take a company's internal patches and do the work of cleaning them up to get them upstream.
Exactly. It's also why the argument that open source has an advantage because many eyes can look at the code is also a mostly empty promise, and why things like Heartbeat happened despite everyone knowing the criticality of code like OpenSSL being absolutely solid. If you don't have enough of the right people looking at the right code then you get things like Heartbeat.
I'm not pointing this out to argue that Open Source is worthless, but rather to encourage people to not get complacent - Open Source is not a panacea and should still be vetted as you would vet any other part of your solution.
>So the result is that, in practice, companies contribute back to GPL-licensed projects for the same reason they contribute back to BSD-licensed projects: because they want to be able to pull in new code from the upstream, and having to rebase a patchqueue every time they want new upstream features is more expensive than engaging with the maintainers to contribute their own code back.
You mean people act in favor of their own enlightened self interests? Who could have guess that? Ham fisted attempts to force people to do the right "moral" thing rarely succeed. But we have people who insist "if we just had a better policy!".
Sigh. Think of how much more productive we could collectively be if we stopped worrying about how to control other people, but instead structure our approaches to influence their inherent behaviors to get the better outcome naturally? And if they still go their own way shrug and go on? The GPL has evolved into a beast that would make the most aggressive HOA blush - yet the same people who would rightly go after a busybody HOA have no problem cheering misguided efforts like GPL 3 on? It's pretty amazing.
Things have just worked and I've really not had any issues with it in the years it's run. The VMs are stored on a mirrored zfs zpool with sparse volumes so they only take up space they actually need.
All that said, I find the bhyve config language and command line options to be pretty painful, so I've been only using it with this frontend: https://github.com/churchers/vm-bhyve
Actually, BSD might incentivize "proprietary" companies more than GPL to contribute back to upstream.
Even ignoring the gratitude factor for BSD license granting more freedom than GPL, it's just strategic. Companies want to apply their own local patches to the kernel whilst keeping update to upstream changes, it becomes a burden, specially if the infrastructure where the patch touches changes, to ease the burden of maintaining the patches they contribute them to upstream.
I don't think you read the article very well. It mentions bhyve and also promotes jails - which I think are a perfectly acceptable solution to many (but not all) of the reasons why someone might want to do virtualization - I've moved on to OpenBSD for my hosting and have also been experimenting with NetBSD, but in both of them I'm really missing something equivalent to FreeBSD's jails and I wish the idea had caught on in the broader BSD ecosystem.
Otherwise it would be emulation not virtualization. Parallels on Apple Silicon only works with arm64 VMs.
But that's pretty much everything I care about. I have Windows 11, FreeBSD, OpenBSD, several Linux distributions. They all work fine.
Linux had had this part sorted for about 10 years which is one of the main reasons why FreeBSD will continue to be forgotten as a desktop OS.
FreeBSD tends to be the best still, but the lack of 802.11ac support and the occasional odd problem with “supported hardware” makes it hard for me to go with, when I can just use Linux and everything works.
NetBSD is amazing, especially as a retrocomputing enthusiast (there’s an active VAX port, not even OpenVMS has a VAX port anymore), but dear god the hardware problems I’ve had with it. Last time I tried to use NetBSD, it was on a lower end laptop I wanted to try to squeeze as much usability out of and for some reason, the installer refused to work with the eMMC attached. In that last I’ve also had all sorts of issues with supported network hardware causing kernel panics.
DragonflyBSD seem cool too, and probably has the nicest kernel maintainer I’ve ever seen. Sadly I’m not sure if it’s whole schtick still applies today, and the lack of any video drivers except Intel made it unusable for me. Yes there’s generic framebuffer drivers, but dear good they are barely usable.
Don’t have too much experience with OpenBSD, but I wouldn’t use it as a desktop either way. The lack of LKMs is a turn off for myself, who’s always swapping in and out random weird hardware.
If I had the time, energy and patience to learn these kernel, and figure out how to inject myself into projects that are probably long ongoing and with people much more experienced than myself, I’d love to help, but sadly I do not have those things.
I found this, but it doesn't tell me much: https://wiki.freebsd.org/Graphics/Wayland
I'm not as familiar with how it works in FreeBSD, but the OpenBSD Chromium maintainer asked Google to upstream their patches and the Chromium team refused. So OpenBSD has 2.6MB of patches to maintain to keep Chromium going. I just checked and it looks like FreeBSD has 4.1MB of patches in their Chromium port.
See: https://groups.google.com/a/chromium.org/g/chromium-dev/c/b5...
Gnome decided a while back that systemd dependencies were ok, so the BSDs (and Gentoo) have large patch sets to maintain to keep basic functionality going.
Those are just a couple of examples of large important projects that don't want to dedicate much if any effort to portability to BSDs or other non-Linux OSs.
Seems like that puts more and more pressure on a small number of volunteers to keep up porting efforts of some mainstream programs, otherwise *BSD becomes even more niche and limited.