Egregoros

Signal feed

Timeline

Post

Remote status

Context

21

Jolla could capitalize so hard right now on Android getting closed off more and more by Google if they had a clue how to play this niche that is only going to get bigger. bringing back The Other Half and being able to get a modern phone running a Linux phone OS that actually works and isn't ugly and miserable to use, and has an Android compatibility layer, AND will soon likely have a physical QWERTY keyboard, AND has hackable open hardware modding (!) would be like next level getting in on the ground floor and pulling forward a space that is only going to keep growing

@nyx@social.xenofem.me

Jolla could capitalize so hard right now on Android getting closed off more and more by Google
They really could, if they actually made Sailfish OS less proprietary than Android.

That is currently not the case, so if you actually care about free and "open" software, Android is currently a better operating system than Sailfish.

That's also why I disagree with calling Sailfish a "Linux phone". It is misleading. Android also has a Linux kernel, so Android is also a "Linux phone".

@SuperDicq @nyx > Linux phone, while Android just is

Yeah, the one thing that Android isn't is Unix, that's the model that Android explicitly throws away. (See how anyone wanting a Unix environment on Android installs termux, which could be compared with Cygwin or WSL, specially in how it ends up jailed in a corner)

Could also put that SailfishOS (among others) isn't a gigantic monolithic system, but instead atomic system packages, so you can throw away stuff you don't like as well as replacing bits like a ship of thesus, something you can't cleanly do with Android.
@SuperDicq @nyx Yeah, the certification bit is pretty much just UNIX trademark rights and corporate/US-federal-government (at least when it was also published through FIPS) box ticking.

As for Unix the OS. Or arguing about some sort of Unix Philosophy or copyright lineage.
Either Unix is dead (and starting to smell really bad), or Unix is still a thing.
@SuperDicq @nyx Yeah, and that's one I can agree on (although I love saying that macOS is outdated as it's still UNIX 03 aka POSIX 2001, severely lagging behind FOSS unixes to the point where a bunch of stuff requires ifdefs or patching).

Although could still say that android isn't POSIX, which yeah, it isn't.
In a manner similar to like how RFCs don't need certification and whatnot but are still referred to.

@SuperDicq @nyx Yeah but very related, like in the standards that got absorbed by SUS, POSIX still remains, while XPG is like a ghost that only seems to remain for incrementing variables like XOPEN_VERSION (XSI indicator), and SVID seems to be long dead.

Also technically, SUS is POSIX with XSI, with Unix certification adding X/Open Curses as well.

(I've been working on OpenGroup's testsuite since march, I know the mess ^^)

@SuperDicq @nyx I care about Unix portability (and part of it's history) so managing the standard makes sense.

To me the certification bit is pretty much just the income source, and certification is them running the testsuite, sending the logs and me validating it, so I don't end up having to deal with all kinds of Unixes. It's still pretty much "Not a foss system? Your bugs to deal with".
@SuperDicq @nyx POSIX still has updates you know, and system devs do care about POSIX, in the same style as they care about say ISO C if not even more.
For example GNU coreutils has a regular participant in the meetings, BSDs devs often participate in the bugtracker/mailing-list, …

In fact, the ~40 years of experience plus multiple implementations is a hell of a virtue when other ecosystems are annoyingly full of churn but also locked to a single vendor and it's whims.
And I know you like GNU, but FOSS doesn't means you're free from being pretty much locked on the whims of a vendor given a big codebase that's effectively too big to fork.

POSIX and C? Just write it, adopt new interfaces, maybe toss some after deprecation time measured in years, and you can use whatever operating system you want with ability to easily swap components.

Heck reminds me of the awful state we're in with SSL/TLS libraries, with most software using it being stuck to OpenSSL and it's still horrible codebase and monstrosity of an API.

@lanodan@queer.hacktivis.me @nyx@social.xenofem.me

and system devs do care about POSIX
I mean I get that basic stuff like GNU coreutils might want to be compliant, because it is convenient for users of other systems to use something that works in a similar way.

But GNU is deliberately not POSIX compliant, there are a lot of things in POSIX that GNU doesn't agree with and they do differently. That's why a compatibility mode, called using POSIXLY_CORRECT exist.

@SuperDicq @nyx And that compatibility mode is extremely normal and expected.

On conformant POSIX.1-2024 systems with GNU software, getconf V8_ENV would return something like POSIXLY_CORRECT=1 to set that variable.

Quite like how illumos has getconf PATH returning /usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin to get things like a conformant sh instead of the painfully legacy one that lives at it's /bin/sh.

Which is similar to how on C, you can pass -std=c17 to the compiler, and do #define _POSIX_C_SOURCE 202405

@SuperDicq @nyx Even though the differences are extremely small?

Like the ones I'm aware of are those two:
- df(1) using 1024 instead of 512
- getopts(3) continuing to parse options after non-options

Small enough that in practice it barely ever matters, like you can still write strictly POSIX code that will run against GNU software without the POSIXLY_CORRECT envvar set.

Not caring about POSIX is more like the behavior of macOS.

Replies

24
@SuperDicq @nyx Eh? Which ones for example?

Specially as like extensions typically aren't a POSIX conformance issue, both for utilities and for C interfaces.

Like there's namespace limits for C interfaces (mostly allowed prefixes/suffixes, and posix_ being a reserved prefix).

And pretty much none of utilities, which is why new posix options require to make sure to not step on ones that are already defined in existing implementations or to have consent from those (reminds me of a recent question about adding getopt_long in POSIX because well… probably going to run out of possible short options at some point).
@SuperDicq @nyx Yeah, that one's 100% a non-issue and not what POSIXLY_CORRECT is even about, just try it.

You're just supposed to avoid it when writing portable code, but effectively still can.

POSIX isn't there to tie down the OS, specially when a lot of things are out of scope (like so glad system management like init systems are out of scope, in fact Linux Standard Base really should have taken a hint there).

@SuperDicq @nyx FHS to me is one of the weirdest still surviving bits of LSB, like either it's distributed as source and so buildsystem needs to allow setting sbindir, bindir, mandir, … to avoid hardcoding paths.

Or it's binary horror (which personally is something I'd rather not pretend can work reliably across different machines) and so does not ever messes with the root filesystem or anything under /usr, and instead either uses home directories (like ~/.local/ plus maybe xdg dirs) or does it's stuff in something like /opt/$vendor/