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
Context
13Jolla could capitalize so hard right now on Android getting closed off more and more by GoogleThey 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.
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.
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me Sailfish isn't Unix either, it's is GNU.
:^)
@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
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me Unix 3 is a certification, not an operating system. It just means these systems are POSIX compliant which is something that only corpos actually care about. It's not Unix (the operating system).
@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.
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me If you ask me I would say ignore all the trademark and certification bullshit. In my opinion the last version of Unix was V10.5.
Unless you ask some weirdos who thinks all these weirdo corpo forks of V7 like Unixware and Solaris and shit like that are the latest versions of Unix.
And even weirder people who say BSD is still actually Unix because it originally started as a fork.
@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.
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me
FOSS unixesDoesn't exist. All versions of Unix are proprietary.
@SuperDicq @nyx FOSS POSIX, whatever, essentially the same thing.
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me POSIX and SUS are also not 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 ^^)
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me Why do you work with this crap anyways?
Replies
34
@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".
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me
I care about Unix portability (and part of it's history)Why? I really don't care about that at all.
Why does it matter to you if your stuff is "compatible" with some 40 year old standard that almost nobody uses?
@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 @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.
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me
and system devs do care about POSIXI 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
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me The point being, that to me that says that the developers don't actually care about POSIX, because otherwise they would've made POSIXLY_CORRECT on by default.
@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.
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me It's mostly extensions. Many commands have extra arguments and more advanced options that do not exist in POSIX, meaning that a lot of stuff written for GNU do not work on other POSIX systems.
POSIXLY_CORRECT also disables all these additional GNU extensions in many programs.
@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).
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me I don't know because I'm not a POSIX nerd and I have never actually read the spec, but I'm just going to assume that options like ls --color are not POSIX.
@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).
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me Ok LSB can fuck right off.
First of all it is called "Linux" and has absolutely nothing to do with the kernel. And I use Guix so all my homies hate FHS.
@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/
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me In case of binary horror, use patchelf.
@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.
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me There's an alarming amount of people in favor or getting rid of traditional software distribution altogether and replacing everything with Flatpaks because muh sandbox.
@SuperDicq @nyx Prank idea: Go to a Flatpak conference with a bucket of sand and a rake.
@lanodan@queer.hacktivis.me @nyx@social.xenofem.me I think that would amuse them. I don't want to amuse them. I want to abolish flatpak.
@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"
@phnt@fluffytail.org @lanodan@queer.hacktivis.me @nyx@social.xenofem.me I love this shirt so much. It's actual top tier ragebait. I run shepherd, xorg, no libadwaita, and no flatpak.
@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.
@phnt@fluffytail.org @lanodan@queer.hacktivis.me @nyx@social.xenofem.me
Gentoo, so systemd is out of the questionIt's not. Gentoo supports systemd if you want it to.
@SuperDicq @lanodan @nyx I know, but probably only gnome users actually use it. Sure, you can use it, but why would you.
@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.
@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.
@hj @SuperDicq @lanodan @nyx If it was a single shirt, I would probably buy it. systemd... on the front and OK on the back.