Saving Energy: Home Server That Automatically Suspends to RAM and Wakes Up Again

I use a USB 3 harddisk for that. Even my 8 year old "home server laptop" has usb 3.2 support which is faster than the disks can do anyway.

But I don't want to pay the spin up price all the time.

Yep. I have a storage server, also with a 5750GE, 128GB ECC memory, 40Gbps (QSFP+, passive DAC), EIGHT 16TB drives off a modern HBA, two 2TB NVME SSDs (mirrored) as a cache/ingest tier, a SATA DOM to boot off of, and a BMC (which alone draws 3.2W).

132TB raw storage organized into 16TB and 64TB ZFS volumes, plus the 2TB ingest/cache tier. Can saturate 40Gbps up and down.

43-44W at the lowest idle state, about 55W with just the 16TB volume spinning. Though with all the memory and the cache/ingest tier, it doesn’t spin up often, and often it’s mostly spinning up just the two-disk volume. So most of the time it is completely silent — not even a fan whirr.

And that provides the bulk storage and backups (plus pushing offsite) to the PCs, a six-node Pi cluster, and those 9W virtualization servers by providing iSCSI volumes. Also lets any new device PXE boot, and if a device has no OS and no configuration, the hardware will self-install, then self-configure after the first boot. A lot of work, but very valuable experience that paid off at the day job.

A lot of VERY deliberate hardware choices to drive power consumption that low, and probably two weeks measuring power consumption of everything. Something people fail to realize that 10GbE Ethernet is rather power hungry if you’re using copper, but if you’re using fiber or (ideally) passive DACs, you can eke out lower latency, better performance, and drive power consumption into the ground. It matters when you consider you pay for that power consumption for 10GbE copper at every single RJ-45 port in the chain between the devices. You can pay < 10W for all the devices in a 40Gbps connection (four ports) with passive DAC, but with copper it’s more like 40-42W.

Android doesn't run apps in a Java VM. At build time, the Java bytecode is translated to DEX bytecode, which is designed specifically for Android. Today, at install time, the Android runtime compiles DEX bytecode to native code. You're probably right about this being true in the early days, but not so much anymore.

I think the power usage difference between Android and plain Linux on the same hardware is mainly due to the way Android aggressively puts the CPU into sleep states and uses timers (etc) to wake it up as needed.

As I see it there's a few missing features, and they need to be solved anyway to make self hosting less painful in general, right now I don't see many good ways to do it at all unless you like stuff that unpredictabily needs maintenance.

Play store needs to be split into provider and interface APIs, so you can add your own repos and still have it work with existing tools.

Remote management needs to be a thing for sure, installing apps is the hard part of that. WearOS does it amazingly, just connected to BT and the host play store does it, but you'd need the split app store to make that work well with open source third party repos.

Automatic updates would be solved by that, just deploy your app on a repo, and update via the play store or your interface app of choice.

Finally you'd have to solve the biggest problem with ANY self hosting as far as I'm concerned, how to handle certs and domains with zero manual IT work(Has to be truly zero, no chance it needs maintenance while you're on vacation).

I've been saying this for a while, we need pubkey-based domains like .onion URLs, but without the onion routing, so there's no dependence on a CA or anything that might be hard to do in a fully automated "Scan the QR and connect" context.

Or, more likely, Google gives you a service.yoursubdomain.google when you buy Google One, and routes stuff ngrok style for you, with lots of spying, because P2P hasn't been their thing so far. Perhaps one of the forks could do it though.

Without eliminating domains and certs, I'll continue mostly ignoring self hosting, I don't want any chance it goes wrong while I'm too busy to fix it, since there's no dedicated support staff, just me.

It would also solve the other half of remote admin, apps could just declare a web interface for admin that you access if you have the secret URL.

Then you'd need some systemd alternative to manage processes. You'd have to be able to say "Start this on boot, restart it on failure, and never clear it out of RAM".

On the hardware side, phones are already close to perfect. Keep the screen and NFC and Bluetooth, for QR based connections and the like, keep the battery as a UPS, but add more USB ports, Thread/Matter, and ditch or downgrade the cameras.

The filesystem probably needs to support snapshots, and Android should get a Full Backup and Restore Provider API to make it easier to back up everything, just the home folder, just one app, just the settings, just the data, etc, to your chosen provider, maybe even with hooks for apps to respond to import and export, so that the state of your app is totally portable and needs only a few clicks to restore from auto backup.

Finally, we need a cpanel-like VPS management tool to migrate your stuff to cloud hosted if you want, that can take backup files, and show you what's on the remote device's virtual screen(Again, so QR stuff works) or at least what's being displayed via some "Admin screen API" if you don't want to drag the full graphics API into it(But keeping graphics all the time seems like a good plan for standardization, and for kiosk type stuff).

And then finally, you'd probably want a some of the features from a normal-ish Linux userland, or as close as you could get, to make porting existing stuff easier, but even without that, I'd say the porting would be worth it.