Now the posix APIs feels like the worst of both worlds.
Most applications shouldn't really store data on the filesystem, and probably not even configuration. Most applications use a database for a zillion reasons (e.g. better backup, restore, consistency, replication, transactions, avoiding random writes, ...). Yet the filesystem is also not a great interface if you're building a database: you want more control over flushing and buffering and atomic file operations. The filesystem is mainly good at storing compiled code.
The "everything is a text file" interface is not great anymore, either. Simple manipulation of the output of basic commands (like text 'ps') requires error-prone parsing and quite some skill with things like grep, sed, awk, sort, etc. That's OK for experienced sysadmins working on individual machines, but doesn't integrate very well in larger systems where you have lots of automated access to that information. I have some experience doing sysadmin-like work, but I still run into problems with simple things like spaces in filenames and getting the quoting and escaping right in a regex. One option is for it to be more database-like, but that's not the only option. Erlang provides nice programmatic access to processes and other system information while still feeling very free and ad-hoc.
Of course, Linux is still great in many ways. But it feels like some of the core posix APIs and interfaces just aren't a great fit, and a lot of the interesting stuff is happening in non-posix APIs. And applications/services are being built on higher-level abstractions that aren't tied to single machines.
I think, like anything, it depends on what you're doing, and how you're doing it.
> The "everything is a text file" interface is not great anymore, either.
Text doesn't seem markedly different from a JSON API? Perhaps "worse is better" more often when you are composing several programs/apps to make one system? Even complex distributed systems.
> But it feels like some of the core posix APIs and interfaces just aren't a great fit
And I think these APIs can thrive on top of (the good parts of) POSIX. I'm not so certain we need to fundamentally rethink this layer, because this layer seems to work pretty well at what it does well. It should be pruned occasionally, but I'm not sure we need a whole new abstraction.
FWIW, I think this what the article is saying. Let's create some new interfaces where the old interfaces don't model the hardware well[0].
Json would be terrible as a primitive.
I was imagining something more like erlang, which is very OS-like. The types are very permissive/fleixble, and there's lots of ways to transform and manipulate results or feed it into something else without feeling code-heavy. It still feels comfortable to do ad-hoc stuff. The advantage is that in erlang you usually don't worry about basic stuff like record and field separators.
"Perhaps "worse is better" more often when you are composing several programs/apps to make one system?"
That's probably true as you zoom out. But even basic utilities in posix within the same system require a bunch of parsing. Imagine if a function call in a programming language required an intermediate text format. That's how unix feels sometimes.