Just to clarify, Bash is installed under /usr/local because it’s from packages and not part of the base system.

The base shell, ksh, is at /bin/ksh.

You probably know that but I just felt like being pedantic this morning :).

...and that ksh descended from pdksh, and is distributed as the oksh portable project here:

https://github.com/ibara/oksh

The MirBSD Korn Shell also descended from pdksh, and it can be found here:

http://www.mirbsd.org/mksh.htm

I don't know about the feature differences and code quality between these two; they both implement most of ksh88, and a small amount of ksh93.

I prefer mksh when I need something more than a POSIX shell.

Yes, absolutely true. The idea is that `ksh` is good enough, and the extra features of bash are extraneous or unnecessary, making it an add-on rather than a core feature.

It's an interesting idea, and while I feel bash is absolutely 'good enough' to be part of the base system, I wouldn't want zsh or fish part of my base system - so it's then a matter of opinion whose shell is bloat and whose is essential. So I respect their decision to not include bash in the base image - it's meant to be uncompromisingly lean and simple.

Another issue is size. This is what I see on CentOS:

    $ ls -l /bin/bash /bin/dash /bin/mksh
    -rwxr-xr-x. 1 root root 964536 Nov 22  2019 /bin/bash
    -rwxr-xr-x. 1 root root 113536 Nov  5  2018 /bin/dash
    -rwxr-xr-x. 1 root root 296192 Jan 27  2018 /bin/mksh

The Debian Almquist shell has nearly nothing beyond POSIX (I believe that local function variables are the only extension). This is the Ubuntu system shell, and it tolerates no bashisms. Alternate POSIX shell implementations in OCaml (and somewhat ADA) accuse Almquist of not using formal grammars and imply that dash is not a safe implementation.

https://www.irif.fr/_media/rencontres/pps2018/regis-gianas.p...

I would say that mksh implements 80% of bash functionality in much less space, and closely follows ksh88; mksh is also licensed such that Android uses it as /bin/sh.

Apple has switched from bash to zsh. I don't know the motivations for this, but preferences for shells wax and wane. BSD doesn't include bash (in base) more because of license than code quality.

POSIX seems to be all that we can agree on, but I do wish that standard could grow; it's stuck in the '70s.

Apple avoids GPLv3-licensed software, which may explain why they continue to ship an older version of bash (3.2, the last GPLv2 version). Eventually they must have decided that was too outdated to keep as the default shell and switched to zsh, which has an MIT-derived license.

> Apple has switched from bash to zsh. I don't know the motivations for this

GPLv3 vs BSD or MIT license. I lived zsh anyway, switched some of my BSD shells to it afterwards.

I love zsh but it’s history doesn’t segregate based on the tty and it locks up a lot during autocompletion for me (on Ubuntu.)

I'm using it without any plugins and disabled autocompletion anyway, because it just gets in the way irrespective of the shell. Like not completing tar filenames if it doesn't like the extension (tar axvf) even if the file is there. Modren distributions 'helpfully' enable completion by default.

I don't like the fact that you have no way to clear the history buffer if you've accidentally dropped a password at the prompt. Bash has history -c. I don't have shared history enabled, you could unset that and it'll stop segregating.

Anyway, zsh is a lot more versatile and familiar than tcsh for instance, so it's almost always my go to shell on FreeBSD as /bin/sh is quite limited, but also miles ahead of the Debian shell regarding features.

This is not typically the default setting in zsh (it is if it’s acting like ksh.) Your distributor has probably “helpfully” set it up this way. man zshoptions and look for “SHARE_HISTORY”.

It's Ubuntu 18.04 with Oh My Zsh

And that would make me switch from Linux why exactly?

Don't get me wrong, I was a BSD user for many years (FreeBSD 3.5-5.0) but I don't think that's enough reason to switch.

Reason for my switch was that some key things (for me) were designed in a way that seemed more right that on linux and this is totally subjective opinion.

I am still running ubuntu on laptop and will switch when the next install is a thing, but I am running freebsd on server for years now and while i tremble on each update for the laptop, I dont for freebsd, even when updating from 12.x to 13.x.

Based on years of experience on both operating systems. I was surprised only once when freebsd made change where the base network settings weren't by default copied into fibs (you wont encounter this... probably ever) and even then I needed an hour to figure what the change was.

On the other side, I no longer count the nasty surprises the linux distributions played on me (like /etc/resolv.conf being overwritten by systemd resolv, just as trivial change). My laptop is unbootable for a year as they messed something regarding the order of zpool import (bpool being imported before rpool - probably a race condition) so i have to import it manually or it doesnt boot, while I have freebsd zfs root for ~10 years and it never failed me.

Details like that made me insecure about linux. And on the other side, made me highly secure about freebsd.

I think that (again, this is subjective, speaking only for myself)...

I... trust... BSD... guys. Based on experience.

I... dont trust linux... distributions. Based on experience.

But it might just be me.

Not to be that guy, but your Linux complaints sound like systemd complaints.

Not sure the teething process has finished there, but I share the sentiment.

Naah, systemd is not bothering me at all, i dont have issues if they change the way how resolve information is stored.

What bothers me that the old way is still there (/etc/resolv.conf) while it is being generated by systemd. I can accept the change where the dns information is stored. Fine, it is no longer the same file, I dont care. While on the other side, if I get parallel mechanism, that is keeping the old, this is really an annoyance. That is hard to identify.

The ZFS has nothing to do with systemd and I havent even touched stuff like jails/lxc, byhve/kvm, memory consumption, quality of code,... as I have said it, it is subjective and it is about trust into operating system. Linux distributions dont have it. They blew it just too many times. BSD didnt.

It is hard to be objective there, just try the BSD. And please do report your findings.

It made me switch from Linux.

If it doesn't sound compelling to you, that's okay too, Linux is great. But I do think focusing on the consistency of design really is the best high-level summary of the difference between Linux and OpenBSD.

Consistency is great, but there's no equivalent to NixOS for the BSDs -- that I know of.

Am I actually wrong about that? Is there some declarative configuration system I should be using, which I've simply never heard of?

There are a couple issues tracking FreeBSD support for Nix [0,1], the package manager indicating it works there. Depending on the level of integration you want that might be sufficient, that would already be enough to generate the system config files for example, but to get the sort of integration you get on NixOS with different generations and the ability to rollback at boot would require more work. This would look something more like nix-darwin [2] than NixOS really.

I wouldn't be entirely surprised if OpenBSD works too, I might spin up a VM and see...

[0] https://github.com/NixOS/nix/issues/3280

[1] https://github.com/NixOS/nixpkgs/pull/81459

[2] https://github.com/LnL7/nix-darwin

I was actually looking into this as well. I recently switched my server to NixOS and the declarative configuration has been really nice to work with and fits easily into my workflow/tools (emacs with tramp).

I’d be really interested in seeing a variant on top of openbsd that has a comparable declarative layer. If anyone knows of such projects, please share!

I think we're talking about different definitions of consistency.

In the BSD context, consistancy is that human effort has been put in to get the userspace to look similar. Similar behavior of command line tools, similar documentation, similar configuration, etc.

It looks like you're talking about consistancy of packages across installs, which is a totally different issue.

No, that's the sort of consistency I was thinking of. I simply want that and all the niceties I'd get from NixOS.

Why is that "the way it's supposed to be," and how is it going to improve my user experience? It just seems like unnecessary complexity to me.

When things are consistent, less mental effort goes into remembering arbitrary differences.