You shouldn't run a BSD on a PC
michal.sapka.me
michal.sapka.me
Isn't it pretty much the only example of this? As long as you don't pick nvidia, you won't have proprietary drivers running.
Of course there are many firmware blobs. It's an issue, I would prefer not running any proprietary firmware, but I don't see how it would be a bigger issue in BSD land.
So yes, the issue is programs assuming Linux (though doesn't many people in the OSS ecosystem using Mac help a bit?), hardware support, and not as much help from the internet. Not too surprising, I would expect this; and the hardware support is what prevents me from considering *BSD. I didn't think of the fact you are not going to be on the bleeding edge too on *BSD, and that would be relevant to me, since I run a rolling distro and take this somewhat for granted.
Bonus note:
> You try to Kagi[6] it and nothing
I would suggest "look it up" as a term that will remain stable and doesn't advertise a particular search engine. The best thing is you won't need a footnote either (however, I sympathize with the wish to make people use something else than Google).
It's closed-source, and it's Linux. There is no firmware for BSD.
Of course it's closed-source. I still don't see how it's a bigger issue for the BSDs than for Linux. As in, it's already a big issue for Linux. On Debian they are in a separate section of the repositories (non-free-firmware) that can be disabled. The *BSD could do the same kind of thing. I believe it's up to the *BSD to decide whether they want to compromise this way, but it's the same issue for Linux and for the *BSD. Unless I'm missing something.
> and it's Linux. There is no firmware for BSD.
I don't believe the firmware blobs are Linux-specific, are they? They run on the device, their code is not managed by the main OS on the main CPU of the computer. The device doesn't care about what OS is managing them as long as the OS knows how to speak with them. That the drivers are actually to be written / ported to BSD is another matter.
https://www.nvidia.com/en-us/drivers/unix/
FreeBSD ships firmware blobs both in tree, e.g.,
https://github.com/freebsd/freebsd-src/tree/main/sys/contrib...
and via ports/packages, e.g.,
https://ports.freebsd.org/cgi/ports.cgi?query=firmware&stype...
- You may need to unlearn some Linux-isms
- Your software may assume GNU instead of POSIX
- You will not get good GPU/WiFi driver support
- You may need to relearn looking for answers
- You will need to learn how your OS works
While Linux is more noob-friendly, and BSD is known for "RTFM!", it is in part because very small communities cannot service the masses with tailored answers in every possible form (so we settle for well-maintained docs rather than highly searchable variations over a theme), and perhaps in part simply because of a culture difference where BSD users dedicate themselves to their platforms more than many Linux users (myself included), and answering questions from people who don't try to get a full picture, but just want to move on, creates an un-even playing ground. I don't know, I just liked how you can elevate the conversation about community dynamics beyond "BSD users are mean because 'RTFM!' contains a swear word!"
Now I run FreeBSD on server and my personal laptop. I don't understand what is the point of this article, I had a problem with LTO5 LTFS on server, installed minimum debian into bhyve, did a PCI passtrough and shared the mountpoint. Works like a charm.
I am not using FreeBSD to support all the hardware in the world but to have a nifty environment, that is stable. And it stays stable (was regularly upgraded from FreeBSD 8 to latest, hardware has changed twice, still running the same installation), while linux is starting to look more and more like furball on y2y basis (not talking about kernel, distributions are THE problem).
---
I would like to challenge arch/gentoo users to try FreeBSD for a while. Just for fun, use vm. You might be surprised how complicated for no reason can linux distributions be. This is how I made a switch to it.
(since it's a very convenient way to hide the subject when it would really matter, in addition to not have to specify the subject when it actually doesn't matter)
And they are telling you what they think.
This is both a totally factual warning and advocacy.
Title is fine and matches the content.
Even though there is another level at which some few readers end up being curious and try exactly the thing being nominally warned against, and this reaction is intentional, the surface literal meaning is also plain fact and neither misleading nor non-literal paternalistic literary device.
The reasons given are actually true and are reasons one might not want to use a BSD as a desktop.
The contrary reaction to reject the advice and try to run BSD is expected but only from a few people. The title and the content are 100% plain surface value good true advice. You will have those problems.
As for the title, if they themselves do run BSD despite those problems, then the title is fine. They are simply reporting what life is like. There is nothing wrong with that.
Exactly what way do you think GNU/Linux is better?
What I like the most about FreeBSD is the flexibility it offers, similar to GNU/Linux, yet at the same time it feels like an integrated system?
Additionally. The FreeBSD pkg and ports combo beats every GNU/Linux distro I’ve ever tried, and I’ve tried many of them.
Certainly I agree with the author of the blog post in many ways. If I was not using FreeBSD as a server OS, I would (maybe) not use it on the desktop.
like maybe if I just needed a simple browsing-word-coding box, but there are Mac offerings there if I want to go fancy, or linux on a commodity Dell/Acer, if I don't, and most of the linux offerings are usable desktops right out of the metaphorical box
Firefox on FreeBSD is a hack layered over a hack running slowly. I have no idea how much work is required to support it, but it’s somewhere between “big” and “have mercy”.
On linux too. I have to install Wayland just to be able to start Firefox.
Are you on Ubuntu, by any chance? They replaced their firefox with a snap version (even if you `apt install` it, there's a redirect) which I've heard is significantly slower to start.
What magic am I applying without knowing it?
I use FreeBSD on laptops/desktop since 2005 and it mostly works.
Do some things do not work? Sure. Do all things work on Linux? Nope. Do all things work on Windows? Nope. Not to mention how many times Linux or Windows break to the point of reinstall.
From all the OSes I know – and they are a few – FreeBSD sucks the least – just pick the right hardware.
Yes but the BSD license allows a lot more. So this isn't really a problem.
> Firefox on FreeBSD is a hack layered over a hack running slowly. I have no idea how much work is required to support it, but it’s somewhere between “big” and “have mercy”. About that closed-source ones? No Office for you.
Firefox works fine on FreeBSD.
And MS office is not available on Linux either. Open source office stuff is. I use abiword myself.
> Nada. GNU/Linux has plethora of sites, blogs, and vlogs. Any problem you may encounter, someone else already solved and documented
This is actually a problem with Gnu/Linux. A solved issue on arch may not be the solution on Debian or redhat. Really these distros are different OSes but they are not treated as such.
> You need to enjoy making it work for you. Otherwise, all you will find is annoyance and a swift OS change.
Well yes. Here I agree. I love running my FreeBSD desktop. But it's not as much work as he claims and the community is really helpful. Because it's so small you can often reach out to the maintainers directly and because they're completely non-commercial you will get real answers, not the corporate line. This is the main thing I love about FreeBSD. There's no double motive. Nobody trying to make a buck or push their own intellectual property. If some corporation is paying to do work for you they're doing that because they're expecting to make more money off you one way or another. There's no win-win. Linux is more neoliberal, BSD more socialist and grassroots.
> Next: do you like to call yourself an early adopter? Being in the bleeding edge is what gets you going? BSD are evolving slowly by design. If something works, let’s leave it alone. That’s the mantra. GNU/Linux is changing rapidly - Pipewire, Wayland, SystemD. Even good old ifconfig is being deprecated. At the same time BSDs still use technology from decades ago7. There was never a need to replace them, so no one did it.
Yes this is a huge benefit of the BSDs in my opinion. No changes for the sake of it.
Overall, l think the title of the article is way too black and white. Yes you need to be aware of what you're getting into. But if you're even trying this, you already do. Nobody runs BSD on their desktop because some magazine told them it's the best thing ever.
ahm .... is not that the exact problem that a code with a higher amount of restrictions to be transferred into a licensed environment with less restrictions.
Unless you are fine with this and your only concern is that your code is permissively licensed and you don't care that much about further restrictions applying to the whole project.
I believe the *BSD care and want to keep their projects licensed under BSD though. Some GPL code in the BSDs would suddenly prevent use case that are possible today.
Personally I think the whole license thing is a bit overrated anyway. It's more the GNU crowd making this a huge thing, whereas the BSD approach is more like "do whatever you want". Another thing why the BSD camp fits me better.
Personally I don't really care about licenses, it's just some legalese to me (I never bother to read or obey EULAs either for example). And if I share some of my code as FOSS I don't even assign a license. But that's just my personal thing.
Yes, although any GPL program in the BSD land cannot grant the same freedoms than BSD programs and will have to be filtered out for some use cases, which weakens the point of the BSD distributions a bit. That's not only the kernel, it's also userspace tools.
> It's more the GNU crowd making this a huge thing, the BSD approach is more like "do whatever you want"
I don't believe this to be the case. Some people in the BSD world are adamant that their code should not be contaminated by the GPL for instance because suddenly, they could not grant the rights to their users to take the code and put it into a proprietary product.
Some people in the BSD world have a strong opinion on how permissive licenses are the right way to do open source / free software.
> the GNU crowd making this a huge thing
I believe this to be a huge thing though. It is a huge thing. You should care what people can and cannot do with your code. Maybe you care that people can do "whatever you want" with your code. I think it's worth stopping and thinking about this stuff and the consequences for a moment, at least once. The world is very little "don't care, whatever", things have consequences and maybe you care about some of them. Surely you deeply care about some things? (of course there's no bad answer, you can answer no)
I myself think the GPL is the better option in most cases, because I care that the end users' freedom is guaranteed. I pretty much don't want developers to do "whatever they want" with my work, I want them to respect their own users' freedom. This is highly political/philosophical of course.
(there are exceptions, for example for codecs you might want the code to be as permissive as possible so the free codec itself is spread and is not replaced with a proprietary one for instance)
Yes, and? They want people to be able to use their code freely, without limitations. Check golang packages, they are mostly BSD/MIT.
Thats why BSD is in Playstation and Macs. You think there would be linux GPLed code? There is a usecase for everything and linux doesnt cover them all.
> Yes, and?
And? Nothing. I'm making an observation, I'm not judging here. They have a strong stance on this, often because they deeply thought about the consequences. I don't agree with them, and I don't care for helping Apple and Sony make their proprietary products, I think we'd probably be in a better world if they participated in improving the commons and that's actually how Linux succeeds, but I respect this stance when it's well thought out.
For fun check this beauty: https://man.freebsd.org/cgi/man.cgi?query=setfib&apropos=0&s...
This why we use FreeBSD. As not only its kernel but also its userspace is well designed.
Yes I care very much about people making their own decisions in their own lives (e.g. LGBT, abortion etc) and with ever more restrictive laws (even here in Europe) I kinda just have given up on the law in general. I just shrug at it while the extreme-right tries to curtail our rights (in my country a quarter of people voted extreme-right in our last election). I just don't think legalese is the way to protect this. It's not working anyway.
Also I'm just totally not a 'team player' so I don't care about loyalty to a party, group or country.
> I myself think the GPL is the better option in most cases, because I care that the end users' freedom is guaranteed. I pretty much don't want developers to do "whatever they want" with my work, I want them to respect their own users' freedom. This is highly political/philosophical of course.
I don't think the GPL is very good at this. The BSD license is seen as more friendly to business but in practice it gives users more freedom. Especially because the GPL protects the rights of all contributors including corporate ones, the corporate market loves GPL much more and thus is more involved. Which always comes with more strings attached. I view GPL more as protection of the authors, not the end users.
The few times serious tinkering was done by commercial entities in BSD it was basically a huge disaster: https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
Totally with you on this
(and that's why I think the software industry should be producing free software for people. So they can make their own decisions without depending on their original providers. Of course, free software is not a sufficient condition to this.)
> I kinda just have given up on the law in general.
Okay, but I hope you'll understand many of us don't see this as an option.
> I don't think the GPL is very good at this. [...]
I don't see how end users have more freedoms with BSD programs and how the GPL comes with more strings attached for the user (who doesn't intend to build proprietary software - of course I'm against this so if you see this as an attached string, I see this string in good light).
> I view GPL more as protection of the authors, not the end users.
I think you are wrong on this. The user owes nothing to the author of a GPL program. They can modify it without contributing back. The authors are not guaranteed to see the improvements to their code, also users are guaranteed the freedoms that come with free software, even for the derivatives (this is where the GPL shines, in my view, compared to permissive licenses).
> commercial entities
iXsystems, Inc.: sponsored commits in three FreeBSD source trees:
https://gist.github.com/grahamperrin/eb0bf1a03b64e14d9288cbd...
Created last week, a snapshot of that point in time, I don't intend to update it.
That's not true. The GPL cannot re-license other project's. You just have to write a file with (for example):
We use GPL-Software XY, and here you can find our changes to it...that's it,
Most proprietary consumer-router-firmware handle gpl just like that, Android has the Linux-kernel and is (over all) NOT GPL.
I'm talking about putting some GPL code in a program whose code is BSD licensed.
Putting a GPL program in a BSD software distribution would not make the whole package GPL
(However GPL restrictions will apply to the GPL parts and you may not want this in your package of BSD-licensed software)
Of course you can run GPL software on your BSD system, the same way you can run proprietary software on Linux (and BSD).
Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL. Now you can always distribute your BSD-licensed kernel and make your users compile some GPL code into your kernel themselves.
It's just that the GPL code unavailable to people that want to build some proprietary product from your BSD distribution, and as a BSD distribution, you might not want too much of this.
NO, absolutely NOT. Not you nor the GPL has the right to re-license someone else code. There are many modules who are not GPL like Nvidia and not even AMD-GPU -> MIT...and still the kernel is GPL, and even the kernel itself has many different (but compatible to GPL2) licenses.
If you change GPL code you have to show your changes (if you redistribute the code) if you have MIT/BSD you don't have to make that step, it really has nothing todo if you mix that stuff (if compatible). The maybe ~problem with CDDL/GPL (ZFS) however is, that you redistribute it in binary form.
You are mentioning NVidia and this actually illustrates my point: nobody distributes the Linux kernel with the NVidia driver because you can't, because of the GPL that forbids you from linking GPL with proprietary code and distributing the result. Instead, you make the user download the kernel, download the nvidia driver and then compile the module locally. That's why we have DKMS. It's a hack around the distribution limitations. Of course it doesn't please the Linux kernel developers too much and that why they have the GPL-only symbols (things that only work if your module is GPL-compatible).
The CDDL/GPL issue of ZFS is the same thing: you just can't distribute the whole thing together if you consider that the licenses are not compatible or don't want to take the risk. Ubuntu certainly does take it but not the rest of the world.
Also no need to get upset, let's have a calm argument, please?
Yes and i am totally fine with your latest explanation, however you wrote:
>Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL.
And that's just wrong, just because i run a GPL-Driver on Windows make Windows not GPL, and just because i run a GPL-Driver in a BSD makes BSD not GPL, it just means, that package has many licenses and the most restrictive but compatible is (for example) the GPL, so you probably want to follow it's rules.
>Drivers usually run in the kernel though, so a GPL driver would make the whole thing GPL.
Would be: "Any distribution of a kernel with a GPL driver needs to be under GPL and requires the kernel to be under a GPL compatible license."
(I implied distribution because as long as something is not distributed, nothing matters in terms of licensing when it comes to free software licenses.)
Since installing yourself a GPL module in any kernel doesn't constitute a distribution, the direct consequence is that the module and the kernel are distributed separately in such incompatible cases. Which would also be true of GPL drivers on Windows, but the kernel is always distributed alone by Microsoft and the GPL driver by the vendor (while for Linux, distributions could decide to compile the kernel with third-party modules - not sure how the BSD world works in this regard) so the situation is somewhat easier to understand.
Now, distributing GPL code explicitly meant to be linked to the Windows kernel might be a grey area and probably requires all the authors to agree to this. Like, it's not 100% clear to me whether you can take some random GPL code and put it in a GPL driver explicitly intended to be linked to the Windows kernel even if you don't distribute the result yourself. I guess that would be somewhat similar to the ZFS on Linux project though: while everyone writes CDDL code, ZFS on Linux is clearly intended to be linked to the GPL'd Linux kernel.
Thanks for expecting me to be accurate and holding me to higher standards, that's appreciated.
Well you did the same to me, so i have to thank you too ;)
BTW: Absolutely on par with you last comment.
I suspect Windows driver signing requirements may conflict with GPL 3, however, because running Windows in test-signing mode interferes with the normal operation of popular Windows software (e.g., games that require anti-cheat software deliberately incompatible with test-signing mode in general).
OTOH, Windows itself runs just fine in test-signing mode, and surely the fact that other software deliberately chooses not to run if a test-signed driver is installed doesn't imply that Windows is incompatible with test-signed drivers, and therefore GPL 3, so it's hard to say, but I'd personally talk to a lawyer before creating or distributing a GPL 3-licensed Windows driver.
Here's a copy of the click-through license from the latest Windows Driver Kit installer, which, to my non-lawyer eyes, doesn't appear to place any restrictions on use or distribution of drivers created with it, in source or binary form:
https://jasomill.at/wdk-license.html
Obviously any individual or project using proprietary headers under this license to build a driver would have to accept its terms, but this is no different than, e.g., using proprietary headers under the Xcode license to build GPL software for macOS, and the FSF, at least, seems to be fine with this, given that the Emacs project recommends[2] a macOS binary distribution[3] that does precisely this[4], so I assume it's okay.
[1] https://github.com/mirror/vbox/blob/master/src/VBox/Addition...
[2] https://www.gnu.org/software/emacs/download.html#macos
[3] https://emacsformacosx.com/
[4] https://git.savannah.gnu.org/cgit/emacs.git/tree/configure.a...
But did they take third party GPL code from someone else? If they are the only authors of the code or if all the contributors have directly contributed to the drivers (thus knowing full well their code would end up being linked to the windows kernel), then there can't be any issue.
On FreeBSD you can run GPL software without issues. It's all userland anyway. FreeBSD has now separation between kernel and installed software than Linux (where usually if you want rolling userland you must have a rolling kernel too)
There's no problem incorporating BSD-licensed code into GPL-licensed software, though.