In my teenage years I have used all of the bigger BSDs (FreeBSD, NetBSD, OpenBSD, DragonFly) as my main desktop for at least half a year each. They worked for what was typical desktop use back then.
Whit it has gotten better at some fronts it got worse on other (for Linux as a desktop as well though). I am not sure why, but lately I think it might be that the browser became the OS. Even when not strictly speaking using a browser you likely do, in form of Electron apps, etc. While hardware support has become really good, I think it’s really sad that one now has to jump through hoops, for example due to DRM making their way in the browser. Even getting Flash to run seemed nicer back then. Even though I’ve heard there’s good work-arounds now if you have to watch Netflix on it.
I haven’t used any of the BSDs in a long time, but at this point it’s mostly due to having this Arch Linux installation for over a decade and I am too lazy to set up something new.
If you are however not in such a state, I think I’d agree with the article. Just don’t expect it to be Linux. That can be helpful. If you are expecting just another Linux distro (and you will do that at some points) you will be mistaken. It’s a different OS with different trade-offs. In fact the BSDs are all pretty different OSs. And while people say things like “OpenBSD for security” they are all general-purpose OSs. Every one of them supports hardware that another one doesn’t (not just due to some install time difference, like on Linux). Each one of them is a daily driver for people. And one last thing that’s nice about the BSDs compared to people using Linux on the desktop, is that they tend to be pragmatic and not ideological. There also is very little in terms of “being a missionary to Windows users” or things like that. That article as far as it typically goes. People tend to be surprised ask the community “Why should I use BSD?” only to not hear any advertisements or even reasons.
If you want to try it I’d just like with programming languages give the advice to use it seriously for at least half a year before you judge it. Just like with programming languages things won’t make sense or seem weird in the beginning. I also want to repeat that while they are all called BSDs they are pretty different and you can’t expect really anything to be the same as the other. They are not just distros and they are not just kernels. Also I’d advise to start with the OSs, not some LiveCD or some pre-made desktop. In my experience people are extremely disappointed and never touch the BSDs again with any of those ready made systems. For some reason they tend to be a lot worse than what you’ll come up with if you even follow the simplest guides you found via Google. Even though it’s out-dated I think this one is worth mentioning. I think it would largely still work (and still will in a few years). Some stuff might not be necessary anymore.
Vermaden’s guide desktop guide is great, but I think also really intimidating. It goes into specifics of basically a perfect system for them with where specific application. If you want to just setup your KDE/GNOME/XFCE/… desktop I think it’s probably too much.
I haven’t used any of the BSDs in a long time, but at this point it’s mostly due to having this Arch Linux installation for over a decade and I am too lazy to set up something new.
I totally understand you. I use (and improve) my Openbox setup and I am happy about it - but when I would have to move to new WM (od even DE) it would rather be something like MATE/XFCE then FVWM3 … although I always wanted to try FVWM and configure it my own way :)
Vermaden’s guide desktop guide is great, but I think also really intimidating. It goes into specifics of basically a perfect system for them with where specific application. If you want to just setup your KDE/GNOME/XFCE/… desktop I think it’s probably too much.
It is not intended - to be intimidating - but wanting to explain how all things work in details just takes some space and time.
I also try to provide easier/simpler guides with XFCE or GNOME for example such as these:
Sometimes even based on GhostBSD to have faster and easier start/install … to be honest after GhostBSD moved back from OpenRC to rc(8) sussystem that FreeBSD uses there are really no obstacles why no to use it if you want to have fast and easy FreeBSD desktop. Its really great and it also has GUI for updating the system and managing ZFS Boot Environments. I look really forward of its future and development.
Sorry, I think I worded it badly with “intimidating”. What I really mean is that they are extremely detailed because you detail also non-FreeBSD application in detail and in fact that’s why I also like to read them. You explain how to go from 0 to a complete setup that is also really nice.
What I meant with intimidating is that someone jumping into a new OS and wanting to quickly set up an OS often wants to basically see how to get this and that running quickly. That’s what I like about the other guide.
It wasn’t meant as a criticism, not even a productive one. Yours is an in-depth guide on how to set up a really good nice FreeBSD desktop, while the other is a guide to quickly get X running on FreeBSD. So they to me have different goals.
I’ve read your guides and they are amazing. What I meant with intimidating is the detail. And also yours is a guide to set up a specific, well configured system, while the other is more like “And this is how you should get sound running”, “This are the commands to get KDE installed”, which for some people is how they start out with a new OS.
I hope that clarifies it. Intimidating was just as you say. Having a really good guide to set something up in detail. I’ve used them, I’ve recommended them.
But I do like the other one mentioned because if you start out with an OS you might want to speed through “now I have that standard desktop”, so you have your browser and stuff and then can work through details. For example if someone actually wants to play with jails, but wants to have KDE and a browser and be able to watch YouTube or something like that, not really considering the setup part of the learning process yet.
The reason why I explicitly mentioned it is because I wanted to use it as a contrast. Yours is in great detail and specific, the other one is a bit more like a cheat sheet.
I haven’t used GhostBSD at all. I just know that there have been FreeBSD desktop projects with the best intention, but they have a tendency to make people think things are a FreeBSD-problem when they are a problem specific to the “FreeBSD distribution” (distribution as opposed to derivative, so like GhostBSD is to FreeBSD, not OpenBSD and FreeBSD for example) so to say. And sometimes things that you can easily work well feel next to impossible on one of them to work well for some configuration reason for example. And the bigger Linux desktop distributions all had a lot more people working exclusively on that than any FreeBSD desktop distribution ever had.
Sorry, I think I worded it badly with “intimidating”.
None offense taken - I got the idea.
Also I really like (and try) to improve - so any hints are welcome … and what better place for them then comments? :)
I haven’t used GhostBSD at all.
I know that You are happy with your Arch setup - but IMHO next time when I will think of trying (or just weekend tinkering) about FreeBSD - start with GhostBSD. After they (GhostBSD) went back from OpenRC to rc(8) that FreeBSD uses it really is more or like FreeBSD STABLE with graphical GTK installer and MATE GTK GUI (XFCE option/ISO is also available).
It just takes a lot less effort to start playing with it.
The only thing that I still do not like about GhostBSD is that by default it uses fish(1) shell … and to be honest its quite good interactive shell … its just that zsh(1) is a lot better :) There are some objections against ZSH that i takes a lot to config it right … same for Openbox I think :)
I gathered quite nice ZSH config for all these years and I shared it here (also with fish(1) like coloring and syntax completion):
I haven’t tried it, but one of @vermaden’s articles linked to a script that installed the Linux version of Chrome and ran it with the Linux ABI layer. I’m not sure how good an idea this is (I think a bunch of the Linux security features are not implemented), but apparently it now works well enough for things like Netflix to work.
Thanks. It would be nice if it installed in a jail with a ZFS ruleset that exposed the /dev/drm and /dev/pcm interfaces (or the PulseAudio socket, if it’s using a native sound server?) and mounted users’ downloads directories, so it didn’t interfere with other Linuxulator uses. As I understand it, the Linuxulator does not currently support seccomp-bpf, SELinux policies, or Linux namespaces, so Chromium-based browsers will lose most of their security features. That would make me a bit nervous about using it for anything that required credentials or dealt with sensitive information.
To be honest I would love to see a paper/document how Linux Compat Layer security compares to a FreeBSD Jail or a Linux Jail - and if Capsicum is used and where for example. Unfortunately I was not able to find such information …
About Chrome sandboxing on FreeBSD - FreeBSD developers sent patches to Chrome to add Capsicum sandboxing to it - but they were refused:
To be honest I would love to see a paper/document how Linux Compat Layer security compares to a FreeBSD Jail or a Linux Jail - and if Capsicum is used and where for example
On Linux, Chromium uses seccomp-bpf to limit the system calls that the renderer sandbox can make namespaces to restrict what it can do in terms of access to the host filesystem and network access.
Capsicum provides a more principled approach to both of these. It blocks all system calls that allow access to global namespaces and limits all of the ones that allow access to anything outside of the process’ address space to operating on file descriptors that carry the correct (fine-grained) permissions. This makes it trivial to implement the Chromium sandboxing model (less than a tenth of the code of the Linux approach).
Jails and Capsicum have very different usage models. Jails are intended to isolate programs from the rest of the system, Capsicum is intended to allow programs to run with minimal privilege or to run parts of themselves with minimum privilege. If you run Chromium in a jail, it’s hard (requires a kernel bug, not impossible - the kernel is a massive C codebase, after all) for it to touch anything on the host system. That doesn’t really help much with the threat model for web browsers, where often the browser is the target for attackers. If you use webmail, for example, an attacker who compromises the jail that runs Linux Chrome can still get your webmail credentials and can then do password resets on other accounts and so get control over a lot of your digital life, even if they can’t touch other files that you have locally. This is why Chromium separates each renderer process into something separately isolated: if it’s compromised then the attacker gains only data associated with the current site. That’s still not wonderful because a compromise from some HTML embedded in a email opened in gmail can compromise your gmail, for example.
Unfortunately, the effort from the ChromeOS team to upstream Capsicum support to Linux failed and so there’s no Linux build that supports Capsicum.
I believe some folks are thinking about adding seccomp-bpf and namespaces to the Linux ABI layer. I’m not a huge fan of this because seccomp-bpf is a terrible idea. It makes it very easy for an attacker to inject gadgets into the kernel that can be used to exploit speculative execution vulnerabilities. Any system that allows arbitrary seccomp-bpf policies at the moment should assume that nothing in the kernel is secret.
Very nice advocacy. All about the positives and upsides, not overdoing it. It’s been ages since I actually road-tested a *BSD, and if I had just a little more spare time I’d be inclined to throw FreeBSD or NetBSD on an older machine for fun.
AFAICT, there are 2 motivations for running any of *BSD as a daily driver desktop.
Education. You want to learn more about FreeBSD because you need to know about *BSD or how unix OSes other than linux work.
You have older or unusual hardware that you want to use as your daily driver, in which case, of course it works with NetBSD.
Outside of those, running these as your main computing interface to the rest of the world is just opening yourself up to a world of pain. You will be forever tinkering with esoteric command lines and text files to do things that just work on Windows, or Mac, or even Linux.
“That’s fine,” I hear you say, “I love tinkering with my computer”, and I do, too, but the need to tinker to get something to work inevitably comes up when you’re in the middle of something important and need your daily driver, not when you have a free afternoon to tinker with cups because you need to print something important.
I would also say that some people (like me for example) prefer to their system (and hardware controlled by this system) to behave in a specified way. That way may be different from popular systems like Windows or macOS … or even from Linux.
Some people do not like being ‘misleaded’ by systemd(1) or PulseAudio in the name of convenience.
Some people prefer to know what is happening and being sure that other thing will not happen no matter what … and they are willing to pay for that specific behavior in their time with step learning curve on BSDs.
I think this is the case for most BSD (or even Illumos) users preferring to learn more to have exactly (or closer to) what they believe suit their needs best.
That has not been my experience with BSDs. Unless you’ve read over and understood every line of BSD source code, you will be surprised or misled occasionally by the way the system works. It happened to me with FreeBSD multiple times where the way the system ran did not match the documentation. What are simple operations under Linux or MacOS take hours of googling and experimentation.
You may not like systemd, or pulseaudio, but they don’t mislead you. It’s just software. It may not work the way you like, but that’s not misleading you.
I’ve used OpenBSD as a daily-driver desktop for about 2 years now. As vermaden says, it’s an OS that behaves exactly as described. I feel I can trust it more than other OSes, in so many ways. The hyper-focus on security and sanely-designed related features is a huge benefit as well. The computer isn’t doing a bunch of stuff I don’t want it to, and it allows extremely granular control over what it does. The maintenance and upkeep is extremely straightforward (shockingly so), and applying system upgrades is the easiest of any OS I’ve ever used in my life. The more I use it, the more I want to install it on all my other systems. Yeah, I’ve learned a bunch along the way, but that was just a side-effect of wanting an OS that doesn’t enrage me constantly – something that literally no other OS has provided me in years.
Sidebar, my Pop!_OS install is broken again, I can’t update despite always using the built-in software management tools - at the moment it appears /boot is full because for some reason it doesn’t prune the ancient kernels my system no longer uses, and the default partition size is enough for like 2 kernels or something ridiculous like that. That’s not the only issue though, but I haven’t reviewed the logs yet. Last time it was because for some reason the apt repos were moved to a completely different domain because apparently if you wait too long to update, the packages you need are just… moved away? I had to switch my apt config to point to some other domain and then spend literally hours trying to update everything: fix the broken installs, try to update, fix the broken stuff, try to update.. rinse and repeat. I 100% don’t care why, this approach to upgrading is just ridiculous.
If you use UEFI hardware, it uses the systemd bootup tool, which keeps your kernel and your initrd in the UEFI ESP. This means you need an extra-large ESP… but Gparted can’t resize ESPs because it can’t resize FAT32 drives under a certain minimum size, and typically ESPs are smaller than that. (TBH it makes little sense to use FAT32 under 0.5GB, but that’s UEFI for you: it makes little sense in general. Nor does systemd in a lot of ways.)
So, general guidelines:
either run Pop on BIOS boot (then it uses GRUB);
or, make an extra-large ESP before you install;
ideally, don’t try to dual-boot Pop on UEFI;
for distro vendors, don’t use experimental bootup tools on PCs that already have >1 OS in place;
for the systemd-boot team, if you need a big ESP, fix the standard partitioning tool so it can make one for you;
Ubuntu (& spinoff) users: on the end of your normal cleanup commands, add:
In my teenage years I have used all of the bigger BSDs (FreeBSD, NetBSD, OpenBSD, DragonFly) as my main desktop for at least half a year each. They worked for what was typical desktop use back then.
Whit it has gotten better at some fronts it got worse on other (for Linux as a desktop as well though). I am not sure why, but lately I think it might be that the browser became the OS. Even when not strictly speaking using a browser you likely do, in form of Electron apps, etc. While hardware support has become really good, I think it’s really sad that one now has to jump through hoops, for example due to DRM making their way in the browser. Even getting Flash to run seemed nicer back then. Even though I’ve heard there’s good work-arounds now if you have to watch Netflix on it.
I haven’t used any of the BSDs in a long time, but at this point it’s mostly due to having this Arch Linux installation for over a decade and I am too lazy to set up something new.
If you are however not in such a state, I think I’d agree with the article. Just don’t expect it to be Linux. That can be helpful. If you are expecting just another Linux distro (and you will do that at some points) you will be mistaken. It’s a different OS with different trade-offs. In fact the BSDs are all pretty different OSs. And while people say things like “OpenBSD for security” they are all general-purpose OSs. Every one of them supports hardware that another one doesn’t (not just due to some install time difference, like on Linux). Each one of them is a daily driver for people. And one last thing that’s nice about the BSDs compared to people using Linux on the desktop, is that they tend to be pragmatic and not ideological. There also is very little in terms of “being a missionary to Windows users” or things like that. That article as far as it typically goes. People tend to be surprised ask the community “Why should I use BSD?” only to not hear any advertisements or even reasons.
If you want to try it I’d just like with programming languages give the advice to use it seriously for at least half a year before you judge it. Just like with programming languages things won’t make sense or seem weird in the beginning. I also want to repeat that while they are all called BSDs they are pretty different and you can’t expect really anything to be the same as the other. They are not just distros and they are not just kernels. Also I’d advise to start with the OSs, not some LiveCD or some pre-made desktop. In my experience people are extremely disappointed and never touch the BSDs again with any of those ready made systems. For some reason they tend to be a lot worse than what you’ll come up with if you even follow the simplest guides you found via Google. Even though it’s out-dated I think this one is worth mentioning. I think it would largely still work (and still will in a few years). Some stuff might not be necessary anymore.
https://cooltrainer.org/a-freebsd-desktop-howto/
Vermaden’s guide desktop guide is great, but I think also really intimidating. It goes into specifics of basically a perfect system for them with where specific application. If you want to just setup your KDE/GNOME/XFCE/… desktop I think it’s probably too much.
https://vermaden.wordpress.com/
I totally understand you. I use (and improve) my Openbox setup and I am happy about it - but when I would have to move to new WM (od even DE) it would rather be something like MATE/XFCE then FVWM3 … although I always wanted to try FVWM and configure it my own way :)
It is not intended - to be intimidating - but wanting to explain how all things work in details just takes some space and time.
I also try to provide easier/simpler guides with XFCE or GNOME for example such as these:
https://vermaden.wordpress.com/2022/02/09/xfce-cupertino-way/
https://vermaden.wordpress.com/2020/10/18/freebsd-gnome-3-fast-track/
Sometimes even based on GhostBSD to have faster and easier start/install … to be honest after GhostBSD moved back from OpenRC to rc(8) sussystem that FreeBSD uses there are really no obstacles why no to use it if you want to have fast and easy FreeBSD desktop. Its really great and it also has GUI for updating the system and managing ZFS Boot Environments. I look really forward of its future and development.
Regards.
Sorry, I think I worded it badly with “intimidating”. What I really mean is that they are extremely detailed because you detail also non-FreeBSD application in detail and in fact that’s why I also like to read them. You explain how to go from 0 to a complete setup that is also really nice.
What I meant with intimidating is that someone jumping into a new OS and wanting to quickly set up an OS often wants to basically see how to get this and that running quickly. That’s what I like about the other guide.
It wasn’t meant as a criticism, not even a productive one. Yours is an in-depth guide on how to set up a really good nice FreeBSD desktop, while the other is a guide to quickly get X running on FreeBSD. So they to me have different goals.
I’ve read your guides and they are amazing. What I meant with intimidating is the detail. And also yours is a guide to set up a specific, well configured system, while the other is more like “And this is how you should get sound running”, “This are the commands to get KDE installed”, which for some people is how they start out with a new OS.
I hope that clarifies it. Intimidating was just as you say. Having a really good guide to set something up in detail. I’ve used them, I’ve recommended them.
But I do like the other one mentioned because if you start out with an OS you might want to speed through “now I have that standard desktop”, so you have your browser and stuff and then can work through details. For example if someone actually wants to play with jails, but wants to have KDE and a browser and be able to watch YouTube or something like that, not really considering the setup part of the learning process yet.
The reason why I explicitly mentioned it is because I wanted to use it as a contrast. Yours is in great detail and specific, the other one is a bit more like a cheat sheet.
I haven’t used GhostBSD at all. I just know that there have been FreeBSD desktop projects with the best intention, but they have a tendency to make people think things are a FreeBSD-problem when they are a problem specific to the “FreeBSD distribution” (distribution as opposed to derivative, so like GhostBSD is to FreeBSD, not OpenBSD and FreeBSD for example) so to say. And sometimes things that you can easily work well feel next to impossible on one of them to work well for some configuration reason for example. And the bigger Linux desktop distributions all had a lot more people working exclusively on that than any FreeBSD desktop distribution ever had.
None offense taken - I got the idea.
Also I really like (and try) to improve - so any hints are welcome … and what better place for them then comments? :)
I know that You are happy with your Arch setup - but IMHO next time when I will think of trying (or just weekend tinkering) about FreeBSD - start with GhostBSD. After they (GhostBSD) went back from OpenRC to rc(8) that FreeBSD uses it really is more or like FreeBSD STABLE with graphical GTK installer and MATE GTK GUI (XFCE option/ISO is also available).
It just takes a lot less effort to start playing with it.
The only thing that I still do not like about GhostBSD is that by default it uses fish(1) shell … and to be honest its quite good interactive shell … its just that zsh(1) is a lot better :) There are some objections against ZSH that i takes a lot to config it right … same for Openbox I think :)
I gathered quite nice ZSH config for all these years and I shared it here (also with fish(1) like coloring and syntax completion):
With this guide its really pointless to use fish(1) as comparing to that zsh(1) setup the fish(1) shell is just limited :)
Regards.
Agreed. Very well written.
I haven’t tried it, but one of @vermaden’s articles linked to a script that installed the Linux version of Chrome and ran it with the Linux ABI layer. I’m not sure how good an idea this is (I think a bunch of the Linux security features are not implemented), but apparently it now works well enough for things like Netflix to work.
Hi.
Its this one:
… and yes it works as desired :)
I also really like that it also covers updating that environment with this command:
So you do not end up with some old insecure bloat after a year and need to reinstall it again.
Hope that helps.
Regards.
Thanks. It would be nice if it installed in a jail with a ZFS ruleset that exposed the /dev/drm and /dev/pcm interfaces (or the PulseAudio socket, if it’s using a native sound server?) and mounted users’ downloads directories, so it didn’t interfere with other Linuxulator uses. As I understand it, the Linuxulator does not currently support seccomp-bpf, SELinux policies, or Linux namespaces, so Chromium-based browsers will lose most of their security features. That would make me a bit nervous about using it for anything that required credentials or dealt with sensitive information.
To be honest I would love to see a paper/document how Linux Compat Layer security compares to a FreeBSD Jail or a Linux Jail - and if Capsicum is used and where for example. Unfortunately I was not able to find such information …
About Chrome sandboxing on FreeBSD - FreeBSD developers sent patches to Chrome to add Capsicum sandboxing to it - but they were refused:
https://lists.freebsd.org/pipermail/freebsd-chromium/2016-July/002554.html
https://lists.freebsd.org/pipermail/freebsd-chromium/2016-July/002562.html
I also once did a guide on ‘secure’ Jailed browser here:
Hope that helps.
On Linux, Chromium uses seccomp-bpf to limit the system calls that the renderer sandbox can make namespaces to restrict what it can do in terms of access to the host filesystem and network access.
Capsicum provides a more principled approach to both of these. It blocks all system calls that allow access to global namespaces and limits all of the ones that allow access to anything outside of the process’ address space to operating on file descriptors that carry the correct (fine-grained) permissions. This makes it trivial to implement the Chromium sandboxing model (less than a tenth of the code of the Linux approach).
Jails and Capsicum have very different usage models. Jails are intended to isolate programs from the rest of the system, Capsicum is intended to allow programs to run with minimal privilege or to run parts of themselves with minimum privilege. If you run Chromium in a jail, it’s hard (requires a kernel bug, not impossible - the kernel is a massive C codebase, after all) for it to touch anything on the host system. That doesn’t really help much with the threat model for web browsers, where often the browser is the target for attackers. If you use webmail, for example, an attacker who compromises the jail that runs Linux Chrome can still get your webmail credentials and can then do password resets on other accounts and so get control over a lot of your digital life, even if they can’t touch other files that you have locally. This is why Chromium separates each renderer process into something separately isolated: if it’s compromised then the attacker gains only data associated with the current site. That’s still not wonderful because a compromise from some HTML embedded in a email opened in gmail can compromise your gmail, for example.
Unfortunately, the effort from the ChromeOS team to upstream Capsicum support to Linux failed and so there’s no Linux build that supports Capsicum.
I believe some folks are thinking about adding seccomp-bpf and namespaces to the Linux ABI layer. I’m not a huge fan of this because seccomp-bpf is a terrible idea. It makes it very easy for an attacker to inject gadgets into the kernel that can be used to exploit speculative execution vulnerabilities. Any system that allows arbitrary seccomp-bpf policies at the moment should assume that nothing in the kernel is secret.
Very nice advocacy. All about the positives and upsides, not overdoing it. It’s been ages since I actually road-tested a *BSD, and if I had just a little more spare time I’d be inclined to throw FreeBSD or NetBSD on an older machine for fun.
It is! I’ve used FreeBSD as a daily driver for years, even as a consultant. My setup is here:
https://git.sr.ht/~duncan-bayne/freebsd-setup
AFAICT, there are 2 motivations for running any of *BSD as a daily driver desktop.
Outside of those, running these as your main computing interface to the rest of the world is just opening yourself up to a world of pain. You will be forever tinkering with esoteric command lines and text files to do things that just work on Windows, or Mac, or even Linux.
“That’s fine,” I hear you say, “I love tinkering with my computer”, and I do, too, but the need to tinker to get something to work inevitably comes up when you’re in the middle of something important and need your daily driver, not when you have a free afternoon to tinker with cups because you need to print something important.
I would also say that some people (like me for example) prefer to their system (and hardware controlled by this system) to behave in a specified way. That way may be different from popular systems like Windows or macOS … or even from Linux.
Some people do not like being ‘misleaded’ by systemd(1) or PulseAudio in the name of convenience.
Some people prefer to know what is happening and being sure that other thing will not happen no matter what … and they are willing to pay for that specific behavior in their time with step learning curve on BSDs.
I think this is the case for most BSD (or even Illumos) users preferring to learn more to have exactly (or closer to) what they believe suit their needs best.
Regards.
That has not been my experience with BSDs. Unless you’ve read over and understood every line of BSD source code, you will be surprised or misled occasionally by the way the system works. It happened to me with FreeBSD multiple times where the way the system ran did not match the documentation. What are simple operations under Linux or MacOS take hours of googling and experimentation.
You may not like systemd, or pulseaudio, but they don’t mislead you. It’s just software. It may not work the way you like, but that’s not misleading you.
I’ve used OpenBSD as a daily-driver desktop for about 2 years now. As vermaden says, it’s an OS that behaves exactly as described. I feel I can trust it more than other OSes, in so many ways. The hyper-focus on security and sanely-designed related features is a huge benefit as well. The computer isn’t doing a bunch of stuff I don’t want it to, and it allows extremely granular control over what it does. The maintenance and upkeep is extremely straightforward (shockingly so), and applying system upgrades is the easiest of any OS I’ve ever used in my life. The more I use it, the more I want to install it on all my other systems. Yeah, I’ve learned a bunch along the way, but that was just a side-effect of wanting an OS that doesn’t enrage me constantly – something that literally no other OS has provided me in years.
Sidebar, my Pop!_OS install is broken again, I can’t update despite always using the built-in software management tools - at the moment it appears /boot is full because for some reason it doesn’t prune the ancient kernels my system no longer uses, and the default partition size is enough for like 2 kernels or something ridiculous like that. That’s not the only issue though, but I haven’t reviewed the logs yet. Last time it was because for some reason the apt repos were moved to a completely different domain because apparently if you wait too long to update, the packages you need are just… moved away? I had to switch my apt config to point to some other domain and then spend literally hours trying to update everything: fix the broken installs, try to update, fix the broken stuff, try to update.. rinse and repeat. I 100% don’t care why, this approach to upgrading is just ridiculous.
Not enough info to diagnose, but the 1st time I reviewed PopOS it nuked my system. I was not impressed.
https://www.theregister.com/2021/12/16/pop_os_2110_new_system76/
If you use UEFI hardware, it uses the systemd bootup tool, which keeps your kernel and your initrd in the UEFI ESP. This means you need an extra-large ESP… but Gparted can’t resize ESPs because it can’t resize FAT32 drives under a certain minimum size, and typically ESPs are smaller than that. (TBH it makes little sense to use FAT32 under 0.5GB, but that’s UEFI for you: it makes little sense in general. Nor does systemd in a lot of ways.)
So, general guidelines:
Agreed 100%, the BSDs are a serious breath of fresh air. Try one. For me personally I suggest OpenBSD but just try one.
Why not OpenBSD? I do lots of server stuff, so I’m more likely to get use out of being familiar with it.
Probably author was not familiar with it - but to be honest any BSD will do for a desktop/laptop today.
Derek Sivers on OpenBSD :)
https://rubenerd.com/derek-sivers-on-openbsd/
Well OpenBSD also worth but author is used to or using these two BSDs mainly :)
I keep separate partitions for testing out OSes. I always have a freebsd install with intent to switch to a main driver some day.
Just like with most software it’s uninstallable so what’s the risk or the hemming and hawwing?