| HN Mirror

You are making the great-grandparent's point (with which I was agreeing). Their concern was not only the cruft built up in the POSIX API, but the many layers of abstraction and behemoths of code that depended on said cruft, making it a compatibility nightmare to ever remove. That comprises the web browser that drives chromeos's apps; the java runtime that drives android apps; the language runtimes that drive serverless apps.

IoT is even more of a niche than desktop.

And, I think you underestimate the amount of software written in c, directly against posix.

I don't underestimate the amount of C code written against POSIX, luckly the last time I did it was in 2001.

Since then, language runtimes have spared me the effort, and I am not alone.

josephg 1961 days ago

> ChromeOS and Android? POSIX APIs are not exposed to app developers. Cloud? Language runtimes and serveless make POSIX irrelevant.

The underlying POSIX filesystem is still exposed to android developers via java's File. And via the C apis too, from the sounds of things. I think its the same on iOS.

But even if you're only using posix calls indirectly through complicated database abstractions and unix sockets, you're certainly still paying a cost. Plenty of benchmarks have been made over the years showing how better APIs can yield 20+% more filesystem & TCP socket performance on linux by bypassing write() and friends. If you spend $10k on a database or application server, think about it as $2k of that hardware wasted simply due to bad kernel APIs. And I'm sure there's plenty of features postgres and sqlite don't have because their devs instead needed to spend their days in a desperate struggling to make their software work correctly, at all.

Aside from performance, in my opinion a better API would also be transactional, at the filesystem level. Aside from dramatically simplifying every database, that could also would allow collaborative editing through simple network shares. I don't even think it would be that hard to do.

0. https://fuchsia.googlesource.com/docs/+/dart-docs/dotdot.md

> Aside from performance, in my opinion a better API would also be transactional, at the filesystem level

A better API shouldn't be a filesystem. As a strictly hierarchical system, its only virtue is that it should be easy to create sandboxes and reason about the resultant guarantees. Emphasis on 'should'; in practice, chroots are easy but very ineffective. (I believe fuchsia[0] and plan9[1] do a slightly better job of this.)

Systems based (for example) on tags and tag categories are faster, more expressive, easier to reason about, and can be constructed into arbitrary trees on the fly should the need arise. (They are thus also capable of presenting a hierarchical interface to a legacy application, so compatibility isn't an issue.)

1. Because plan9 does a better job than unix of making all resources files, inability to access some subset of files is a stronger guarantee.

imtringued 1961 days ago

I disagree with everything you said because your tone is just wrong. Old APIs don't remove the need for new ones. New APIs don't remove the need for old ones. The existence of one API does not prevent the existence of another API. Phrasing this as an us vs them problem will just waste your time and fail to convince everyone else. Instead of telling everyone how wrong they are you should convince them how great the new thing is.

Java File doesn't expose POSIX semantics directly.

In fact, there are special derived classes to handle file system specific semantics, if one feels inclined to do so, but that doesn't mean they work all the time, as JVM runs anywhere.

Jasper_ 1961 days ago

pjmlp, I don't know how you can keep claiming stuff like this. Android has fopen and pthread and you are allowed to use them in your app.

https://developer.android.com/ndk/guides/stable_apis

fopen is part of ISO C, supported by NDK, and pthread is a special case.

> Note that on Android, unlike Linux, there are no separate libpthread or librt libraries. That functionality is included directly in libc, which does not need to be explicitly linked against.

Better learn how much POSIX Android actually allows.

0. https://android.googlesource.com/platform/bionic/+/refs/head...

> pthread is a special case

How's that? It's a posix api among many others which is implemented on android.

How about fork[0], which is one of the more maligned posix apis (as far as I know, no one has any big problems with pthreads). Or errno[1]. Lots of ugly garbage in android...

1. https://android.googlesource.com/platform/bionic/+/refs/head...

So what?

APIs that aren't part of NDK stable API contract are not allowed, and since Android 7 Google has started to implement security measures to kill processes that try to use private APIs, one of the reasons why termux is no longer.

Good luck using your beloved POSIX APIs and not being killed in random Android devices.

josephg 1961 days ago

Thats a distinction without a difference.

According to this google result[1] open() / write() are officially part of posix, while fopen() is part of C. Whatever - that distinction misses the forest for the trees. Its the semantics of those methods that hold computing back. Not their syntax.

[1] https://www.mkompf.com/cplus/posixlist.html - I'd have read the spec itself but you have to buy it from IEEE. Blergh.

No it does not, a platform with ISO compliant C compiler is not required to support POSIX in any form.

By the way, since C11, there is no need for POSIX threads any longer.

C11 threads might be implemented on top of POSIX threads, or anything else that the compiler vendor thinks of.

josephg 1960 days ago

Sorry; the mistake was mine in my earlier comment. I pointed to "the crufty parts of POSIX" in an effort to point vaguely to the UNIX filesystem abstractions - fwrite/write, socket fds, fsync / fsyncdata, as well as fork() and whatnot. I don't actually care about the POSIX spec itself, or how POSIX differs from C11 (or how any of that is wrapped by the equivalent methods in Java).

This caused a distraction from the point I was making - which is that there are other ways we can do computing that don't use this model for files at all. For example we could make file operations transactional, or make files semantically rich - like database objects. So files themselves aren't "buckets of bytes" that need to be parsed by each application which interacts with them. There's lots of other ideas in this idea space - but the yoke of millions of lines of legacy code makes it difficult to explore this space outside of toy programming environments. And I worry as a result we might be stuck with the unix model forever.

specification https://pubs.opengroup.org/onlinepubs/9699919799/functions/o...