5 ms·

So, the article seems to be mostly about desktop usage, but for me, the best way to show off OpenBSD is to just run `ps ax` after a clean install, and compare t

So, the article seems to be mostly about desktop usage, but for me, the best way to show off OpenBSD is to just run `ps ax` after a clean install, and compare that to, say, Fedora CoreOS (just because that happens to be the other common OS I use for my server VMs). On OpenBSD, the list of processes is mercifully short, and I can tell you what each of them is supposed to do. CoreOS? Not so much -- and, yeah, I know, I could of course switch to non-systemd-infested distro, but even there, there would be at least a screen-full of processes of which I could maybe identify half? This pattern extends to configuration: OpenBSD has a handful of very-well-documented files in /etc, whereas under Linux, things are literally all over the place, and you might even end up editing irrelevant configs, because they happen to be regenerated by yet-another-layer of tooling, or your distro is simply not using the tool you think you're configuring... Still, I have no clear preference for one OS over the other! With workloads being mostly containerized these days, it's so easy to roll out a new VM, that the level of understanding required to, say, nurse a broken OS on physical hardware back to health, is now simply irrelevant. Just blow away the old and deploy the new, and forget about it. On OpenBSD, the deployment tooling uses tried-and-true commands like `fdisk` and `ifconfig`, whereas for CoreOS it's YAML (pronounced: 'hell'), but the truth is... it doesn't matter that much. Getting the base OS installed, adding some volumes, creating sub-interfaces for the relevant VLANs, installing Docker(-compose), and getting the containers to (re)start is all very, very similar. So, yeah, I sort-of get what the article is trying to say, but the ground-truth I think is that in most cases the OS isn't that much of a differentiator anymore, as they're pretty much all OK-ish...

ruthmarx 2y ago
> On OpenBSD, the list of processes is mercifully short, and I can tell you what each of them is supposed to do. I've always appreciated a very minimal system, but nowadays Alpine Linux is much better for that IMO. I'm not sure there's a better alternative if minimalism is the goal.
viraptor 2y ago
> On OpenBSD, the list of processes is mercifully short, and I can tell you what each of them is supposed to do. CoreOS? Not so much Have you got the actual outputs to compare?
- PreInternet01 2y ago
  Sure, why not: https://openbsd-ps-vs-coreos.tiiny.site/ https://openbsd-ps-vs-coreos.tiiny.site/ In fact, OpenBSD has gotten a lot more verbose over the years, due to sub-processes being listed explicitly. Good example here is `smtpd`, but even then, the difference with Linux remains... stark.
  - olddustytrail 2y ago
    That's because Linux is showing you the kernel processes and OpenBSD isn't. Filter out the Linux ones that have [ ] around them (grep -v ]$ will do the trick) but just a quick glance tells me the Linux and BSD lists are about the same length.
    - PreInternet01 2y ago
      Counterpoint: possibly OpenBSD doesn't really have any relevant 'kernel processes' (in line with the model: the kernel is there to serve user-mode, and not a goal on its own). (And tangentially: why do I need multiple `psimon` kernel processes? Tire pressure is good to keep in mind, I guess, but, at the kernel level? Repeatedly?). I truly don't know, by the way; this was merely an example to illustrate my perceived difference-in-complexity between Linux and OpenBSD, which might be entirely misguided, but definitely part of the issue the article linked in the submission hints at?
      - viraptor 2y ago
        > possibly OpenBSD doesn't really have any relevant 'kernel processes' It does. They're just hidden from the listing. https://github.com/search?q=repo%3Aopenbsd%2Fsrc%20kthread_create&type=code https://github.com/search?q=repo%3Aopenbsd%2Fsrc%20kthread_c... > why do I need multiple `psimon` kernel processes? It's the way that module is organised. There's nothing wrong with the idea, you'd need to dive into the code to understand the details. > illustrate my perceived difference-in-complexity It depends on the situation. Seeing many kernel threads is one kind of complex. Not seeing the kernel threads and not being able to understand which one is having issues is another kind of complex. You just saw how the sausage is made, but that has nothing to do with the final taste / how the system actually behaves.
