There's the Installing Linux on a dead badger HOWTO, but NetBSD actually runs everywhere for realsies. It's also lovely to work with and has the nicest man pages imho.
> Default partitioning: /root goes in the spinal cord and brain stem, /swap and /soul go on the left hemisphere of the brain, and /usr, /var, and /home go on the right. If you're working with a badger with damage to one of those areas, you can repartition one or the other brain hemisphere, but as noted in Step 2, using a brain-damaged badger is not recommended and may interfere with successful installation.
How usable are the BSDs as a GUI daily driver? Like 99% of Linux applications work out of the box or more like 50%?
With new CVEs being discovered in ancient bedrock code on the daily, it seems prudent to switch to a NetBSD/OpenBSD/Qubes system for the next few years until some vulnerabilities might get smoothed over.
I use FreeBSD on all my machines for everything sinc about 11 years GUI is I3/X11/AMD-Card everything works, but please test it yourself, it's like with linux, you just know what's not/is working if you use it daily for all your edge-cases (maybe your scanner, maybe your barcode-scanner your Bluetooth-Stuff your wireless etcetc)
Overall i really love FreeBSD for everything computing (Pi/Laptop/Workstation/Servers).
And the community is great...wanna make a port/src-patch?...just send it to the bug-tracker, no rituals needed ;)
they get accepted or rejected, updating ports/packets would be a wonderful AI job, check newest version, update port, poudriere the thing, test it, make patch, send to bugtracker.
Maybe the AI can even check "funny" upstream commits like it happens with npm/crate and block that stuff.
But FreeBSD ports is incredible up to date so there should be no flood of patches anyhow.
Indeed. This might be naive but it would be grand if projects could have their own models and compute with which to perform these and other tasks, each trained as per the project's ethos/needs.-
This is way too expensive. Models are an inherently centralizing technology, and there's no future for niche projects that don't make up a big part of the major providers training sets.
It has a working X11 with DRM from linux as base so everything graphical will work mostly fine. The issue is more around the OS and some subsystems. OpenBSD is still using the Giant Lock model, so SMP can be an issue. Linux has more independent subsystems so heavy processing is unlikely to impact usb audio (which is an issue I have with my oldish laptop). Another issue is the input subsystem (wscons framework) which is not as sophisticated as Linux Input subsystem. In general, linux subsystems are more sophisticated/complex than their OpenBSD counterpart, but the latter work well enough.
There are some linuxisms in some applications (the recent moves to wayland/systemd,...) but they're mostly easy to port.
Depends on what you need. Software compatibility is mostly good, as long as it doesn't have a dependency on systemd or some other Linux-specific feature. Driver support varies, but FreeBSD in particular is pretty decent there.
FreeBSD has a Linux compatibility feature that lets you run native Linux binaries. I've never used it so I can't say how good it is, though - all the stuff I use runs fine natively.
The major BSDs have decent package management and sizeable repositories, with the option to build software (and customize compile-time options) using the ports or pkgsrc systems. You can also rebuild and customize the kernel and base system (aka "make world") but that's strictly optional these days.
I seem to remember there was some GNOME stuff that had a hard systemd dependency and wouldn't run on the BSDs. That was a while back though and I don't run GNOME so I don't know whatever happened there or what the status is.
FreeBSD does, but I haven't tried it. It has its own chapter in the handbook. No idea about the others. I rarely need to run Windows binaries so I'm not the best person to ask.
NetBSD 11 with Firefox 151 from pkgsrc on a custom CTWM is a usable daily driver for Emacs daemon mode GUI/TUI and console tmux simultaneous use. Remote in from a Windows or macOS desktop.
The problem with missing drivers is not "typing code fast enough", it is knowing that you need to poke 5 into [base-address + $0562] within 5 milliseconds of receiving an IRQ or something stupid like that which good docs would tell you why and how, but most/many vendors will not hand out docs on how to program their chips at that level. They will have docs on how to paint rectangles on an existing surface using the gfx card, but not on how to actually start it at poweron or something along those lines. If you can't make it start painting a screen and waking up the monitor at boot, it is of very little use that you can paint rectangles in the dark.
So even if you can divine that a binary windows driver sometimes writes a 5 into that register at certain times, you will have a far harder time figuring out how and when it is needed to actually do that, and the source you get will be super hard for anyone else to understand if its all magic numbers getting written into "random" locations, compared to say, "wificard.driver.radio_enable = ACTIVATE_RADIO;" even if it compiles into writing 5 to offset $0562. Such reverse-engineered sources are super hard to keep working in the long run, when someone rewrites how and when IRQs are delivered to devices or whatever major is happening in the kernels so this leads to drivers no longer working even if they did have a short period of use.
Microsoft brought up an new processor[0][1][2] with NetBSD...
[0] https://www.microsoft.com/en-us/download/details.aspx?id=524...
[1] https://wiki.netbsd.org/ports/emips/
[2] https://www.microsoft.com/en-us/research/publication/an-onli...
There's the Installing Linux on a dead badger HOWTO, but NetBSD actually runs everywhere for realsies. It's also lovely to work with and has the nicest man pages imho.
lol, how am I only hearing about this now?
Installing Linux on a dead badger
https://strangehorizons.com/wordpress/non-fiction/articles/i...
> Default partitioning: /root goes in the spinal cord and brain stem, /swap and /soul go on the left hemisphere of the brain, and /usr, /var, and /home go on the right. If you're working with a badger with damage to one of those areas, you can repartition one or the other brain hemisphere, but as noted in Step 2, using a brain-damaged badger is not recommended and may interfere with successful installation.
> lol, how am I only hearing about this now?
You're one of today's lucky 10,000! [0]
[0] https://xkcd.com/1053/
How usable are the BSDs as a GUI daily driver? Like 99% of Linux applications work out of the box or more like 50%?
With new CVEs being discovered in ancient bedrock code on the daily, it seems prudent to switch to a NetBSD/OpenBSD/Qubes system for the next few years until some vulnerabilities might get smoothed over.
I use FreeBSD on all my machines for everything sinc about 11 years GUI is I3/X11/AMD-Card everything works, but please test it yourself, it's like with linux, you just know what's not/is working if you use it daily for all your edge-cases (maybe your scanner, maybe your barcode-scanner your Bluetooth-Stuff your wireless etcetc)
Overall i really love FreeBSD for everything computing (Pi/Laptop/Workstation/Servers).
And the community is great...wanna make a port/src-patch?...just send it to the bug-tracker, no rituals needed ;)
I really wonder what will become of these systems once AI agents start intervening en masse - sending patches and the like.-
they get accepted or rejected, updating ports/packets would be a wonderful AI job, check newest version, update port, poudriere the thing, test it, make patch, send to bugtracker.
Maybe the AI can even check "funny" upstream commits like it happens with npm/crate and block that stuff.
But FreeBSD ports is incredible up to date so there should be no flood of patches anyhow.
Indeed. This might be naive but it would be grand if projects could have their own models and compute with which to perform these and other tasks, each trained as per the project's ethos/needs.-
This is way too expensive. Models are an inherently centralizing technology, and there's no future for niche projects that don't make up a big part of the major providers training sets.
Running OpenBSD as a daily driver but with no DE.
It has a working X11 with DRM from linux as base so everything graphical will work mostly fine. The issue is more around the OS and some subsystems. OpenBSD is still using the Giant Lock model, so SMP can be an issue. Linux has more independent subsystems so heavy processing is unlikely to impact usb audio (which is an issue I have with my oldish laptop). Another issue is the input subsystem (wscons framework) which is not as sophisticated as Linux Input subsystem. In general, linux subsystems are more sophisticated/complex than their OpenBSD counterpart, but the latter work well enough.
There are some linuxisms in some applications (the recent moves to wayland/systemd,...) but they're mostly easy to port.
Depends on what you need. Software compatibility is mostly good, as long as it doesn't have a dependency on systemd or some other Linux-specific feature. Driver support varies, but FreeBSD in particular is pretty decent there.
FreeBSD has a Linux compatibility feature that lets you run native Linux binaries. I've never used it so I can't say how good it is, though - all the stuff I use runs fine natively.
The major BSDs have decent package management and sizeable repositories, with the option to build software (and customize compile-time options) using the ports or pkgsrc systems. You can also rebuild and customize the kernel and base system (aka "make world") but that's strictly optional these days.
I seem to remember there was some GNOME stuff that had a hard systemd dependency and wouldn't run on the BSDs. That was a while back though and I don't run GNOME so I don't know whatever happened there or what the status is.
Do they run Wine?
Not sure about NetBSD - but FreeBSD does WINE really well.
Details:
- https://vermaden.wordpress.com/2020/10/14/oldschool-gaming-o...
FreeBSD does, but I haven't tried it. It has its own chapter in the handbook. No idea about the others. I rarely need to run Windows binaries so I'm not the best person to ask.
NetBSD 11 with Firefox 151 from pkgsrc on a custom CTWM is a usable daily driver for Emacs daemon mode GUI/TUI and console tmux simultaneous use. Remote in from a Windows or macOS desktop.
CTWM Claude's Tab Window Manager
- https://www.ctwm.org/index.html
that's one confusing title in $currentyear...
It took me one serious doubletake ...
The cross build tooling, specifically around build.sh, makes the process of building a kernel + userland straight forward.
Use your best build hardware to build for your test hardware.
Please define what "Linux applications" is first.
I wonder if the popularity of NetBSD for research has to do with how easy it is to compile a version of NetBSD with favorable licenses.
You can opt to build it yourself and exclude anything that is not 2-clause BSD licensed, as some drivers and such are if I recall correctly.
Makes me wonder - in the year of Astra and Fable what prevents people from building bespoke BSDs for their hardware rapidly now?
What kind of customizations would you want that requires that degree of change?
Wifi drivers, display drivers, maybe graphics drivers...
The problem with missing drivers is not "typing code fast enough", it is knowing that you need to poke 5 into [base-address + $0562] within 5 milliseconds of receiving an IRQ or something stupid like that which good docs would tell you why and how, but most/many vendors will not hand out docs on how to program their chips at that level. They will have docs on how to paint rectangles on an existing surface using the gfx card, but not on how to actually start it at poweron or something along those lines. If you can't make it start painting a screen and waking up the monitor at boot, it is of very little use that you can paint rectangles in the dark.
So even if you can divine that a binary windows driver sometimes writes a 5 into that register at certain times, you will have a far harder time figuring out how and when it is needed to actually do that, and the source you get will be super hard for anyone else to understand if its all magic numbers getting written into "random" locations, compared to say, "wificard.driver.radio_enable = ACTIVATE_RADIO;" even if it compiles into writing 5 to offset $0562. Such reverse-engineered sources are super hard to keep working in the long run, when someone rewrites how and when IRQs are delivered to devices or whatever major is happening in the kernels so this leads to drivers no longer working even if they did have a short period of use.
If we had:
- A standard driver API with some traction.
- Drivers running in userspace.
It would not be the problem it is.
Time for donation. Thanks for the reminder.
Some real copium lmao ;)