Oh ! The performance table on github is not rendered. If you look at the same page on https://fossil.kd2.org/karadav/doc/main/README.md KaraDAV is very close to apache mod_dav module and way faster than NextCloud.
> KaraDAV performance was very close to mod_dav, and NextCloud performance was incredibly poor.
And yeah, you can even buy phones with a non-android linux pre-installed, e.g. from pine64. But they come with all kinds of "for early adopters" warning labels. Deservedly so, in my opinion.
Hope there's a timeline in which banking and corporate apps can run/be enrolled on that. If the current geopolitical mess from the USA isn't a good-enough reason to make it happen, I don't know what is.
Why are all commenters on HN ignoring the only smartphone running an FSF-endorsed [0] operating system, Librem 5, and only list everything else? I just can't get it.
Because it was a kickstarter that was run like a scam, was years late to deliver the first device, the hardware was already not good at the start due picking an automotive SOC, the form factor was bulky, and the software was really buggy.
GrapheneOS is a much more practical open source OS to use Linux on a phone.
GrapheneOS is not solving the actual interesting problem (running on an entirely mainline kernel, just like on x86). It's effectively a hardened variety of LineageOS/AOSP, hence entirely reliant on device-specific downstream kernels/BSPs that will never see a feature update.
BTW, hardware support on postmarketOS "community" class devices has seen some nice improvements as of late. Once these improvements meaningfully stabilize (avoiding the risk of regression/breakage; there's been some of that even in the recent testing for the 2025-12 stable release) it's quite possible that some "community" devices might finally reach "main" class, marking them as OK for daily-driver use. Something to watch for as we approach 2026-06.
>GrapheneOS is not solving the actual interesting problem
Consumers don't care how interesting the developer's problems are. They want their own problems to be solved and GrapheneOS does a better job of that.
>running on an entirely mainline kernel
Google already did that work years ago. Android will work on a mainline kernel. Just like with x86 the mainline kernel needs to support the hardware e you want to use though.
And while Linus allows Linux to be open source. A benefit of open source is that you can fork it if upstream decides to stop development or go closed source.
>This doesn't work with GrapheneOS.
GrapheneOS can use free drivers too. It literally is using Linux.
> GrapheneOS can use free drivers too. It literally is using Linux.
Except there is no device with free drivers that it supports. They just refuse to support Librem or Pinephone without a good reason. (I strongly disagree with their "security" arguments.)
> A benefit of open source is that you can fork it if upstream decides to stop development or go closed source
Android is already semi-closed (see this submission). Are GrapheneOS developers forking it? (No)
That's not how it works. GPL only prevents old versions from becoming closed source. If Linus added code to the kernel which required a $100k license to redistribute then people could no longer freely distribute the code of the kernel. People could not freely distribute compile kernels because they would need that license. GPL doesn't magically make all licensing issues go away. He could also make a required kernel module that was not GPL licensed that Linux could require to operate.
>Except there is no device with free drivers that it supports.
Having a working system providing competitive value to others is much more important.
>They just refuse to support Librem or Pinephone without a good reason.
The good reason is that those devices can't provide industry standard security.
Because it's prohibitively expensive for something that isn't guaranteed to be a usable daily-driver for most people. Also IIRC the hardware isn't quite worth the price tag in-and-of-itself.
> We need a third alternative, based on freedom with your device.
We does not refer only to HN users, and there is no implication as such.
The default assumption is that 'we' refers to the general population.
However, even if I'm charitable and go with your assumption that 'we' referred to HN users, I will confidently say most HN users also don't care about FSF approval.
You like to post a lot of HN links without ever giving an indication of what they point to. As a habit, I don't waste my time clicking random links that people post without context.
Most HN users don't know about the alternatives, just like the public. If you say that those who know don't care, I will ask you for some evidence.
In my linked post I explain why the public doesn't matter at this point of time. Also I explain that the public doesn't need the alternative before it works flawlessly, i.e., before it becomes popular among technical users.
> Most HN users don't know about the alternatives, just like the public.
That's a rather ridiculous assumption on your part. As a tech-literate crowd, it's quite likely they are aware of them, if for no other reason those alternatives make the front page semi-frequently.
> If you say that those who know don't care, I will ask you for some evidence.
As soon as you provide evidence for the premises for your argument. As my position is simply saying yours is false, the onus is on you to support yours.
> "we" are aware of the problem and care about the freedom.
Sure, maybe, but caring about freedom isn't the same as caring about FSF approved software.
When I said native, I meant native to the language, something written purely in Zig, without depending on external UI toolkits. Basically like how Rust's egui works.
I'm a vim user, using orgmode. I've noticed the blog of Sascha Chua. She posts Emacs News and in these posts there are some orgmode gems. But she is posting more on Emacs. Maybe interesting to look these posts up:
https://sachachua.com/topic/
I don't want to make advertisement, but what you describe is what Beeline is selling for bicycle and motor bike. I've not tried it. I don't know how good it works.
These are available in the Netherlands and Belgium. And as the cyclists there like to travel a little bit further, the network is extended around north of France, the German border, some in Luxembourg. This is a very nice way to travel.
Stasiware is more appropriate. Stasi (Staatssicherheit) was the administration in charge of spying each citizen of east Germany. It runs until 1989. So more people remember the opening of the archives in the 1990ies.
> KaraDAV performance was very close to mod_dav, and NextCloud performance was incredibly poor.
reply