jmclnx 2y ago
Just compare he results of mount(8) between Linux and OpenBSD, another eye-opener. Linux has a lot of in memory file-systems that I do not know what they are all for :)
- NekkoDroid 2y ago
  > Linux has a lot of in memory file-systems that I do not know what they are all for :) Which ones for example? I wanna know if you know some I might still not know of.
  - jmclnx 2y ago
    I left it as it defaults, but here is a comparison between OpenBSD and my Linux workstation. Linux mount is separated between the physical and the memory mounts. The only memory mount I added as for /tmp OpenBSD: ======== /dev/sd1a on / type ffs (local) /dev/sd1h on /home type ffs (local, nodev, nosuid) /dev/sd1d on /tmp type ffs (local, nodev, nosuid) /dev/sd1i on /u type ffs (local, nodev, nosuid) /dev/sd1f on /usr type ffs (local, nodev) /dev/sd1g on /usr/local type ffs (local, nodev, wxallowed) /dev/sd1e on /var type ffs (local, nodev, nosuid) Linux: ====== /dev/sda1 on /boot type ext4 (rw,noatime,stripe=4) /dev/mapper/cryptvg-home on /home type ext4 (rw,noatime) /dev/mapper/cryptvg-u on /u type ext4 (rw,noatime) /dev/mapper/lukssdb1 on /u1 type ext4 (rw,noatime) /dev/mapper/lukssdb2 on /u2 type ext4 (rw,noatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=4194304k,inode64) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=32768k,mode=755,inode64) devtmpfs on /dev type devtmpfs (rw,relatime,size=8192k,nr_inodes=1995831,mode=755,inode64) /dev/mapper/cryptvg-root on / type ext4 (rw,noatime) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,inode64) cgroup_root on /sys/fs/cgroup type tmpfs (rw,relatime,size=8192k,mode=755,inode64) cpuset on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset) cpu on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu) cpuacct on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct) blkio on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio) memory on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory) devices on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices) freezer on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer) net_cls on /sys/fs/cgroup/net_cls type cgroup (rw,relatime,net_cls) perf_event on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event) net_prio on /sys/fs/cgroup/net_prio type cgroup (rw,relatime,net_prio) pids on /sys/fs/cgroup/pids type cgroup (rw,relatime,pids) misc on /sys/fs/cgroup/misc type cgroup (rw,relatime,misc) cgroup on /sys/fs/cgroup/elogind type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib64/elogind/elogind-cgroups-agent,name=elogind) tmpfs on /run/user/1001 type tmpfs (rw,nosuid,nodev,relatime,size=1598624k,nr_inodes=399656,mode=700,uid=1001,gid=1001,inode64)
JackSlateur 2y ago
Boarf I just checked on my home server (Debian), running ps auxf, the only three userspace processes I did not install was udevd, uuidd and getty The rest is my workload (nginx, random docker shit, postfix etc)

ruthmarx 2y ago

> On OpenBSD, the list of processes is mercifully short, and I can tell you what each of them is supposed to do. I've always appreciated a very minimal system, but nowadays Alpine Linux is much better for that IMO. I'm not sure there's a better alternative if minimalism is the goal.

viraptor 2y ago

> On OpenBSD, the list of processes is mercifully short, and I can tell you what each of them is supposed to do. CoreOS? Not so much Have you got the actual outputs to compare?

