This blog is hosted on my Android phone
androidblog.a.pinggy.io
androidblog.a.pinggy.io
Also, if you're looking for similar tools to pinggy, I maintain a list here[1].
Q: "How will it handle scaling to millions of users?"
A: "By crashing. But it will handle 100s or maybe even 1000s, and you currently have 3, so chill."
If your 3 users cannot read your blog then good luck getting to 10 users.
We need less reliable systems, not more.
I mean, that's why a mobile phone is being used, no? Because otherwise, a Raspberry Pi would suffice and would be cheaper and more reliable.
No signal for more than fifteen minutes every day? That must be frustrating.
But there are other factors such as battery dying or just dropping the phone.
Neither of these has happened to me. If they did, the uptime of my personal blog would be a much lower priority than fixing that problem. It's a blog, not a business.
Imagine a distributed social network where updates come via email. Updates are identified by the email client (or other) and automatically sent to whatever program needs to process them. You end up with a local copy of everyones stuff that is kept for a period of time.
For some applictions, it is simple to fallback or use always and luckily the basics are included. Unfortunately, lots of applications won't work at all and many would have to be rewritten.
At that point I'm not sure if it's functionally different to syncing markdown files to something like S3 or GitHub pages.
In practice this works only for trivial apps, that have no dynamic content, don't serve large files, don't see a lot of traffic, doesn't come from all over the world (each PoP has a separate cache), etc. CDN caching is opportunistic, most services assume server-grade hardware at the origin that can take some "warmup" load on its own.
Also if you're introducing a third-party CDN/cache, you're already throwing away a whole bunch of reasons for self-hosting in the first place.
So something exactly like a blog then.
Make websites not apps.
I do agree, let's build websites instead.
Nowadays you find dozen of CDNs. A personal site may be fine without it. If your plan is having an offline version ready to be served, as you expect a lot of downtime, distributed cache might not be the best architecture. Some CDN offer a dedicated layer of cache in front of your origin, but that sounds overkill for a personal blog.
I think I'll pass.
As an alternative to paying a subscription fee for some service, you could instead just have your hardware do enough compute/storage to offset your usage.
Good luck!
I'm not sure it's ideal because if the network partitions you're going to end up with a more or less random assortment of data in your partition. Better for the biology data to end up on the partition with the university that specializes in that and the physics data to end up nearest its users as well. (This may be handled at a higher level, but I haven't gotten that far yet.) Nonetheless, I'm glad somebody is exploring the design space.
I'm not saying they haven't been doing things, but the big decentralized Internet they touted from the beginning still doesn't exist AFAIK.
When I can host a website and have it stay up indefinitely with zero maintenance.. then I think they have something.
I'm sure it's an enormous amount of work and I did buy some coin so I don't mean to be disparaging, but I stopped tracking updates after a couple years because it's all been technical mumbo jumbo and they don't seem to be moving the needle. They've had many "test networks" over the years.
In theory the users could just mine filecoin and pay for the service in that, and then I could dispatch storage contracts to the users in ways that ensure that the entire dataset stays pinned, but so far as I know that's not built in. Besides, a spare phone isn't up to the task of mining filecoin (you need a pretty beefy rig).
I think it would be cheaper and simpler to keep the "have you pinned enough data to justify a free premium account?" Logic all together in one place and not introduce the mining process as an intermediary, but not so cheap and simple that every app that does it should have to implement it themselves.
What if you lose connectivity? What if you run out of battery? What if your phone breaks for some reason?
For a blog I really don't see the advantage compared to a free static host.
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).
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 :-)
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.
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.
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?
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.
So many possibilities have been crushed.
You can: https://userland.tech/
Are you one of the developers? As I'm really curious how this works.
Louwrentius uses 29W? Do I read it correctly? [1]
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 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.
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?
- like a raspi, phones are optimized for "always-on" operation, which means they are energy efficient and completely quiet.
- compute power is probably larger than a raspi, or at least comparable, depending how old the phone is.
- unlike a raspi, phones come with lots of additional hardware, such as a battery, touchscreen, microphones, camera, wifi, bluetooth, a cellular modem and various sensors. More modern phones might even come with TPUs or other accelerators.
- there are also a few GB of flash storage.
I think hardware-wise, that's already more than enough for some basic "tinker" usecases, where you mostly need an always-on device with basic LAN and internet connectivity: i.e. IRC bots or servers, webhook targets, pihole, (small) media or Owncloud servers, etc.
Projects which require a camera, microphone, display or bluetooth connectivity might even be a lot cheaper because you don't need any additional hardware.
Things are getting less advantageous when you need additional ports or peripherals, i.e. Ethernet, HDMI/DisplayPort or GPIO pins. You can sort of solve this by using an USB-OTG cable and then connecting various USB peripherals to provide the missing ports. (You could even connect an Arduino to get GPIO pins).
It'll probably not work well with high-bandwidth use cases if everything has to be relayed through a single USB2 port though. That makes it hard for usecases such as router, NAS or media player. Maybe newer phones with USBC would work here though.
The other drawback is that you'll invariably end up with all kinds of proprietary and opaque firmware blobs. I think the best option here would be Fairphone, but even there I'm not sure if they are entirely blob-free.
Nevertheless, I think it's an interesting avenue. Termux seems like a good start, but it's still just a VM in an app. Does anyone know if there are actual AOSP or Lineage distributions for something like this?
Termux is surprisingly native. The thing holding your back is mostly SELinux sandboxing. Termux compiles most of the normal Linux userland, but adapted to use bionic libc and with /data/data/com.termux/files/ as $PREFIX.
If you really want you can run "normal applications/normal distros" that depend on a "normal libc" by using proot, but even thought the performance is bad, it's still not a VM.
You are only stuck with VMs if you want to run, say, x86_64 with qemu or JVM bytecode.
Not sure though if those actually let you route the phone's GPU to a second screen or if they just have a cheap additional GPU built-in.
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.
Because in a real country you always have blind spots, even in relatively easier points such as the Netherlands (flat and populated)
The CPU in the Pixel 6 for exemple, is equal to a 2012 intel cpu server: https://www.cpubenchmark.net/compare/5349vs1193/Google-Tenso...
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.
It's a spectacularly bad idea that lets you serve HTTP (and any other port) directly from your phone without a SSH tunnel. You can also debug your Android with ADB... over the internet.
To allow untrusted access, you'd have to have the ADB port accessible to the attacker, and then intentionally open developer options and tap "pair for wifi debugging", and then enter/scan a malicious pairing code, and then accept the unrecognized public key when the device connected. And if that does happen, there's a persistent notification that a debugger is connected.
> This Blog is hosted on my Android phone
> Click link
> 101: ERR_CONNECTION_RESET
Yeah, that went about as I expected...
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.
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.
Altruism?
Hoping to help startups?
How do they gain?
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.
> 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
Of course it is.
Is this an ad?
https://mobiforge.com/design-development/pamp-personal-apach...
Same issues as faced here, of course.
Then again, actual servers seem more reliable in practice; and decentralised platforms like e.g. pixelfed [1] work well for me for this kind of usage.
[1]: https://pixelfed.org
Is it a self-hosted Mastodon instance, with the sole purpose of hosting your photos (and videos)?
Why is there a reference to AWS, to do the heavy lifting instead of rely on your own server?
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.
NAT is not actual “security”, and a good part of the spirit of the internet died when it became ubiquitous, along with puny asymmetric upload speeds
just-js holds spot 5 of TechEmpower web framework benchmark round 21.
Would be fun to run a Kubernetes cluster out of old Androids :)
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...
EDIT: according to comments it was down earlier, but it's pretty snappy right now, suprisingly
Ok.
"Termux and its plugins are no longer updated on Google Play Store due to android 10 issues and have been deprecated. The last version released for Android >= 7 was v0.101. It is highly recommended to not install Termux apps from Play Store any more."