Well, it idles for about 22 hours, can record videos, does multi-constellation GNSS and both classic and LE Bluetooth.
The way to make disinterested normies able to use it is to have lots of nerds capable of fixing various papercuts themselves switch already and contribute rather than complain.
Thanks for sharing! I hadn't heard of this before. IMO any competition in this space is good competition.
But the reality is that it's not quite that straightforward. Linux desktop is a perfect example of that. We have tons of nerds working on the Linux ecosystem. Many on distros meant to ease transition from Mac/Windows to Linux (like Pop OS).
But if I were to tell my mom to install Pop OS, she would look at me like I'm crazy.
In some ways, Linux has become "cool" — Steam Machine and Steam Deck run Linux, and they're popular. Unfortunately, they're popular within a niche, and even then, they're popular for only a slice of digital life. People don't do work on a Steam Deck and I can't imagine many doing work on a Steam Machine.
Mobile phones are completely different though because most people have one phone. And that phone needs to do everything they need it to do. It needs to run the apps they need. It needs to play the games they want. It needs to integrate into everything. And it also needs to look trendy, because smartphones have become a bit of a status symbol of sorts.
So, while I agree that us nerds must become part of the solution than the problem, it's not enough. We need buy-in from major service providers. We need marketing. That's all stuff that the typical nerd can't/won't do.
> But if I were to tell my mom to install Pop OS, she would look at me like I'm crazy.
What would she say if you asked her to install Windows? It doesn't matter. Normal people should either buy preinstalled or ask technical people for help. Using GNU/Linux desktop is as simple as Windows. It will be the same with phones one day, if we push it.
If I told her to install Windows, she'd at least know what to tell the technician in the event that I'm not around.
If I install Pop OS on her computer she will just tell the technician she has a laptop because she doesn't know the difference. I would hope that the technician does know the difference, and moreover, knows how to use it (which I assume someone calling themselves a technician would know how to troubleshoot basic stuff on a foreign operating system, but I've been wrong on lighter assumptions)
I've been happily using it on several phones since 2008 (and writing this on one of them right now), only two years shorter than on my desktops/laptops. "Non-starter" is in the eye of the beholder.
There are phones that can run "true Linux" out there, and there even are ports of Sailfish OS for some of them, but Jolla phones were never part of those and rely on Android drivers instead.
People also successfully use Librem 5 (which I happen to use), OnePlus 6, Pixel 3A and some others. There's not a lot to choose from, sure, but they do exist.
It's both; the one I mentioned is for system drivers, the one you're talking about is for running applications (which you can also do on a regular non-Halium GNU/Linux using e.g. Waydroid).
I'm sure that if you tell Jolla about a relatively modern mobile SOC with mainline linux support, they'll look into it instead of relying on libhybris.
They can rely on libhybris if they want, why should I care - I just object to calling that "a full-stack alternative", especially when alternatives do exist.
That wasn't modern when they released it in 2020. Jolla chose a little more pragmatism for their hardware in the hope that they actually sell phones to other people than 100% open-source purists. I find it funny when dudes like you go all "well awkshwally" on them...
I use my Librem 5 as a daily driver, and I’m certainly not an open source purist.
What I do care about is that my phone isn’t going to run into obsolescence a few years down the road (due to hard kernel forks and YOLO’ed device drivers that are not going to be updated for newer kernels).
Battery: I unplugged it from the charger 10 hours ago, it's currently at 55%. Typically it's up to 22 hours when suspended, up to 12 hours when idling without suspend and about 3-5 hours of active use depending on what you're doing. Could be better, but can be worked with.
What I was trying to tell you with my original reply to you is that Jolla chose a different point on the free/pramatic curve of available SoCs. They selected a phone that's more likely to be used by average people rather than a fully open one. (You can still see in this very thread, complains about the high price for what it offers, showing they haven't fully succeeded, at that.)
Pointing out that they still rely on Android drivers for booting the thing is a little tone-deaf from my perspective when they're basically choosing a different path towards a similar goal to Purism and other alternative mobile vendors: higher availability of non Google, non Apple mobile devices. Perfect is the enemy of good and all that. And like I explained the reason for their choice is not nefarious but a pragmatic one.
And what I was trying to tell you is that they're free to choose whatever point on the curve they want and pursue that as long as they don't misrepresent what they're doing. What is "full-stack alternative" supposed to mean when it relies on the very thing it's supposed to be an alternative to? What is Purism's effort then, "even fuller-stack alternative"? Words have meanings.
mmap is not a C feature, but POSIX. There are C platforms that don't provide mmap, and on those that do you can use mmap from other languages (there's mmap module in the Python's standard library, for example).
I think this is sort of missing the point, though. Yes, mmap() is in POSIX[1] in the sense of "where is it specified".
But mmap() was implemented in C because C is the natural language for exposing Unix system calls and mmap() is a syscall provided by the OS. And this is true up and down the stack. Best language for integrating with low level kernel networking (sockopts, routing, etc...)? C. Best language for async I/O primitives? C. Best language for SIMD integration? C. And it goes on and on.
Obviously you can do this stuff (including mmap()) in all sorts of runtimes. But it always appears first in C and gets ported elsewhere. Because no matter how much you think your language is better, if you have to go into the kernel to plumb out hooks for your new feature, you're going to integrated and test it using a C rig before you get the other ports.
[1] Given that the pedantry bottle was opened already, it's worth pointing out that you'd have gotten more points by noting that it appeared in 4.2BSD.
If we're going to be pedantic, mmap is a syscall. It happens that the C version is standardized by POSIX.
The underlying syscall doesn't use the C ABI, you need to wrap it to use it from C in the same way you need to wrap it to use it from any language, which is exactly what glibc and friends do.
Moral of the story is mmap belongs to the platform, not the language.
No, that's too far down the pedantry rabbit hole. "mmap()" is quite literally a C function in the 4.2BSD libc. It happens to wrap a system call of the same name, but to claim that they are different when they arrived in the same software and were written by the same author at the same time is straining the argument past the breaking point. You now have a "C Erasure Polemic" and not a clarifying comment.
If you take a kernel written in C and implement a VM system for it in C and expose a new API for it to be used by userspace processes written in C, it doesn't magically become "not C" just because there's a hardware trap in the middle somewhere.
and if i directly do an mmap syscall on linux from a freestanding forth that doesn't go through libc for anything? sure, c unfortunately defines how i have say, pass a string, but that's effectively an arbitrary calling convention at that point; there's no c runtime on the calling side so it's not particularly useful to contend that what i'm using is a c api.
or perhaps mmap is incontrovertibly a c function on platforms where libc wrappers are the sole stable interface to the kernel but something else entirely on linux?
> and if i directly do an mmap syscall on linux from a freestanding forth
... mmap() remains a system call to a C kernel designed for use from the C library in C programs, and you're running what amounts to an emulator.
The fact that you can imagine[1] an environment where that might not be the case doesn't mean that it isn't the case in the real world.
Your argument appears to be one of Personal Liberty: de facto truths don't matter because you can just make your own. This is sort of a software variant of a Sovereign Citizen, I think.
[1] Can you even link a "freestanding forth" with an mmap() binding on any Unix that doesn't live above the libc implementation? I mean, absent everything else it would have to open code all the flag constants, whose values change between systems. This appears to be a completely fictitious runtime you've invented, which if anything sits as evidence in my favor and not yours.
i'm not so much imagining an environment per se¹ as describing one i've already written, so i'm not entirely sure where any of this is coming from. if you care to have some additional assurance this isn't somehow an elaborate rhetorical trap, a previous comment about forth tail call elimination with a bit of demonstrative assembly is presumably only a short scroll down my profile. ctrl-f for cmov if you want to find it quickly. as i recall, it came up for similar reasons then because people often make similar incorrect generalizations about lots of things that implicitly sit atop a c runtime in their minds. that said, you're the first one to call me a sovcit before asking any clarifying questions so at least there's some new pizzazz there.
i was clear that i was talking specifically about linux precisely because this isn't something one can do portably for exactly the reasons you're describing (which, yes, makes porting things built like this off of linux before the point you've built up enough to be able to go through libc annoying and ad hoc at the very least).
the fact remains that i can, right now, non-theoretically, on a well supported common unixlike os, and entirely unrelated to whatever weird crusade you seem to have invented to stand in for my side of this discussion, link a pile of assembly with -static -nolibc, fire up the repl, and mmap files into memory as i please with nary a bit of c on the userspace side.
as i originally said, i'm happy to consider linux a weird exception to the point you're making in a wider context since this isn't something you can do portably, but there still are entirely useful things one can do today with mmap that involve zero userspace c code on a widely supported platform.
edit: lol forgot to even get to this part. i'm also somewhat curious what you mean with this bit: "you're running what amounts to an emulator." perhaps i'm not firing on all cylinders today but i fail to see how it's useful to characterize performing bare syscalls from assembly (or something more high-level built out of assembly legos) as an emulator in any way, but i'm open to having missed some interesting nuance there.
¹ unless you mean trivially (seeing as this is code i imagined and then proceeded to write) in which case i suppose i agree
> C is the natural language for exposing Unix system calls
No, C is the language _designed_ to write UNIX. Unix is older than C, C was designed to write it and that's why all UNIX APIs follow C conventions. It's obvious that when you design something for a system it will have its best APIs in the language the system is written in.
C has also multiple weird and quirky APIs that suck, especially in the ISO C libc.
>> C is the natural language for exposing Unix system calls
> No, C is the language _designed_ to write UNIX. [...]
This is one of those hilarious situations where internet discussion goes off the rails. Everything you wrote, to the last word, would carry the same meaning and the same benefit to the discussion had you written "Yes" instead of "No" as the first word.
Literally you're agreeing with me, but phrasing it as a disagreement only because you feel I left something out.
If I write an OS in Basic, surely the 'natural' language for exposing the system calls is Basic?
Yes Unix predates C. But at this point in time 50+ years down the road, where the majority on nix users don't use anything that ever contained that code, and the minority use a nix that has been thoroughly ship of Theseused, Unix is to all intents and purposes a C operating system.
> If I write an OS in Basic, surely the 'natural' language for exposing the system calls is Basic?
For that specific OS, that would probably be the case? I think every API is bound to reflect the specific constraints of the language it has been written in. What I was trying to clarify was that UNIX and C are intertwined in an especially deep way, more than basically other OS that doesn't have a UNIX API, because both were born and written alongside each other, so some Unix APIs rely on C-specific behaviour and quirks and some C features were born and designed around the same historical context UNIX was born
Agree to disagree there. For casual "I need to vectorize this code" tasks, modern compilers are almost magic. I mean, have you looked at the generated code for array-based numerics processing? It's like, you start the process of
"vectorizing" the algorithm and realize the compiler already did 80% of it for you.
These feelings aren't mutually exclusive. I'm often like "I have no memory of this place" while my name stares at me from git blame, but that doesn't mean my intuition of how it's structured isn't highly likely to be right in such cases.
I juggle between various codebases regularly, some written by me and some not, often come back to things after not even months but years, and in my experience there's very little difference in coming back to a codebase after 6 months or after a week.
The hard part is to gain familiarity with the project's coding style and high level structure (the "intuition" of where to expect what you're looking for) and this is something that comes back to you with relative ease if you had already put that effort in the past - like a song you used to have memorized in the past, but couldn't recall it now after all these years until you heard the first verse somewhere. And of course, memorizing songs you wrote yourself is much easier, it just kinda happens on its own.
If you're interested in open handheld devices, the Librem 5 smartphone has its layouts, schematics, assembly drawings and 3D designs published on a free license:
reply