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
Timeline
Post
Remote status
Replies
30
@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.
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 Well, there's been some that have been certified in the past, Inspur K-UX and EulerOS for example, interestingly both RedHat derived.
https://www.opengroup.org/openbrand/register/brand3622.htm
https://www.opengroup.org/openbrand/register/brand3617.htm
https://www.opengroup.org/openbrand/register/brand3622.htm
https://www.opengroup.org/openbrand/register/brand3617.htm
@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.
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.
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, Plan9 is more like when a book author starts new series, it can feel the same as the previous one but can't take it as like a sequel.
@SuperDicq @nyx FOSS POSIX, whatever, essentially the same thing.
@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".
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 @lanodan @nyx bsd compatibility is important to me because modern bsd systems are very nice to use operating systems , from which modern linux distros could really learn a lesson or two ngl . of course its not always tge case that such compatibility is necessary , but if one is able to keep it , why not do it ?
@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.
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.
@SuperDicq @lanodan @nyx
>Why? I really don't care about that at all.
You don't want the software you write to run on as many platforms as possible?
>Why? I really don't care about that at all.
You don't want the software you write to run on as many platforms as possible?
@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.
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.
@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).
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).
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/
@SuperDicq @nyx For me binary horror goes in a bwrap-container/chroot, these days OpenSUSE flavor, that way I don't need to care about binary-compatibility in my normal environment.
Linux didn't support containers at the time of LSB though, and I guess these days it would embrace stuff like docker which is like a gate to hell.
Linux didn't support containers at the time of LSB though, and I guess these days it would embrace stuff like docker which is like a gate to hell.
@SuperDicq @nyx Prank idea: Go to a Flatpak conference with a bucket of sand and a rake.
@SuperDicq @lanodan @nyx Reminds of this shirt. Incidentally the issue with packaging software being hard and sometimes barely doable is an issue of not writing portable software. Or to be more precise, not caring about portability.
linux-ragebait-shirt.jpg
linux-ragebait-shirt.jpg
@phnt @SuperDicq @nyx Yeah, sometimes it's fun how like my stuff tends to work all the way to like Haiku with little to no issues.
And then there's software that's like "I don't know the version of your C compiler, screw you"
And then there's software that's like "I don't know the version of your C compiler, screw you"
@SuperDicq @lanodan @nyx And I have none of those things on my system. Gentoo, so systemd is out of the question and the 3 remaining are all masked and disabled with use flags.
@hj @SuperDicq @lanodan @nyx If it was a single shirt, I would probably buy it. systemd... on the front and OK on the back.
@SuperDicq @lanodan @nyx I know, but probably only gnome users actually use it. Sure, you can use it, but why would you.
@SuperDicq @nyx @phnt Given you're sharing, here it's openrc + s6, sway, no libadwaita, no flatpak.
Although on my Sun workstation (kept off the internet): svcadm, Xsun, Gnome1/KDE2?/Xfce from another era, too retro for libadwaita, too retro for flatpak.
Oh and: Traditional vi, vim, xemacs, gnu emacs, maybe even MULE Emacs, …
Although on my Sun workstation (kept off the internet): svcadm, Xsun, Gnome1/KDE2?/Xfce from another era, too retro for libadwaita, too retro for flatpak.
Oh and: Traditional vi, vim, xemacs, gnu emacs, maybe even MULE Emacs, …
@SuperDicq @nyx @phnt Also mdevd instead of systemd-udev (or eudev), so I have 0 amount of systemd code on my machines.
@phnt @menherahair @SuperDicq @lanodan @nyx Systemd is quite nice if you want services to get back up and react to global events such as conntrack exhaustion and load peaks. Gentoo at the same time is nice for less optimized for architectures, particularly amd's zen with decent vectorization support.