6 ms·

This weekend I started digging into OpenBSD. I'd never used a BSD - been a Linux user for the past decade. While the table linked might show OpenBSD as the "lea

This weekend I started digging into OpenBSD. I'd never used a BSD - been a Linux user for the past decade. While the table linked might show OpenBSD as the "least complete", what seems to be the case is that they pick one tool to fit a use case and then use that one. There aren't 400 different shells installed by default or 5 different process monitoring/inspection programs, because they have the one they like and use/improve upon it. OpenBSD is a fascinating operating system. I'm only a few chapters into Absolute OpenBSD (https://en.wikipedia.org/wiki/Absolute_OpenBSD https://en.wikipedia.org/wiki/Absolute_OpenBSD) by Michael W. Lucas, but from a Linux user/admin perspective it is enthralling. I can't wait to learn more about it.

Enginerrrd 7y ago
The systemd debacle is what led me down a rabbit hole toward the BSD's. Don't get me wrong, systemd actually adds a lot of needed functionality, but I really feel like it is a major philosophical branch away from the conventional Unix thinking of 'make a tool that does one thing really well'. That mindset has such a strength in that such tools form reliable building blocks for other tools and system components in a way that is really approachable for amateur/volunteer developers. It takes no time to parse through the man page of a simple tool. And only a bit longer to parse the code. That makes it easy to build improvements, or build on top of it. But trying to wrap your head around systemd in even a few hours isn't reasonable. And binary log files? Wtf. It also seems like relying on certain aspects of it's behavior is a good way to end up breaking your system. BSD still has that old school Unix mindset that made Linux great in the first place. Especially up against Microsoft's products. The proof in the pudding for me is to look at the running processes of a default system between BSD and Linux with systemd. Yikes.
- dreich 7y ago
  > The systemd debacle is what led me down a rabbit hole toward the BSD's. Like most, you could have simply moved to a distribution without systemd. Unlike Linux, the BSDs offer less choice when it comes to both init, service supervision and service management options. It is also evidenced in the comparison table in the OP. If anything the debacle resulted in creating more awareness and leaving people open to more choice. That said, adopting one monolith instead of another sounds more like a knee jerk reaction than anything else. > The proof in the pudding for me is to look at the running processes of a default system between BSD and Linux with systemd. Yikes. This only scratches the surface. Daemons running under systemd have their PIDs supervised instead of using unreliable hacks like pidfiles. This is one of the reasons why systemd is preferred in large deployments and professional environments.
  - jimktrains2 7y ago
    BSDs aren't a "monolith", but the system and tools are developed together and parts can be replaced wholesale if you choose to do so. Also, there's what, Gentoo and GUIX that don't use systemd? Gentoo still prefers building all source on the system which is a non-starter for most, and GUIX I didn't think was ready for a daily-driver role yet.
    - jonathonf 7y ago
      Devuan [1] and MX Linux [2] (Debian-like), Artix (Arch-like) [3], and Void [4] are four other systemd-free distros off the top of my head. There will be others. [1] https://devuan.org/ https://devuan.org/ [2] https://mxlinux.org https://mxlinux.org [3] https://artixlinux.org/ https://artixlinux.org/ [4] https://voidlinux.org/ https://voidlinux.org/
      - pmoriarty 7y ago
        On Gentoo one is not forced to use systemd. I myself run a Gentoo system without systemd, and it works great.
    - xouse 7y ago
      https://nosystemd.org/ https://nosystemd.org/ The most popular non-systemd distro I hear about is Void linux, which is a rolling release style distro that's pretty comparable to(though not based on) Arch. As a tangent because you brought up distro's and difficulty, I know Arch has a reputation with some as being too difficult for regular skilled users, but as a regular skill level user myself, I find that the Arch/Void style rolling release paradigm of doing stuff makes things easier for noobs like me, not harder. Once you get past the initial hurdle that is the first hour or two of install and setup(which you can do just by copying youtube tutorial instructions line by line) then everything after that is much simpler. For me, I find that the majority of everyday linux problems all boil down to trying to install or update some kind of software. Either software you already have has a bugfix or feature you want in the newest update, or you have some new software you want to install. And because developers like new shiny things, often times the newest version of whatever has a dependency of some other new shiny thing. Installing new software in a fixed release distro often quickly gets too hairy for me, but in Arch I can almost always a simple install directly from the main or user repositories. This has so far eliminated 95% of everyday problems for me defying the usual narrative I hear of it being "harder" to use for normal Joe's like me.
