It's time for these people to get off their high elephant and write or fund a substitute, instead of doing nothing and whinging constantly just for the sake of gathering imaginary internet points.
[1] Here's his first commit: https://cgit.freebsd.org/src/commit/?id=026e67b69b612f90360a... with the most recent happening within the last year.
edit: fixed link
Bad object id: 026e67b69b612f90360a3c7b35be16f34bffd0c6cThe author is writing in context of people who use code very differently than I do - they think about it differently too. Perhaps there are different types of API for their use cases that are less "fighting with the OS" for them, or more likely the tool makers that build the intermediate code/frameworks?
I am entirely in favor of domain-specific APIs that "make hard problems easier to solve". But it is important to recognize two things about this:
1. the "complex APIs" that are right for solving one set of hard problems are frequently not the right ones for a different set of hard problems.
2. POSIX never made any claim to universality in the domain of being the right API for a given problem class. As someone else noted here in the comments, it was a bunch of people & organizations simply agreeing on the low level stuff they could agree on.
I'd make one additional point: unless the plan is to reimplement the kernel for every problem domain, which seems pretty crazy, the actual situation faced by many/most real world programmers even in a better world is going to be "APIs we want to use layered on top of APIs we (mostly) don't want to use". This is necessarily so, because the APIs that make it possible to implement the APIs that whiners like the author of TFA want to use, along with the APIs that domain specialists want, are generally APIs like POSIX that people don't seem to warm to very strongly.
2. Sure, but that provided enough foundation for other ideas like epoll/kqueue to spread between OSes. It happened because everyone saw the strange non-posix thing (i think at Sun?) and made a similar system. Even though they aren't directly api compatible they were conceptually close enough, people ended up building nice layers on them (libuv, mio, etc). Maybe that would be enough.
Perhaps even, the right answer to several of the points raised is in fact io_uring like apis spreading to other OSes too, so that a reasonable cross platform abstraction layer can be built. Perhaps it's something different.
Perhaps is creating a new standard or a new posix version or addendum or whatever.
All of this aside, I'm not here to champion the specifics. I'm pointing out that it's a reasonable discussion to have, there's no need to be upset at someone for pointing it out.
But I've also written a whole lot of software which really couldn't care less about the OS. It needs some way to list directories, some way to read and write files, maybe some way to communicate over the network, but everything interesting happens in code that's not related to interacting with the OS. In those cases, I love that I can just write against one API and know that, if it doesn't already just work on all posixy systems, it's at least going to be easy to port.
What you often see are half-baked, trivial re-implementations of some parts of existing utilities and then the proclamation "Rust is here and it's so much better!".
A program that amounts to some undergrad's semester project isn't going to be taken seriously - and they often are not. The existing utilities are decades old, are very good at what they do, and rarely are the cause of the supposed bugs we're trying to avoid.
Shell replacements, such as OilShell, can gain traction on their own, because a shell is mostly system agnostic. The struggle here is reaching critical mass of users, while also supporting all of the millions of existing shell scripts out there in the wild.
No one is going to make your new wiz-bang shell the system default on a popular distro without it being completely compatible with existing shell scripts, documentation, examples, etc. It's just a non-starter...
False. zsh is not POSIX nor fully compatible with bash, while being default login shell in popular distros like Kali and Deepin (and macOS).
Not sure if Garuda Linux passes the "popular" threshold for you but their default is fish.
Shell scripts typically lead with a shebang, making your login shell inconsequential as long as you have the target shell available.
Kali is a purpose-built distro that is not a daily driver for nearly anyone.
Deepin is a Chinese distro, and while it may be popular to some, it is not a popular distro at large.
My point remains standing.
> Shell scripts typically lead with a shebang, making your login shell inconsequential as long as you have the target shell available.
Of course - but having multiple shells installed is not common. What's the point of using another shell if all of your scripts have to use bash anyway? You are still effectively using Bash, and have unintentionally exposed the problem with all non-POSIX compliant shells - they don't allow people to get work done.
Excuse me, how is that in any way relevant here? Fuck off with that.
> but having multiple shells installed is not common
False again. Run 'chsh' and tell me how many options you see.
What on earth are you talking about?
Deepin Technology is a wholly owned subsidiary of UnionTech, a Chinese company based in Wuhan China.
It is a Linux Distro developed in China for a domestic audience, ie. used predominantly in China by Chinese citizens. It is a Chinese Linux Distro...
It may be popular in China, but it is not globally popular. Very few people would willingly choose to run an operating system developed in China for domestic consumption, for very obvious reasons.
Pretend to be offended by something else...
> Run 'chsh' and tell me how many options you see.
Ya... only bash available on my system... a default installation of Rocky Linux.
Usually people try to ensure they're correct before saying someone is wrong.
RockyLinux as you know is a RHEL clone. RHEL is a very conservative distro, their original market was refugees from Solaris and other commercial UNIX distros. And I say that as a diehard fan of Redhat/Fedora minimal installation as both a server and development platform.
Other less commercial distros (Debian and deriviatives, Arch, Gentoo etc) tend to offer more shell options out of the box, as do most of the BSD's. And other options are not hard to install from the Redhat/Fedora repos as you would know.
rust itself is an example. The concepts it's based on predate it by decades. When it comes to safety it's not as good as other languages and yet...
Discussing these things earnestly and with considered and well reasoned inspection of what is, and why it is, and what could be… all of that is doing something. Maybe quite a lot in fact. Certainly it’s doing more than efforts like this, to quash or interrupt that public sharing of thought process.
“Doing” is an incredibly broad category of action. But it very seldom includes categorically dismissing ideas on the basis they haven’t already produced some other more concrete deliverable.
For everyone one person who posts one of these, there are 100 people cheering them on, and 10000 developers in the real world who just learnt to deal with POSIX and its warts years ago, just want a paycheck, and will wait until a better API gains traction in the real world before they go asking their employer to bet the farm on it.
Speaking as a working data scientist, even well-structured data usually needs heavy manipulation before it's suitable for use, and modern datasets absolutely do not fit into the system memory of a typical workstation. Secondary storage is now just an nvme cache for what we might as well call "tertiary storage," which is in the cloud, and just as unreliable as the old pallet full of tapes (not because the vendor is screwing up, but because there's a lot of network between here and there).
The problems haven't meaningfully changed in practice, they've just sort of shifted around so that different ones loom large. Unless you win the lottery and find a consistent, reliable source of clean data, POSIX isn't ever going to be the bottleneck.
EDIT: HN won't let me reply, so I'm editing this post in response to haunter's question below:
For the filesystem stuff, https://en.wikipedia.org/wiki/Files-11 and be sure to read the section about "Record Management Services" which sort of blurs the line between database and filesystem.
For resource sharing: https://en.wikipedia.org/wiki/VMScluster and remember that thanks to record-based file storage, locking can happen on the record level -- imagine instead of having to lock a whole JSON document for writing, you could lock just the key/value pair you were updating, and other programs could read/write the rest of the file safely!
Can you expand on that part? Sorry I’m not an expert but curious about this part of the OS history. Or is there an article (Wikipedia) about it?
For example VMS, there is an OpenVMS finally, but decades too late and still kept behind a gate, ensuring its demise.
Only mainframes survived from the previous era, probably due to their vastly different requirements and customers. Banks/govts for example, have no patience for "move fast and break things" and plenty of money to spare.
The "Worse is Better" piece describes the process from a design/implementation standpoint while the book the "Innovator's Dilemma" explains the process from an economics one.
There was no political will to standardize the layers above POSIX and the standards that attempted to do that are dead and buried (in some cases for good reasons).
20 years later there still isn't the political will towards standardization.
The original article is correct in that our programming models do need to be updated, but I think it's a stretch to blame it on POSIX.
That could exist right now.
But either you want think about the "plumbing" under the hood that makes that possible, or your don't. One way or another it has to be there. Even as hard as Apple has tried to pretend that their OS(es) don't have a BSD/POSIX/Mach kernel, most developers (certainly the ones who have to pay attention to cross-platform development) end up bumping into somewhere along the way.
> Secondary storage is now just an nvme cache for what we might as well call "tertiary storage," which is in the cloud
This might be true for some sort of computing, but it is absolutely not the general rule, and I would wager that it never will be. There's nothing you can do on the cloud that you cannot do on local storage except provide remote access more simply.
And I agree about the plumbing, but this is a discussion around the environment of primitives commonly available, and I'm merely pointing out that richer environments than posix have already failed out of the market once.
Don't know about VMS, but I've used "data-structured systems": old macs with resources forks, and Symbian with its databases.
Thank god they are gone.
I don't want to have to learn special archival tool just for one system. I want to be able to take any data file, and back it up, make a copy, send to a different system, encrypt, archive, checksum, rename, delete, compare...
If you want database instead of a file, there are plenty! A sqlite library running over POSIX kernel is superior to sqlite-like database in kernel, especially in terms of compatibility and features. Your "record level locking" is already possible, it's called "a database" and it is fine with POSIX.
POSIX won because it was first. Simple inertia keeps it there.
Linux has made some strides to buck the shackles though. The io_uring stuff being some of the better innovations.
UNIX only started wide distribution in 1975. The first POSIX standards were not proposed until 1988. To pretend otherwise is to attempt to rewrite history. There were complaints about UNIX API's long before everyone standardised on POSIX. Not before, not during, not after, have the elephant riders really gotten down and gotten to work. And where they have, as others have pointed out, it's things like io_uring which have emanated from the Linux community itself.
Embedded API's may be better in many respects, but that does not mean that any particular vendor's implementation should be the new basis for a standard - especially if they cannot or will not support the existing deployments out there. Software developers love a clean slate, solution providers and integrators need to be able to deploy something to their customers and be able to guarantee interoperability etc. It's a pipe dream neutered by the practical reality of the real world.
Nobody is arguing that they are completely wrong - it's just that it's long been giving off a "young man shouts at cloud" kind of smell for a long time, and it's not really that useful other than to give other people who have been hurt by POSIX a place to vent before they go off for another scrum, kanban, retrospective, or long lunch and forget about it until the next article.
Not true. OS/360 was released years before the first Unix (OS/360 in 1966; Unix development started in 1969). Multics' development also preceded Unix (indeed, the developers of Unix started by working on Multics).
It's easy to whine, but Unix' interfaces also work for a wide variety of situations.
If you think you have a better idea, implement it & try to convince others to use it. That's how things get better.
I suppose that a real force if change would gather around some real projects with specific needs, which eventually would produce a common, shareable "better alternative". Examples: io_uring, ZFS, containers, http/2, every successful programming language, etc.
I come here for the snarky comments and the “walking away feeling good” feeling, not actual action! /s
This post feels like it falls into the XKCD trap of “soon: there are 15 standards”
If you remove POSIX, what will replace it? If the answer is “nothing” then now on earth do you compete with a “build once run 99% everywhere else” mantra?
You’d end up with IE6 and ActiveX all over again, or HFS resource forks
Whatever will supplant POSIX is going to be something that will have been proven to work already, ready to be standardized. If it's not there yet, POSIX can reign supreme, despite all its (real) flaws.