Imagine this but instead of needing any CLI skills, you just install a "blog" app on the phone, do a quick OAuth2 flow with your domain provider[0] to connect a domain through a tunnel, and you're ready to start posting. This is essentially my vision of the future of selfhosting. We have a lot of work to do, but the technology is all there.
Also, if you're looking for similar tools to pinggy, I maintain a list here[1].
Personal sites don't really need the kind of network stability we've come to expect. It would also be nice to see a move to more offline-tolerant networks for a lot of things.
So are you saying the mobile network you use is absolutely terrible and you have a signal less than 99% of the time, or are you saying that if a blog you read fails to load one out of a hundred times you visit you stop reading it?
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.
>> You know what is offline-tolerant? NNTP and email.
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.
I have been working on idea for generic store-and-forward messaging. Basically, email for everything. The idea is that store-and-forward is more reliable when there are limited or no network. It would also work well for interplanetary communication.
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.
Why is this website hosted in Russia (given current geopolitics), and why does this website have a certificate issued by ca.cypherpunks.ru instead of say Let's Encrypt?
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.
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.
True, but this means your solution is competing with Github pages, Netlify, etc. and your visitors are still subject to the whim of the caching layer. I'm not aware of any classical CDN product that works Great even when the origin server doesn't. Building a CDN for that purpose only would be extremely niche - generic CDNs with a hand-tuned caching policy are great at many other things, such as live video delivery, so you'd be building a non-generic CDN in a saturated market. Then the question of how does the CDN make itself aware of the content it needs to prefetch... once you devolve into that, well you've reinvented git push to Netlify, but with 10x the amount of quirks, oddball architecture, and less flexibility.
If you're building something as complex and convoluted as a blog hosted on a smartphone being tunnelled to the outside world and proxied through a purpose-built CDN, I don't think you can call it a website anymore.
I'm not pushing anything, just haven't seen pass-through proxy that has a similar failure mechanism for when websites are down. They have enough of a market share without me promoting them anyway.
That's a feature of basically any CDN and some existed well before Cloudflare entered the market.
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 would envision something like this being used with an older phone permanently connected to a charger and Wi-Fi or possibly a USB docking station with Ethernet, not running on your personal phone over mobile data. The latter would be terrible for battery life.
I was kicking around a similar idea a few months ago but for a single-user Mastodon instance. Obviously a phone is a huge single point of failure, but there are likely dozens of hobbyist use-cases like this that don’t need strong reliability guarantees.
You know, I read this and got exciting thinking "I could build that!". Then I got to thinking about the security implications of running a webserver on a personal phone exposed to the internet.
It doesn't need to be a personal phone. If you get a new phone, you could do a factory reset on your old phone and use it as a webserver in this way. And since you aren't taking it with you anywhere, you can leave it at home plugged in and on wifi, for better uptime than your regular phone.
What would be really cool is if we could easily share hosting burden of m sites on n devices.
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.
Very disingenuous as they've release many products over the years. With each of these releases they've moved the development of the Safe Network forward. Simply take a look here - https://safenetforum.org/c/development/releases/76/ A test network was just closed and they'll be fixing a couple of things releasing another ASAP.
I've still got some learning to do, but the whole kademlia dht thing is a pretty interesting middle ground between the IPFS approach (not enough redundancy) and the blockchain approach (too much redundancy).
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.
I know that people can use IPFS to voluntarily pin data so that it is redundantly hosted, but supposing there's some paid service that goes with that data, I don't think IPFS helps identify the users that have been pinning the data so that you can offer them the service for free.
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.
You could, but if it's in the app store for the masses to do, most of them won't be, and that's sort of the point of the suggestion here in my mind. Easy self-hosting for the masses with the device they already have.
There are lots of old phones out there, and rather than getting binned it's nice to think of them being put to use. With the exception of the rather young, nearly everyone's had more than one phone in their lifetime, and even an old smartphone is more than powerful enough to run a simple webserver.
I agree with you, but I think your missing my point. If I go and put something like this in the Play/iOS stores, what percentage of users looking to run a small site do you suppose run it on the phone they use everyday vs running it on a wiped old device that they have plugged in in the corner? If you think most will take the proper precautions you have more faith in humanity than I do. Personally, I think even with the somewhat nerdy nature of the app >50% will be running it out of whatever is in their pocket, no matter what kind of warning banner I might put somewhere. And I'm nopeing out of handing that foot-gun to them.
If the app is sandboxed, then it's the same level of risk as browsing the web on your phone. Sandbox escapes are rare enough that the people who find them aren't deploying them against randos.
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).
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 :-)
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.
> 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.
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.
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.
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.
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.
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
>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?
> 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.
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.
I think the idea of using cheap/old Android phones as home servers is exciting, actually. If you compare the hardware with a raspberry pi, the results turn out pretty good:
- 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 seems like a good start, but it's still just a VM in an app.
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.
Note: For USB-C, there already are a number of cheap docks which provide HDMI and Ethernet and can also power the host. The keyword seems to be "USB-C PD hub".
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.
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...
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.
Some telecom providers actually provide a public IP address that maps directly to your phone. You might have to change your APN settings to get one, and it might be dynamic.
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.
That last part scared me! I tend to have ADB debug over USB always enabled on my phone but I'm not in any way enabling debug over wifi now I know this.
Whilst publicly exposing ports from a phone is still certainly scary, for ADB specifically it's actually not as bad as it sounds - wifi debugging requires an explicit & bi-directionally initiated pairing process beforehand (sharing a 6 digit code or scanning a QR code to do so) and then also separately trusting the public key of the connecting computer at the moment when it connects.
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.
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.
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.
> 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. ;-)
If we were using HTTP and not HTTPS, I think this would have survived the HN death hug. It's great in many ways, but it sadly puts a wet blanket on the whole low-powered server thing :-/
I have a music server(Navidrone) running on a similar setup (https://davidhampgonsalves.com/junk-drawer-phone-as-a-music-...) but preventing Termux from being killed is a persistent issue. PostmarketOS seems like the best option but its device support is quite limited.
I like the idea of using a phone for a web server. There could be an app, a simple CMS, a simple CDN. Not much different from social media websites, but maybe more decentralised.
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.
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.
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.
So, just under the drawer full of Pi's and clones, I have another drawer with mediatek tablets and phones, most of them with a broken screen. It's there any progress out there to be able to install armbian/openwrt/whatever linux on them?
postmarketOS is usually leading the way there. I'd check their devices page and see if anyone's got them working yet. Although I think mediatek stuff tends to be harder to support.
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.
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.
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.
Do iOS apps not let you bind a socket TCP/IP port and that's why this couldn't be achieved on an iPhone without jailbreak? Obviously they also don't allow you to have a userspace terminal or access to any of the underlying BSD/OS/Darwin XNU kernel resources
This is a quite nice demonstration of what is already possible these days! The people capable of looking beyond the current limitations understand what the future of a true decentralized internet might/should look like (apart from pinggy requirement). Inspiring. Great job!
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...
This is brilliant! I've kicked around the idea but I've never taken the time to figure out the details. Thank you! I have so many devices lying around and some aren't even fit for women's shelters.
Question is, was the site submitted by the owner as some sort of test, or was it submitted by a "friend" who wanted to show the owner that the idea doesn't work.
"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."
Basically, Google keeps locking down more and more niche computing functions like "file access" and "running subprocesses" that no one would ever want to use, in the name of security.
Also, if you're looking for similar tools to pinggy, I maintain a list here[1].
[0]: https://takingnames.io/blog/introducing-takingnames-io
[1]: https://github.com/anderspitman/awesome-tunneling/