- ti_ranger 7y ago
  > The systemd debacle is what led me down a rabbit hole toward the BSD's. As far as I can tell (not actually using Debian or Ubuntu myself), there was only a debacle in Debian and Ubuntu, because they took too long to decide, and ended up having to rush their migration. All the other distros, that had better-planned migrations (Arch, Fedora, SUSE, etc. etc. etc.) had basically no issues migrating to systemd, and have benefited immensely from being able to ditch the maintenance overhead of diverging init systems and init scripts, all re-implementing the same new features with slightly different implementations due to previous slightly differing implementation details. People will currently call out OpenRC as the one non-systemd approach that works (e.g. if you acknowledge that SysvInit no longer actually works because no-one uses if for all system initialisation, instead leting it delegate lots of control to other bits and pieces), but before systemd won, there were: * SysVinit + RH-derived initscripts * Sysvinit + SUSE-style initscripts * Upstart * OpenRC * prcsys - parallel rc system (Mandrake and derivatives) All of these had similarities, and small differences, e.g. they all tried to support dependency information in init script headers. As a sysadmin, it was frustrating to: * Have to read every init script to see where it read its defaults from, was it /etc/sysconfig/pkgname or /etc/default/daemonname . Did it support setting limits from the defaults file, or would you have to hack the script to support your bigger-than-the-maintainer-imagined environment. * Debug where the application was logging to, if it didn't setup logging correctly by default. As a maintainer of a package used on more than one distro, it was difficult to: * Test your init script to ensure it worked on RH-based distros and SUSE and Debian and Ubuntu. While Upstart said it supports init scripts, it fails in some random way that doesn't occur on RH and SUSE. * Setup logging correctly, as not all distros provided a helper script to setup the right logging daemon (syslogd, vs rsyslog vs syslog-ng etc.) We won't talk about the more modern features such as cgroups etc., where only about 2 init systems support the feature adequately, and no distro or packager actually managed to support such advanced features on more than one init system, and certainly not more than one non-systemd system. systemd mainly stays out of my way, but makes it easy to troubleshoot and customise daemon behaviour in a consistent fashion. > But trying to wrap your head around systemd in even a few hours isn't reasonable. You don't need to wrap your head around systemd to do things with it that you would really struggle to do with any other init system. But, you've probably been too busy fighting it, or trying to prove why it's worse, rather than trying to do real things with it, or you would be able to point to valid bug reports. > The proof in the pudding for me is to look at the running processes of a default system between BSD and Linux with systemd. Yikes. You're comparing apples and oranges here, you should rather be comparing two release of the same distro, before and after systemd became the default, and you would have seen very little difference.
moviuro 7y ago
BTW, there is currently (until Nov. 18th 2019) a sale of BSD & Linux ebooks at humblebundle[0] Absolute OpenBSD and Absolute FreeBSD are in that bundle. [0] https://humblebundle.com/books/linux-bsd-bookshelf-2019-books https://humblebundle.com/books/linux-bsd-bookshelf-2019-book...
- codetrotter 7y ago
  Humble Bundle used to make it possible to select which charity you wanted to give to, and I used to select the FreeBSD Foundation and give them the whole amount. But I can't figure out how to do custom selection of charity any longer. Does anyone know?
  - jmhobbs 7y ago
    edit I missed the "custom" part of your comment. I don't remember that ever being a thing, but I never got particularly detailed with moving the levers around before. It's in a collapsed section titled "Choose where your money goes" which is beneath the price selection tools now. [1] https://pasteboard.co/IF9gtLR.png https://pasteboard.co/IF9gtLR.png
    - codetrotter 7y ago
      The section in your screenshot is for the charities, but it used to be that instead of the pre-selected charities you could choose another one from a huge list of charities and that one included the FreeBSD Foundation. And that's what I'm wondering about, if anyone knows if that is still possible.
  - kick 7y ago
    Humble Bundle is under new ownership (IGN), now, so I wouldn't be surprised if they took that away.