PreInternet01 2y ago
Sure, why not: https://openbsd-ps-vs-coreos.tiiny.site/ https://openbsd-ps-vs-coreos.tiiny.site/ In fact, OpenBSD has gotten a lot more verbose over the years, due to sub-processes being listed explicitly. Good example here is `smtpd`, but even then, the difference with Linux remains... stark.
- olddustytrail 2y ago
  That's because Linux is showing you the kernel processes and OpenBSD isn't. Filter out the Linux ones that have [ ] around them (grep -v ]$ will do the trick) but just a quick glance tells me the Linux and BSD lists are about the same length.
  - PreInternet01 2y ago
    Counterpoint: possibly OpenBSD doesn't really have any relevant 'kernel processes' (in line with the model: the kernel is there to serve user-mode, and not a goal on its own). (And tangentially: why do I need multiple `psimon` kernel processes? Tire pressure is good to keep in mind, I guess, but, at the kernel level? Repeatedly?). I truly don't know, by the way; this was merely an example to illustrate my perceived difference-in-complexity between Linux and OpenBSD, which might be entirely misguided, but definitely part of the issue the article linked in the submission hints at?
    - viraptor 2y ago
      > possibly OpenBSD doesn't really have any relevant 'kernel processes' It does. They're just hidden from the listing. https://github.com/search?q=repo%3Aopenbsd%2Fsrc%20kthread_create&type=code https://github.com/search?q=repo%3Aopenbsd%2Fsrc%20kthread_c... > why do I need multiple `psimon` kernel processes? It's the way that module is organised. There's nothing wrong with the idea, you'd need to dive into the code to understand the details. > illustrate my perceived difference-in-complexity It depends on the situation. Seeing many kernel threads is one kind of complex. Not seeing the kernel threads and not being able to understand which one is having issues is another kind of complex. You just saw how the sausage is made, but that has nothing to do with the final taste / how the system actually behaves.

jmclnx 2y ago

Just compare he results of mount(8) between Linux and OpenBSD, another eye-opener. Linux has a lot of in memory file-systems that I do not know what they are all for :)

NekkoDroid 2y ago
> Linux has a lot of in memory file-systems that I do not know what they are all for :) Which ones for example? I wanna know if you know some I might still not know of.
- jmclnx 2y ago
  I left it as it defaults, but here is a comparison between OpenBSD and my Linux workstation. Linux mount is separated between the physical and the memory mounts. The only memory mount I added as for /tmp OpenBSD: ======== /dev/sd1a on / type ffs (local) /dev/sd1h on /home type ffs (local, nodev, nosuid) /dev/sd1d on /tmp type ffs (local, nodev, nosuid) /dev/sd1i on /u type ffs (local, nodev, nosuid) /dev/sd1f on /usr type ffs (local, nodev) /dev/sd1g on /usr/local type ffs (local, nodev, wxallowed) /dev/sd1e on /var type ffs (local, nodev, nosuid) Linux: ====== /dev/sda1 on /boot type ext4 (rw,noatime,stripe=4) /dev/mapper/cryptvg-home on /home type ext4 (rw,noatime) /dev/mapper/cryptvg-u on /u type ext4 (rw,noatime) /dev/mapper/lukssdb1 on /u1 type ext4 (rw,noatime) /dev/mapper/lukssdb2 on /u2 type ext4 (rw,noatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=4194304k,inode64) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=32768k,mode=755,inode64) devtmpfs on /dev type devtmpfs (rw,relatime,size=8192k,nr_inodes=1995831,mode=755,inode64) /dev/mapper/cryptvg-root on / type ext4 (rw,noatime) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,inode64) cgroup_root on /sys/fs/cgroup type tmpfs (rw,relatime,size=8192k,mode=755,inode64) cpuset on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset) cpu on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu) cpuacct on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct) blkio on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio) memory on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory) devices on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices) freezer on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer) net_cls on /sys/fs/cgroup/net_cls type cgroup (rw,relatime,net_cls) perf_event on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event) net_prio on /sys/fs/cgroup/net_prio type cgroup (rw,relatime,net_prio) pids on /sys/fs/cgroup/pids type cgroup (rw,relatime,pids) misc on /sys/fs/cgroup/misc type cgroup (rw,relatime,misc) cgroup on /sys/fs/cgroup/elogind type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib64/elogind/elogind-cgroups-agent,name=elogind) tmpfs on /run/user/1001 type tmpfs (rw,nosuid,nodev,relatime,size=1598624k,nr_inodes=399656,mode=700,uid=1001,gid=1001,inode64)

JackSlateur 2y ago

Boarf I just checked on my home server (Debian), running ps auxf, the only three userspace processes I did not install was udevd, uuidd and getty The rest is my workload (nginx, random docker shit, postfix etc)