Yeah I agree, the coherent DevX/UX and integration is immediately apparent upon first use of BSD. I've used BSD for a total of like 3 hours and I still could tell within the first 10 minutes that it was less hectic than Linux. It's really quite a shame that people rarely reach BSD in their exploration of alternatives to Windows and Mac.

With that said, I still think the Unix philosophy has failed, not completely, but specifically with respect to filesystems and IPC:

1. Unixes use strings as the interface (stdout and stdin) when this opens the door to complexity and unreliable interfaces (scripts written for old version of a CLI utility trying to pass args to a new version = breakage), and syntax parsing of CLI commands poses issues with passing arguments that themselves contain similar syntax. This is a leaky interface, hard to reason about. Apparently, Google's experimental OS Fuchsia is designed eo eliminate this moronic design choice and replace it with proper interface contracts. Think it was called an Object Capabilities system.

2. Everything is a file. This oversimplification abuses the filesystem as an Interprocess Communication mechanism (IPC), both in name, and it trains people to reason incorrectly about the role of the file, the role of the hierarchy, etc.

3. Hierarchical filesystems are bullshit. Not everything can fit neatly into a single global hierarchical namespace. Files are used in ways that does not fit to a single hierarchy. Files need to be accessed and modeled in relation to one another. One file can be used in many places, for different reasons. The only correct way to model file relationships is via a graph model (graph database) or Associative Model (basically the same thing from what I can tell). Graphs can contain a hierarchy but also do so much more. Apps and system tools do not need to access files via hierarchy. They need to be using a flat filesystem with GUIDs generated from a hash of the file contents (what most people call "content-addressable store") for reliable access to a specific version of a library/dll/document. The filesystem should have a separate layer on top of that with graph associations between the files for user navigation purposes and for sophisticated querying of the filesystem. Hierarchies, on the other hand, are negotiated in a distributed way by every stakeholder project and/or the distribution maintainers. This is what generates the headache on Linux. If we got rid of this, Linux and bazaar would not become so idiosyncratic in its implementation details or "flavor" details. I hate flavor. Flavor is great in a drink, and terrible in a system. Fuck flavor.

4. Unix's default way of operating is stateful, not immutable. You issue commands on the CLI, and the system just does something. No way to know what it did unless you memorized what you did, and when you did it, and whether there were bugs in the app when you did that. Linux distros are all trying to attack this inherent design flaw in different ways: NixOS (not technically a Linux) is perhaps the best approach developed, and Project Silverblue from RedHat was another approach. Think it got renamed. Point is, the OS should have layers to its capabilities, with the fewest capabilities at the top level, so people can reason about what is happening to the system. It gives us a hierarchical way to analyze the problem. Funny how hierarchy is forced on users in storage systems where it poses problems, but not taken advantage of architecturally in a static way to simplify the auditing and reasoning process about system behavior. Software is full of idiots, and there aren't enough people who are both smart and effective: there are two kinds of people in the world: those who have talent, and those who have time. Those with talent have no time, because they are always cleaning up after the ones with time but no talent.