- elagost 7y ago
  That is what prompted me, actually! My coworker alerted me to this sale and I jumped on it. Something about Absolute OpenBSD spoke to me, and I had to pick it up first... maybe it's the "Practical Paranoid" part.
drivers99 7y ago
I see it's available in Safari Books (for those who have a subscription.) Wikipedia says, "the second edition was released in April 2013." Looks like that's just before version 5.3 came out, and there have been 13 releases since then. However, there are mostly 5 star reviews on Amazon, including ones from 2019, so it sounds like it's still worth reading.

Enginerrrd 7y ago

The systemd debacle is what led me down a rabbit hole toward the BSD's. Don't get me wrong, systemd actually adds a lot of needed functionality, but I really feel like it is a major philosophical branch away from the conventional Unix thinking of 'make a tool that does one thing really well'. That mindset has such a strength in that such tools form reliable building blocks for other tools and system components in a way that is really approachable for amateur/volunteer developers. It takes no time to parse through the man page of a simple tool. And only a bit longer to parse the code. That makes it easy to build improvements, or build on top of it. But trying to wrap your head around systemd in even a few hours isn't reasonable. And binary log files? Wtf. It also seems like relying on certain aspects of it's behavior is a good way to end up breaking your system. BSD still has that old school Unix mindset that made Linux great in the first place. Especially up against Microsoft's products. The proof in the pudding for me is to look at the running processes of a default system between BSD and Linux with systemd. Yikes.

dreich 7y ago
> The systemd debacle is what led me down a rabbit hole toward the BSD's. Like most, you could have simply moved to a distribution without systemd. Unlike Linux, the BSDs offer less choice when it comes to both init, service supervision and service management options. It is also evidenced in the comparison table in the OP. If anything the debacle resulted in creating more awareness and leaving people open to more choice. That said, adopting one monolith instead of another sounds more like a knee jerk reaction than anything else. > The proof in the pudding for me is to look at the running processes of a default system between BSD and Linux with systemd. Yikes. This only scratches the surface. Daemons running under systemd have their PIDs supervised instead of using unreliable hacks like pidfiles. This is one of the reasons why systemd is preferred in large deployments and professional environments.
- jimktrains2 7y ago
  BSDs aren't a "monolith", but the system and tools are developed together and parts can be replaced wholesale if you choose to do so. Also, there's what, Gentoo and GUIX that don't use systemd? Gentoo still prefers building all source on the system which is a non-starter for most, and GUIX I didn't think was ready for a daily-driver role yet.
  - jonathonf 7y ago
    Devuan [1] and MX Linux [2] (Debian-like), Artix (Arch-like) [3], and Void [4] are four other systemd-free distros off the top of my head. There will be others. [1] https://devuan.org/ https://devuan.org/ [2] https://mxlinux.org https://mxlinux.org [3] https://artixlinux.org/ https://artixlinux.org/ [4] https://voidlinux.org/ https://voidlinux.org/
    - pmoriarty 7y ago
      On Gentoo one is not forced to use systemd. I myself run a Gentoo system without systemd, and it works great.
  - xouse 7y ago
    https://nosystemd.org/ https://nosystemd.org/ The most popular non-systemd distro I hear about is Void linux, which is a rolling release style distro that's pretty comparable to(though not based on) Arch. As a tangent because you brought up distro's and difficulty, I know Arch has a reputation with some as being too difficult for regular skilled users, but as a regular skill level user myself, I find that the Arch/Void style rolling release paradigm of doing stuff makes things easier for noobs like me, not harder. Once you get past the initial hurdle that is the first hour or two of install and setup(which you can do just by copying youtube tutorial instructions line by line) then everything after that is much simpler. For me, I find that the majority of everyday linux problems all boil down to trying to install or update some kind of software. Either software you already have has a bugfix or feature you want in the newest update, or you have some new software you want to install. And because developers like new shiny things, often times the newest version of whatever has a dependency of some other new shiny thing. Installing new software in a fixed release distro often quickly gets too hairy for me, but in Arch I can almost always a simple install directly from the main or user repositories. This has so far eliminated 95% of everyday problems for me defying the usual narrative I hear of it being "harder" to use for normal Joe's like me.
