Just learned about pinggy.io. Neat little service! I wonder how many requests/second that phone can serve. Nowadays, phone specs aren't too bad for a simple web server.
As someone who's been using PHP since the late 90s, I'm greatly enjoying this renaissance in its fashionability. Seeing multiple comments on HN genuinely recommend it is odd.
Laravel was the first framework I ever used. Until now, I haven't come across any other framework that is well-designed, and enjoyable to use as Laravel (and made PHP fun). I always assumed Laravel was the standard, but sadly that it's not the case.
Especially when the article suggests to "subscribe to Pinggy Pro", which is $5/month (currently $2.50/month on sale). Pretty sure that's more than the cheapest VPS on Hetzner.
This seems like paying more upfront and paying more per month for less.
> Pretty sure that's more than the cheapest VPS on Hetzner.
I'm rocking a two node cluster in Hetzner. One is an old 1vCPU small that costs over $3/month, and the other is a new 2vCPU addition that is a dash over $4.
I pay for two ipv4 external IPs which costs more.
Also, Hetzner started to offer ARM64 nodes that are even cheaper.
Yes, Pinggy Pro is more expensive than operating your own nodes in Hetzner.
Cloudflare still provides free hosting for one website. Setting it up not exactly straightforward. But they're currently hosting my website, my domain, and giving me free CDN, without my having ever provided a credit card.
And yeah, I'm hosting my blog on Cloudflare. Very nice for a free service. Just hoping that the economic downturn isn't gonna turn off the tap on services like Cloudflare Pages.
I've had a VPS since about 2013 or so and I think I haven't passed $180 yet. Of course it really depends on your usage loads, RAM usage, etc. But for small websites/apps there are cheaper alternatives.
It is not really a fair comparison. I would expect that an old android phone that is just sitting in the cupboard to be used for hosting. I think the goal should not be “hosting website” but to be able to repurpose an old compute device for something useful.
Phones these days are really good computing devices. 8GB or 16GB RAM, fast and efficient ARM processors, flash storage, inbuilt ups, Wi-Fi and 4G/5g connectivity, gpu and hardware accelerated encode and decode for video codecs etc.
An equivalent VPS (hardware wise) would be more costly imo.
I remember marvelling at the full mobile phone coverage in the Stockholm underground network 20 years ago. London's tube will manage it any year now, I'm sure...
I have always been confused how some countries have such bad coverage. Before Wi-Fi Calling, it was a nightmare to be inside any apartment building I've been to.
It's actually a great idea in some ways to use a phone instead of a Raspberry Pi, since it has a battery in case your electricity goes unstable, you can add LTE as a backup internet, and it has a screen to bootstrap it without an external monitor which not all of us have. I only wish Android phones would be more open to put a full Linux distro on them.
Ubuntu touch supports some old phones you can buy used. It's technically not a android phone anymore, but it's possible. I tried it on my oneplus 6 and I worked, I'm just not ready for the ecosystem yet
Wow. This is amazing. Just got a server-side Java application running in the Alpine Linux and was able to access it with the normal browser via localhost. Impressive stuff :D
Are you one of the developers? As I'm really curious how this works.
If Termux is enough for you the benefit is that it is quite a bit faster than userland.tech. There is also Nix for Termux which provides a lot more packages.
>Android phones would be more open to put a full Linux distro on them
Honest question. Why? How is Android not fulfilling your needs as a full Linux distro? Are there any features that you would like to see added, or do you feel that apps for what you want are not currently available?
I didn't try it out, maybe you're right. I know how to deploy my stuff via systemd, install Rust/cargo/Elm/Python/Node/GHC/libopencv/Nix/whatever, link static libs and so on. And when I'm using Raspberry Pi I need near-zero new knowledge to do all that.
I suspect that trying something like that on Android will be a long road with lots of caveats, even if possible, learning to do all the things the new "Android" way. Am I wrong?
For building native code it will mostly be the same, but you will need to learn some Android stuff for making the nonnative part of your app so you can learn how to create a background service and how to tell Android to restart your service if it gets killed due to low memory.
> How is Android not fulfilling your needs as a full Linux distro?
I mean there's a lot of things that make life difficult with Android.
* If you want most hardware to keep on working, no kernel updates are possible after the manufacturer ends support.
* Root support and service managers need to be installed aftermarket using the unofficial solution Magisk.
* No vendor kernel out of the box supports kernel compile time flags to enable the infrastructure to run Linux containers using Docker, Podman or LXC.
* Self-invented file hierarchy with a lot of restrictions that make sense from an Android UI perspective but are prohibitive when used as a regular distro.
* Since Android and drivers use bionic libc, it's not possible to run regular Linux binaries that tap into certain hardware features like Vulkan without reworking and recompiling them.
Just from the top of my head, there's a bunch of other things people could name I'm sure. Android misses a lot of the expectations people have for regular GNU/Linux distributions have - expectations that non GNU/Linux distros like Alpine do meet for the most part.
>If you want most hardware to keep on working, no kernel updates are possible after the manufacturer ends support.
Yes, this is a problem and it is trying to be addressed by generic kernel images which should make it so that you no longer need to build a device specific kernel as all of the device specific stuff has been modularized.
>Root support and service managers need to be installed aftermarket using the unofficial solution Magisk.
Root should not be necessary and these break Android's security model. Perhaps there is an operating system API that could be added that could provide the features you are looking for while keeping the system secure.
>No vendor kernel out of the box supports kernel compile time flags to enable the infrastructure to run Linux containers using Docker, Podman or LXC.
Android apps already have their own sandbox. It would be better to develop apps than docker images as darker images don't really follow the Android security model as well. What you want should be possible with Android 13 allowing for kvm.
>Self-invented file hierarchy with a lot of restrictions that make sense from an Android UI perspective but are prohibitive when used as a regular distro.
Why care about a file hierarchy? NixOS does away with it and seems to get along fine. Apps shouldn't rely on it.
>Since Android and drivers use bionic libc, it's not possible to run regular Linux binaries that tap into certain hardware features like Vulkan without reworking and recompiling them.
Most people run apps and not binaries. It is going to need to be reworked anyways.
I know there are reasons why Android works like this, but you may not be aware you've been replying to a post where I listed what I missed about Android compared to a regular Linux distro.
Android is highly opinionated to work as a platform for apps on touchscreen devices, but those opinions do add a lot of restrictions compared to other things built on Linux.
I don't think a comparison to NixOS is fair here. I'm an avid NixOS user. I would love to be able to use it or something like it on mobile. Instead, I can't do much of anything other than consume from my android device.
Likewise, I don't want to have to package all my stuff as apps. If I already have a docker container and I wish for it to be ran on my device I think that there shouldn't be another barrier. Android security model? Why do I care about that? I have a device and I want to run my software on it. It's as simple as that.
Android provides you with a heavily locked down linux kernel and network setup, which is great for app sandboxing, but not great for certain tasks you might want on a server.
For example, android makes it difficult to run userspace containers, like lxc or docker, which also limits what orchestration and deployment systems you can use (since some make very strong assumptions about being able to use containers).
Similarly, various different pieces of server software just won't work because they make use of some linux feature android intentionally builds its kernels without for security reasons.
When data traverse a x86 node, the bytes get distorted and loose their inherent ARM warmth and fidelity. No measurement tool can catch that, but we, computerphiles, can sense the change almost immediately just by our ears and by careful listening to the whining of motherboard coils.
I’ve got an old iPod laying around and was thinking about doing the same - just don’t know how feasible it’d be. Love it when people repurpose old hardware.
Definitely neat for a small personal or community site where you don't expect any kind of public traffic.
Not so useful for something that might end up on HN and go down.
Could also put a CDN infront to lighten the load on the upstream but guess what, now you're not just hosting on your phone anymore and might as well use other cloud services where often you can host more for free than a phone can handle
For those who need this I'd recommend Tailscale and their MagicDNS. You'll get access to this device for free from anywhere, with a working DNS generated for you, and only from devices that were allowed to.
With new DNS HTTPS RR and SVCB records anyone should be able to run a server from Android.
Android does not allow running server on ports below 1000. With above DNS trick one should be able to host a server on non standard port of Android without funny looking URL. We don't even need a third party like pinggy as in OP's case which might be resetting connection to OPs phone.
So far I have tried to configure my local network DNS server to respond using above records but it's not working for some reason.
Do any browsers actually use this mechanism for port detection? I'm seeing plenty of HTTPS queries in my PiHole dashboard, but I'm not sure if browsers will actually connect to some high numbered port just because HTTPS told them to.
In theory we could've had this decades ago if browser respected SRV records, but alas.
> You are a web DevOps expert. Provide a list of ten concise combinations of software stack and hardware, starting from "budget hosted VPS website, heavy caching, and dynamic DNS with outside cache" and ending with "Android phone at home on standard connection using third party dynamic DNS and basic web server". Each combination should get more homebrew until that final Android one.
There's some room for prompt improvement but the ideas in the result were an interesting read (In place of the linked website which I couldn't read of course).
For one, the list seemed way more fun, or the projects easier to maintain for a single person, when I specified "web hobbyist" as compared to DevOps expert... though I know there really are people out there who are _definitely_ looking forward to maintaining enterprise software on the weekends...
3. *Raspberry Pi with LAMP stack and dynamic DNS*
- Software: Apache, PHP, MySQL, ddclient (for dynamic DNS)
- Hardware: Raspberry Pi 4, 2 GB RAM
4. *Self-hosted containerized web stack with dynamic DNS*
- Software: Docker, Nginx, PHP-FPM, MySQL, Traefik (for dynamic DNS)
- Hardware: Home server, 2 cores, 4 GB RAM
5. *Home server with reverse proxy, caching, and dynamic DNS*
- Software: Nginx, PHP-FPM, MySQL, Varnish, ddclient (for dynamic DNS)
- Hardware: Home server, 4 cores, 8 GB RAM
6. *Self-hosted web stack on a NAS with dynamic DNS*
- Software: Apache, PHP, MySQL, Synology DDNS (for dynamic DNS)
- Hardware: Synology NAS, 2 GB RAM
7. *Old laptop as a web server with dynamic DNS*
- Software: Apache, PHP, MySQL, No-IP (for dynamic DNS)
- Hardware: Old laptop, 2 cores, 4 GB RAM
8. *Self-hosted web stack on a mini PC with dynamic DNS*
- Software: Nginx, PHP-FPM, MySQL, DuckDNS (for dynamic DNS)
- Hardware: Intel NUC, 2 cores, 4 GB RAM
9. *Web server on a single-board computer with dynamic DNS*
- Software: Lighttpd, PHP, SQLite, Afraid.org (for dynamic DNS)
- Hardware: BeagleBone Black, 512 MB RAM
10. *Android phone at home on standard connection using third party dynamic DNS and basic web server*
- Software: KSWEB (web server), No-IP (for dynamic DNS)
- Hardware: Android phone, 2 GB RAM
Right on, yeah similar here. I like the direction it takes the prompt. In the future I guess I'd ask it to sort / graduate them better. Also, it's really PHP heavy and I think it'd be fun to tell it it has to use a different, obscure stack for each item. And maybe even give each project a clever nickname based on how sketchy the stack is and the type of coder who would enjoy it. ;-)
Android does not allow running server on port below 1000 so with dyndns your URL will look funny which is okay for HN crowd but not for people you want to share your blog with.
SSH is doing the port forwarding and Pinggy is just acting like a VPS node so one could just change the port forwarding and/or have NGinx/HAProxy/Apache on the VM could listen on 443 and the Android can listen on any port. Added bonus, the web server could cache the static content to avoid the earth shattering kaboom. VM's are not free but neither is Pinggy.
it was kind of interesting to me that archive.ph sent me the images slowly, as if they weren't archived but were coming straight from somebody's phone...
With android termux you can install e.g. django/wagtail and take it from there.
In a sense these projects prove the obvious yet hidden-in-plain-sight: the vast numbers of mobile computing devices that have circulated since the "iPhone moment" could be reconfigured in all sort of ways to be more than a dumb touch screen client for scrolling down social media pages.
If we ever get to see a true open mobile OS there might be a Cambrian explosion of new applications and use cases. Not holding my breath though. The failure of open source mobile to reach a workable stage is now pretty clear. It seems this domain is TITO (too important to open).
Lots of phones are open enough to install lots of things on. My daily phone has lineageos (I'm using it), which is an existence proof that you can run a kernel of your choice and userland of your choice, and my previous one had something called treble, which I didn't look into but also involved supplying your own kernel and userland.
If you have the ability to run a kernel and userland of your choice, what can't you do? I know something you can't do: applications that require much electric power. And something else: applications that require many people (or even everyone) to run the same software. But really, if there were to be some sort of cambrian explosion it ought to show up on my daily phone or one of the many similar ones.
you need critical mass for things to happen. for critical mass you need a reasonably open migration channel. for that you need a combination of device manufacturers and open source communities to make it easy to drift in and out from this space (the dual-boot equivalent)
So... we need critical mass without early adopters, because the things to invent will be created only after critical mass is reached? I think you're just inventing excuses: "There would be a Cambrian explosion of new uses cases, were it not for (excuse goes here)".
> the things to invent will be created only after critical mass is reached
yes, what is so strange about this? Lets check some numbers [1]. Total active installs on the planet: 4 mln. So something like three orders of magnitude less than existing mobile devices in use. Further, there is large dispersion geographically. The majority (when country is known) in China while Vietnam is next. 200K devices in the US. 160K in Germany.
Next, there is a tiny number (< 4000) of open source android apps [2].
The idea that this miniscule ecosystem has explored everything there is to explore is just bizarre. Breakthroughs that change people's perception of what role a platform can play are not just there for the plucking. You need trial-and-error, feedback, iterations etc.
> you're just inventing excuses
I think you are just bragging ("If I could do it, why don't you").
If you want to continue arguing you need to adress my dual-booting point. Would linux ever get anywhere if you could not dual-boot on Wintel?
I was an early adopter of linux; single-boot in August 1992. Not because of anything that would happen only after some future threshold, but because it was worthwhile for me when I did it, at the time. The motivation was in the present, not in the far future.
So I'm an early adopter. </bragging> So what. I still say that the advantages are described in vague terms like "cambrian explosion" and are supposed to arrive much later, that means those advantages don't exist.
EDIT: Actually, let me put that differently. If you posit something impossible, then any consequence is possible: If pigs have wings, then anything is possible. The consequence ("cambrian explosion of uses" or whatever) are meaningless if they depend on an impossible condition. So it's necessary to show that the condition isn't impossible, see? So what could the possible but currently unmet condition be? I'm sure it's not an unwillingness to produce a phone that'll sell to 10% more users than the last phone. Your other part was the existence of an open source community. There is one that serves the current users, what's stopping the next 10% of growth? What I'm saying is that they have to be install because of current reason, not because of a future Cambrian explosion. So name it or argue that it plausibly exists. Naming only something vague in the distant future is tantamount to saying that it doesn't exist.
> which is an existence proof that you can run a kernel of your choice and userland of your choice
Isn't LineageOS dependent on the original kernel of the phone for blobs? My understanding is that the device specific downloadable versions have just already had that RE work done for you instead of requiring you to do it.
fingers crossed that they get traction but lets face it somehow the economics is stacked against these projects (there was also firefox OS which I once owned and ubuntu touch etc.)
after all the effort of the communities and companies involved, 0.1% adoption of something so differentating as an open source phone is "not normal"
even if you consider this delusional idealism we are not that few :-)
215 comments
[ 6.0 ms ] story [ 324 ms ] threadjust-js holds spot 5 of TechEmpower web framework benchmark round 21.
https://www.techempower.com/benchmarks/#section=data-r21
This seems like paying more upfront and paying more per month for less.
I'm rocking a two node cluster in Hetzner. One is an old 1vCPU small that costs over $3/month, and the other is a new 2vCPU addition that is a dash over $4.
I pay for two ipv4 external IPs which costs more.
Also, Hetzner started to offer ARM64 nodes that are even cheaper.
Yes, Pinggy Pro is more expensive than operating your own nodes in Hetzner.
Altruism?
Hoping to help startups?
How do they gain?
And yeah, I'm hosting my blog on Cloudflare. Very nice for a free service. Just hoping that the economic downturn isn't gonna turn off the tap on services like Cloudflare Pages.
But considering the amount of RAM current phones have, compared to what you get with a cheap VPS, there might be a benefit of running it on the phone.
> This Blog is hosted on my Android phone
> Click link
> 101: ERR_CONNECTION_RESET
Yeah, that went about as I expected...
Because in a real country you always have blind spots, even in relatively easier points such as the Netherlands (flat and populated)
I have always been confused how some countries have such bad coverage. Before Wi-Fi Calling, it was a nightmare to be inside any apartment building I've been to.
The CPU in the Pixel 6 for exemple, is equal to a 2012 intel cpu server: https://www.cpubenchmark.net/compare/5349vs1193/Google-Tenso...
https://pinggy.io/blog/host_website_on_android/
Of course it is.
Louwrentius uses 29W? Do I read it correctly? [1]
[0] https://solar.lowtechmagazine.com/power.html
[1] https://louwrentius.com/
You can: https://userland.tech/
Are you one of the developers? As I'm really curious how this works.
Honest question. Why? How is Android not fulfilling your needs as a full Linux distro? Are there any features that you would like to see added, or do you feel that apps for what you want are not currently available?
I suspect that trying something like that on Android will be a long road with lots of caveats, even if possible, learning to do all the things the new "Android" way. Am I wrong?
I mean there's a lot of things that make life difficult with Android.
* If you want most hardware to keep on working, no kernel updates are possible after the manufacturer ends support.
* Root support and service managers need to be installed aftermarket using the unofficial solution Magisk.
* No vendor kernel out of the box supports kernel compile time flags to enable the infrastructure to run Linux containers using Docker, Podman or LXC.
* Self-invented file hierarchy with a lot of restrictions that make sense from an Android UI perspective but are prohibitive when used as a regular distro.
* Since Android and drivers use bionic libc, it's not possible to run regular Linux binaries that tap into certain hardware features like Vulkan without reworking and recompiling them.
Just from the top of my head, there's a bunch of other things people could name I'm sure. Android misses a lot of the expectations people have for regular GNU/Linux distributions have - expectations that non GNU/Linux distros like Alpine do meet for the most part.
Yes, this is a problem and it is trying to be addressed by generic kernel images which should make it so that you no longer need to build a device specific kernel as all of the device specific stuff has been modularized.
https://source.android.com/docs/core/architecture/kernel/gen...
>Root support and service managers need to be installed aftermarket using the unofficial solution Magisk.
Root should not be necessary and these break Android's security model. Perhaps there is an operating system API that could be added that could provide the features you are looking for while keeping the system secure.
>No vendor kernel out of the box supports kernel compile time flags to enable the infrastructure to run Linux containers using Docker, Podman or LXC.
Android apps already have their own sandbox. It would be better to develop apps than docker images as darker images don't really follow the Android security model as well. What you want should be possible with Android 13 allowing for kvm.
>Self-invented file hierarchy with a lot of restrictions that make sense from an Android UI perspective but are prohibitive when used as a regular distro.
Why care about a file hierarchy? NixOS does away with it and seems to get along fine. Apps shouldn't rely on it.
>Since Android and drivers use bionic libc, it's not possible to run regular Linux binaries that tap into certain hardware features like Vulkan without reworking and recompiling them.
Most people run apps and not binaries. It is going to need to be reworked anyways.
Android is highly opinionated to work as a platform for apps on touchscreen devices, but those opinions do add a lot of restrictions compared to other things built on Linux.
Likewise, I don't want to have to package all my stuff as apps. If I already have a docker container and I wish for it to be ran on my device I think that there shouldn't be another barrier. Android security model? Why do I care about that? I have a device and I want to run my software on it. It's as simple as that.
For example, android makes it difficult to run userspace containers, like lxc or docker, which also limits what orchestration and deployment systems you can use (since some make very strong assumptions about being able to use containers).
Similarly, various different pieces of server software just won't work because they make use of some linux feature android intentionally builds its kernels without for security reasons.
Not so useful for something that might end up on HN and go down.
Could also put a CDN infront to lighten the load on the upstream but guess what, now you're not just hosting on your phone anymore and might as well use other cloud services where often you can host more for free than a phone can handle
androidblog.a.pinggy.io is pointing to a AWS IPv4 address, I don't know why the creator did not do this.
I have also tried out direct access to my phone via public IPv6 and it works really well, although the prefix is not static.
Android does not allow running server on ports below 1000. With above DNS trick one should be able to host a server on non standard port of Android without funny looking URL. We don't even need a third party like pinggy as in OP's case which might be resetting connection to OPs phone.
So far I have tried to configure my local network DNS server to respond using above records but it's not working for some reason.
In theory we could've had this decades ago if browser respected SRV records, but alas.
> You are a web DevOps expert. Provide a list of ten concise combinations of software stack and hardware, starting from "budget hosted VPS website, heavy caching, and dynamic DNS with outside cache" and ending with "Android phone at home on standard connection using third party dynamic DNS and basic web server". Each combination should get more homebrew until that final Android one.
There's some room for prompt improvement but the ideas in the result were an interesting read (In place of the linked website which I couldn't read of course).
For one, the list seemed way more fun, or the projects easier to maintain for a single person, when I specified "web hobbyist" as compared to DevOps expert... though I know there really are people out there who are _definitely_ looking forward to maintaining enterprise software on the weekends...
1. *Budget hosted VPS website, heavy caching, and dynamic DNS with outside cache* - Software: Nginx, Varnish, PHP-FPM, MySQL - Hardware: Entry-level VPS, 1 vCPU, 1 GB RAM
2. *Shared hosting with CDN and dynamic DNS* - Software: Apache, PHP, MySQL, Cloudflare CDN - Hardware: Shared hosting plan, 1 GB RAM
3. *Raspberry Pi with LAMP stack and dynamic DNS* - Software: Apache, PHP, MySQL, ddclient (for dynamic DNS) - Hardware: Raspberry Pi 4, 2 GB RAM
4. *Self-hosted containerized web stack with dynamic DNS* - Software: Docker, Nginx, PHP-FPM, MySQL, Traefik (for dynamic DNS) - Hardware: Home server, 2 cores, 4 GB RAM
5. *Home server with reverse proxy, caching, and dynamic DNS* - Software: Nginx, PHP-FPM, MySQL, Varnish, ddclient (for dynamic DNS) - Hardware: Home server, 4 cores, 8 GB RAM
6. *Self-hosted web stack on a NAS with dynamic DNS* - Software: Apache, PHP, MySQL, Synology DDNS (for dynamic DNS) - Hardware: Synology NAS, 2 GB RAM
7. *Old laptop as a web server with dynamic DNS* - Software: Apache, PHP, MySQL, No-IP (for dynamic DNS) - Hardware: Old laptop, 2 cores, 4 GB RAM
8. *Self-hosted web stack on a mini PC with dynamic DNS* - Software: Nginx, PHP-FPM, MySQL, DuckDNS (for dynamic DNS) - Hardware: Intel NUC, 2 cores, 4 GB RAM
9. *Web server on a single-board computer with dynamic DNS* - Software: Lighttpd, PHP, SQLite, Afraid.org (for dynamic DNS) - Hardware: BeagleBone Black, 512 MB RAM
10. *Android phone at home on standard connection using third party dynamic DNS and basic web server* - Software: KSWEB (web server), No-IP (for dynamic DNS) - Hardware: Android phone, 2 GB RAM
it was kind of interesting to me that archive.ph sent me the images slowly, as if they weren't archived but were coming straight from somebody's phone...
In a sense these projects prove the obvious yet hidden-in-plain-sight: the vast numbers of mobile computing devices that have circulated since the "iPhone moment" could be reconfigured in all sort of ways to be more than a dumb touch screen client for scrolling down social media pages.
If we ever get to see a true open mobile OS there might be a Cambrian explosion of new applications and use cases. Not holding my breath though. The failure of open source mobile to reach a workable stage is now pretty clear. It seems this domain is TITO (too important to open).
Lots of phones are open enough to install lots of things on. My daily phone has lineageos (I'm using it), which is an existence proof that you can run a kernel of your choice and userland of your choice, and my previous one had something called treble, which I didn't look into but also involved supplying your own kernel and userland.
If you have the ability to run a kernel and userland of your choice, what can't you do? I know something you can't do: applications that require much electric power. And something else: applications that require many people (or even everyone) to run the same software. But really, if there were to be some sort of cambrian explosion it ought to show up on my daily phone or one of the many similar ones.
yes, what is so strange about this? Lets check some numbers [1]. Total active installs on the planet: 4 mln. So something like three orders of magnitude less than existing mobile devices in use. Further, there is large dispersion geographically. The majority (when country is known) in China while Vietnam is next. 200K devices in the US. 160K in Germany.
Next, there is a tiny number (< 4000) of open source android apps [2].
The idea that this miniscule ecosystem has explored everything there is to explore is just bizarre. Breakthroughs that change people's perception of what role a platform can play are not just there for the plucking. You need trial-and-error, feedback, iterations etc.
> you're just inventing excuses
I think you are just bragging ("If I could do it, why don't you").
If you want to continue arguing you need to adress my dual-booting point. Would linux ever get anywhere if you could not dual-boot on Wintel?
[1] https://www.lineageoslog.com/statistics
[2] https://en.wikipedia.org/wiki/F-Droid
So I'm an early adopter. </bragging> So what. I still say that the advantages are described in vague terms like "cambrian explosion" and are supposed to arrive much later, that means those advantages don't exist.
EDIT: Actually, let me put that differently. If you posit something impossible, then any consequence is possible: If pigs have wings, then anything is possible. The consequence ("cambrian explosion of uses" or whatever) are meaningless if they depend on an impossible condition. So it's necessary to show that the condition isn't impossible, see? So what could the possible but currently unmet condition be? I'm sure it's not an unwillingness to produce a phone that'll sell to 10% more users than the last phone. Your other part was the existence of an open source community. There is one that serves the current users, what's stopping the next 10% of growth? What I'm saying is that they have to be install because of current reason, not because of a future Cambrian explosion. So name it or argue that it plausibly exists. Naming only something vague in the distant future is tantamount to saying that it doesn't exist.
Isn't LineageOS dependent on the original kernel of the phone for blobs? My understanding is that the device specific downloadable versions have just already had that RE work done for you instead of requiring you to do it.
https://avilpage.com/2018/02/deploy-django-web-app-android.h...
PinePhone and Librem 5 are already here, both running various GNU/Linux flavors.
after all the effort of the communities and companies involved, 0.1% adoption of something so differentating as an open source phone is "not normal"
even if you consider this delusional idealism we are not that few :-)
So many possibilities have been crushed.