It still exists! (Or did about a year ago).
When I got my first Android (2009 ish), I searched high and low for a way to run Hamachi on it. There have been solutions, but always clumsy and difficult to implement.
I miss Hamachi, it was so simple to use.
Well, fuck yea, of course it would have to, as it’s part of the history!
(Just watched the Pentaverate, and the bar scene comes to mind, where everyone is cussing their brains out).
Tailscale is wireguard (it uses the wireguard protocols, even says so on the box), just with a centralized resolver to make things easier to setup and manage.
I’m not sure what you’re saying with the rest of your comment, as Tailscale is a mesh network, not a VPN as most people think of it.
It encrypts your traffic, but only into the network of which your device is a member. You can’t even see any devices, or networking, outside the Tailscale network, unless a device is configured as a Subnet router. Then you can see devices in the network which the Subnet Router links together.
For example, you have 3 machines, a laptop on mobile data, and 2 desktops on your home LAN. One desktop and the laptop have Tailscale, they can communicate over Tailscale to each other, but the laptop cannot connect to the second desktop because it’s on a different network, since there’s no routing between Tailscale and your home LAN.
You then configure Subnet Routing on the desktop that has Tailscale, now your laptop can connect o any device on the home LAN, so long as the desktop is running and Tailscale is up.
Think of mesh networks as Virtual LANs in software, configurable on each device (mostly, sort of). Twenty years ago Hamachi was the go-to for this, it was brilliant, and much easier to use than today’s mesh networks, just far less capable/manageable/configurable.
I’d consider 5% to be trivial, for what it does.
My battery consumption really depends on how much traffic I send over it.
The fork is much better anyway.
It moves the sync options into each sync folder/job. Lots more flexible. Now my photos sync on any network and any charge state, while less important things (downloads, etc) only sync when on WiFi and charging.
Only updates it should need are for weird changes Google decides to make to Android.
Hell, at this point if someone forked the fork, and charged a small fee for the Relay Server hosting, I’d happily pay.
It definitely gets better once it’s all caught up.
But it’s still much harder on battery than ST when folders have changes.
It’s kind of not Foldersync’s fault, it’s really because of the protocols - it’s all connection-based, and FS has to compare each file at sync time.
Syncthing keeps an index so it knows what files have changed. Very different tools with different use-cases and approaches.
I used FS for years until I found ST, and had to do a lot more tweaking to get sync to work the way I wanted with FS. FS doesn’t have sync conditions like ST, so I had to use Macrodroid to trigger it when on WiFi, for example.
FS can be a solution, it’s just a lot more work for anything beyond basics.
It’s stupid easy to setup, even has a built-in photo backup job.
I use Syncthing-Fork because it moves all the sync conditions into each job.
So my photos sync regardless of charging state or network (I’m willing to pay for the data to ensure photos are instantly synced). While other things only sync while on WiFi and charging (e.g. Neobackup).
Only one I can think of is Resilio, but it’s hard on RAM and battery for large folders.
That takes a lot more effort.
With Syncthing, I don’t have to setup a server, poke holes in my firewall/expose ports, etc.
Plus Foldersync is way harder on battery, I’ve experimented a lot.
And I’ve used Foldersync since at least 2010 - it’s great, really has it’s uses.
Maybe I’m misremembering, but I thought they used Syncthing as part of a business not directly related to Möbius - as a vendor supplying data management solutions to other companies. I suspect Möbius came out of need for their clients.
I can picture the vendor website in my head, just wish I could remember who it was for sure.
I would eagerly pay for syncthing, it’s that important to me. I keep hundreds of gigs moving around using it. It’s on my annual donate list already, but clearly that’s insufficient.
Maybe the Syncthing-Fork dev will keep it going.
iOS is already more restricted on app sandboxes, and Möbius can handle it in the paid version.
On Android, Resilio somehow has more file access than Syncthing, even without root (it can read/write to either SD card root, while Syncthing can only write to a subfolder of SD0, and can’t write anywhere of an external SD). So there’s something going on.
I can only hope the company makes the iOS client (Möbius) decides they need syncthing to continue and decide to get behind it.
As I recall, they use Syncthing as a solution in their business, this would be a big-break for them.
And yet Resilio can access a lot more than ST, even without root.
It can do sync jobs in a very similar way as syncthing.
But I find Resilio to use more RAM because it stores the file DB in RAM. This kills a phone, but isn’t a big issue for a desktop.
Thanks, it’s been a while.
The 90’s? Locked bootloaders would’ve meant people woukdve simply bought different machines without a locked bootloader.
See the IBM/Phoenix BIOS war - it’s essentially the same thing. IBM didn’t want to license their BIOS to everyone, so Phoenix reverse engineered it. If I remember right, IBM was trying to lock everyone to using their OS.
Early Android (circa 2009) didn’t have locked bootloaders.
Google wanted people to experiment, which was basically free research for them. Pixel’s today are unlocked when purchased from Google.
Even my earliest Verizon phones weren’t bootloader locked - they didn’t start doing that for a few years (my last Verizon phone in 2012 wasn’t bootloader locked). And Verizon is arguably the worst vendor when it comes to bootloader locked phones.
That just sounds painfully inefficient (though we’ve been doing stuff like this for decades).
Arm isn’t as efficient at higher cpu states as x86, and running a VM you’re definitely going to up the cpu usage.
Still interesting to watch. And every use-case is unique. For the typical short-run process this is for, it’ll probably be fine.
Well, it is.
It’s a lot more work to use not-Google stuff on Android. Which I try very hard to do.
Now trying to get a family member to install and run anything not from the Play store is like pulling teeth.
Proton sucks.
I had an account, way too many problems. Apps sucked ass.