ti_ranger 7y ago
> The systemd debacle is what led me down a rabbit hole toward the BSD's. As far as I can tell (not actually using Debian or Ubuntu myself), there was only a debacle in Debian and Ubuntu, because they took too long to decide, and ended up having to rush their migration. All the other distros, that had better-planned migrations (Arch, Fedora, SUSE, etc. etc. etc.) had basically no issues migrating to systemd, and have benefited immensely from being able to ditch the maintenance overhead of diverging init systems and init scripts, all re-implementing the same new features with slightly different implementations due to previous slightly differing implementation details. People will currently call out OpenRC as the one non-systemd approach that works (e.g. if you acknowledge that SysvInit no longer actually works because no-one uses if for all system initialisation, instead leting it delegate lots of control to other bits and pieces), but before systemd won, there were: * SysVinit + RH-derived initscripts * Sysvinit + SUSE-style initscripts * Upstart * OpenRC * prcsys - parallel rc system (Mandrake and derivatives) All of these had similarities, and small differences, e.g. they all tried to support dependency information in init script headers. As a sysadmin, it was frustrating to: * Have to read every init script to see where it read its defaults from, was it /etc/sysconfig/pkgname or /etc/default/daemonname . Did it support setting limits from the defaults file, or would you have to hack the script to support your bigger-than-the-maintainer-imagined environment. * Debug where the application was logging to, if it didn't setup logging correctly by default. As a maintainer of a package used on more than one distro, it was difficult to: * Test your init script to ensure it worked on RH-based distros and SUSE and Debian and Ubuntu. While Upstart said it supports init scripts, it fails in some random way that doesn't occur on RH and SUSE. * Setup logging correctly, as not all distros provided a helper script to setup the right logging daemon (syslogd, vs rsyslog vs syslog-ng etc.) We won't talk about the more modern features such as cgroups etc., where only about 2 init systems support the feature adequately, and no distro or packager actually managed to support such advanced features on more than one init system, and certainly not more than one non-systemd system. systemd mainly stays out of my way, but makes it easy to troubleshoot and customise daemon behaviour in a consistent fashion. > But trying to wrap your head around systemd in even a few hours isn't reasonable. You don't need to wrap your head around systemd to do things with it that you would really struggle to do with any other init system. But, you've probably been too busy fighting it, or trying to prove why it's worse, rather than trying to do real things with it, or you would be able to point to valid bug reports. > The proof in the pudding for me is to look at the running processes of a default system between BSD and Linux with systemd. Yikes. You're comparing apples and oranges here, you should rather be comparing two release of the same distro, before and after systemd became the default, and you would have seen very little difference.

moviuro 7y ago

BTW, there is currently (until Nov. 18th 2019) a sale of BSD & Linux ebooks at humblebundle[0] Absolute OpenBSD and Absolute FreeBSD are in that bundle. [0] https://humblebundle.com/books/linux-bsd-bookshelf-2019-books https://humblebundle.com/books/linux-bsd-bookshelf-2019-book...

codetrotter 7y ago
Humble Bundle used to make it possible to select which charity you wanted to give to, and I used to select the FreeBSD Foundation and give them the whole amount. But I can't figure out how to do custom selection of charity any longer. Does anyone know?
- jmhobbs 7y ago
  edit I missed the "custom" part of your comment. I don't remember that ever being a thing, but I never got particularly detailed with moving the levers around before. It's in a collapsed section titled "Choose where your money goes" which is beneath the price selection tools now. [1] https://pasteboard.co/IF9gtLR.png https://pasteboard.co/IF9gtLR.png
  - codetrotter 7y ago
    The section in your screenshot is for the charities, but it used to be that instead of the pre-selected charities you could choose another one from a huge list of charities and that one included the FreeBSD Foundation. And that's what I'm wondering about, if anyone knows if that is still possible.
- kick 7y ago
  Humble Bundle is under new ownership (IGN), now, so I wouldn't be surprised if they took that away.
elagost 7y ago
That is what prompted me, actually! My coworker alerted me to this sale and I jumped on it. Something about Absolute OpenBSD spoke to me, and I had to pick it up first... maybe it's the "Practical Paranoid" part.

drivers99 7y ago

I see it's available in Safari Books (for those who have a subscription.) Wikipedia says, "the second edition was released in April 2013." Looks like that's just before version 5.3 came out, and there have been 13 releases since then. However, there are mostly 5 star reviews on Amazon, including ones from 2019, so it sounds like it's still worth reading.