Status quo ~2 years ago before FreeBSD 13 was that many 802.11ac cards worked but the ac features did not yet (and/or you’d have to install wpa_supplicant through ports to enable certain compilation flags), so you’d get a fraction of possible speeds or have to jump through hoops. Not sure what the more recent developments here are.
Yeah....sadly WiFi driver development fell behind in *BSD about 8 or 10 years ago. It made firewalls like pfSense and SmallWall less useful if you wanted an all-in-one network solution. You had to start to moving WiFi to APs from various vendors. It's ok when you have a small foot print with few walls (apartment or townhouse or condo). But a larger home, backyard/outdoor space, or garage/network closet spaces might need extra APs or relocation of AP(s). I do otherwise love pfSense and SmallWall despite what my $DAYJOB is. 10GbE NIC is really great too in *BSDs.
Having Freebsd on my laptop since 2 years...the only point of critique is wireless, thank you freebsd-foundation for that...you probably don't care since you all use macOS.
That's an odd and misinformed attack on the foundation. They're actively sponsoring WiFi work, the first half of which recently landed in tree. You can see what they're involved in on on their website: https://freebsdfoundation.org/our-work/projects/
As I said in the previous post, the first half of it just landed within the last month. iwlwifi[0] and dozens of linuxkpi commits[1] over the past couple of months by bz@. My frame.work laptop works generally well with -CURRENT (and presumably with stable/13, since iwlwifi's been mfc'd) with some wifi stability issues that have been reported.
And as i wrote, wireless is criminally underdeveloped on freebsd, not just a problem for laptops but firewalls/access-points too. 802.11n came out 12! years ago...and no i don't even talk about ac here.
Last I knew, the wireless stack lacked 802.11ac support entirely. I think some drivers for 802.11ac hardware could operate in 802.11n mode, but I might be mistaken.
I’m a bit out of date on FreeBSD land but tbh probably both. It references FreeBSD 11 not being out yet so the article is several years old.
FreeBSD does tend to lag behind a bit when it comes to WiFi support though so it wouldn’t surprise me if 802.11ac support is patchy.
There's currently no 802.11ac support, but this is in-progress. There's usually an update about WiFi support in the FreeBSD Foundation quarterly reports, and some major changes were merged into CURRENT a few weeks ago.
FreeBSD has always been rock solid until I broke my XFCE4 install on a Ryzen 5650X, Radon 5700XT.
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.
I am using sway (similar to i3 but for wayland) and it is working flawless on an Lenovo X230 running FreeBSD 13. It seems biggest problem will be graphics driver for different hardware.
Awesome, maybe it's worth a look then. "amdgpu" seems supported, which I assume is very similar to the linux one, since it has the same name and is open source.
Other concerns I have are systemd dependencies and browser support.
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.
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.
The article notes that FreeBSD has over 26,000 pieces of software with a link, but that link just goes to a page that says "The latest Python updated failed. I intend to repair this post-BSDCan 2019 -- mcl"
Could someone tell me if 5GHz .ac wifi is working in modern FreeBSD or not? Also I'm wondering if there is anything NixOS alike built on top of FreeBSD.
That's kind of the killer for laptop usage. Even if there was support for just the most popular broadcom chip or something that would be workable; but, as it is it's unusable on a modern laptop.
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.
I love many BSDs, but yeah sadly they’re hardly usable desktop OS’s for me.
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 feel like FreeBSD lost a lot of momentum once a lot of the Apple contributors moved onto other companies...in contrast to linux which has (or had) several corporate contributors continuing to fund/drive open source commits.
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.
> 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.
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.
I thought M1 silicon could run amd64/x86_64 efficiently via Rosetta, due to changing the memory ordering model to an x86 one. I was hoping that Parallels could somehow take advantage of that.
This is hardly a production use case, but I've had a bare metal server at OVH for several years. It's currently running FreeBSD 13 with bhyve. I have about 4x VMs running on it, including OpenBSD and several different Linux flavors.
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
> >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.
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.
>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.
> BSD gifts companies with an easier path to turning your work into a cloistered and proprietary part of their code
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.
No thanks. It doesn't even support my 3 year old wireless chip and there are still problems with WebRTC in Firefox. They need to use the donations they raised (1,25 million from what I checked last time) to focus on getting decent hardware and software support.
47 comments
[ 4.1 ms ] story [ 113 ms ] thread> 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?
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
For example see the CAVEATS section here: https://man.openbsd.org/iwm.4
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.
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.
This nostalgia is justified - see:
https://news.ycombinator.com/item?id=30063417
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.
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.
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.
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.
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
> 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.
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.