what about https://0.email

I spent the past month "de-Googling" my life after I saw a notice in my Gmail inbox that it was 20 years old. I took a step back and realized just how invested into the Google ecosystem I was. Gmail, Calendar, Docs, Drive, Maps, Keep, Photos, YouTube, FitBit, Android. Basically my entire digital life. My goal was more diversifying than security/privacy, but security/privacy is a really nice bonus.

I ended up going with Proton because they had a good solution for mail, calendar, and drive which I was looking to replace. I set up my custom domain to point to it and have my Gmail forwarding to it - any time I get an email to the old Gmail address I go change it on the website or delete the account altogether.

For Google Docs / Keep, I switched over to Obsidian and pay for the sync there. It's a great replacement for my main use case of Docs / Keep which is just a dumping ground for ideas.

For Google Photos, I now self-host Immich in Hetzner on a VPS with a 1TB storage box mounted via SSHFS. I use Tailscale to connect to it. It took a few days to use Google Takeout + immich-go to upload all the photos (~300GB of data) but it's working really well now. Only costs $10/mo for the VPS and 1TB of storage.

Android I think I'll be stuck on - I have a Pixel 8 Pro that technically supports Graphene but there are too many trade-offs there. Next time I need a new phone I'll take a serious look at Fairphone but I think the Pixel 8 Pro should last a few more years.

My FitBit Versa is really old and starting to die - I ordered one of the new Pebble watches and am patiently waiting for it to ship!

YouTube I'm stuck on because that's where the content is. I have yet to find a suitable replacement for Google Maps - OpenStreetMap is still really hard to use and gives bad directions.

It seems OpenAI acquired Windsurf but is letting it operate independently, keeping its own brand and developing its own coding models. That way, if Windsurf runs into technical problems, the backlash lands on Windsurf—not OpenAI. It’s a smart way to innovate while keeping the main brand safe.

Look for tracing/profiling/binary analysis UIs:

- https://superuser.com/questions/1117466/using-windows-perfor...

- https://github.com/wolfpld/tracy

- https://github.com/WerWolv/ImHex

3D modeling / CAD software:

- Blender/Rhino etc

- Similar for audio you can search for 'DAWs' (https://blog.landr.com/best-daw/)

Many examples on https://x.com/usgraphics/media only some software.

Not on the data side but can be useful just for contrast from todays software:

- https://www.zachtronics.com/wmp-skins/

- https://cari.institute/aesthetics

Unmentioned: there are serious security issues with memory cloning code not designed for it.

For example, an SSL library might have pre-calculated the random nonce for the next incoming SSL connection.

If you clone the VM containing a process using that library, now both child VM's will use the same nonce. Some crypto is 100% broken open if a nonce is reused.

Why do you write “you” as “u” here? I don’t want to be rude, but it’s very jarring to see juvenile txt-speak in a serious discussion.

This seems like a terrible idea. Satellite internet doesn't just cost money; having all those satellites in orbit have real non-monetary costs. They have a huge impact on astronomy, and they increase the probability of accidents which cause space debris.

The current go dependency management is lacking:

- If you want to make a change in one of your dependencies, you have to fork the repository, and in the forked repository you have to textually rename the package to the new name. This makes for abysmal maintenance and unneeded merge conflicts if you want to maintain parity with upstream code.

- There is the go replace directive, but this does not transitively apply to dependencies of the module that declares the go replace directive.

- If your patch gets into the upstream repository, now you have to undo the forking (again via a large textual rename).

- If a dependency of your code and your code both depend on the same package, you are forced to take one version per binary that gets compiled. This is just plain absurd and leads to situations where you cannot bump the dependencies independently. If you have a tree of these dependencies, you must update each dependency in the order that respects the dependency tree. This sort of defeats the purpose of specifying and locking the dependency version.

- Overall, go was designed for a mono-repo in a company (Google) that does not version their software (everything runs at tip), and it shows in any type of effort that attempts to re-use software in non-trivial fashion, with distributed development that happens at different rates in different repositories.