I used this napkin math for image generation, since the context (prompts) were so small, but I think it's misleading at best for most uses.

EDIT: asking because I've been working on an alternative of sorts. I used GV a lot before I figured I could go without it/Google.

And, possibly most importantly to me right now, my current phone has only a data connection and I make and receive calls using the Voice app. I think SIP eats too much battery and data and doesn't work well for wifi<->lte switching, but it's been a long time since I used it much.

I previously looked at jmp.chat but they didn't really inspire confidence on the security front.

I like the muti-platform integration of Voice. I use it on my iPad, on my Android phone, and mostly from my desktop. It works well on all platforms.

When I'm at home, I mainly use my VoIP phones. GV forwards to them, and they spoof my GV numbers when I make outgoing calls.

I like the spam text and call protections that GV provides. I believe they're partnered and integrated with Nomorobo.

I also have jmp.chat. It has capabilities that GV doesn't have, but it's not well integrated. (I use Cheogram on my Android phone, but there's no easily usable client on my iPad, or my desktop.)

Yeah and imo Google has better account access controls than any other mobile provider, especially if you enroll in the Advanced Protection Program.

The main downside of GV that I didn't have with jmp.chat is that numbers are almost guaranteed to be detected as VOIP which sucks but whatever.

I'm regularly switching back to 4.5 and preferring it. I'm not excited for when it gets sunset later this year if 4.6 isn't fixed or superseded by then.

I rarely use the Dock, it's somewhat eye candy I leave up, or add stacks for folders that I use, but typically for keyboard action I reach for spotlight (cmd+space). Now, spotlight occasionally shitting the bed, that's another issue...

And then the official docs: https://opencode.ai/docs/troubleshooting/#linux-wayland--x11...

> Linux: Wayland / X11 issues

> On Linux, some Wayland setups can cause blank windows or compositor errors.

> If you’re on Wayland and the app is blank/crashing, try launching with OC_ALLOW_WAYLAND=1.

> If that makes things worse, remove it and try launching under an X11 session instead.

OC_ALLOW_WAYLAND=1 didn't work for me (Ubuntu 24.04)

Suggesting to use a different display server to use a TUI (!!) seems a bit wild to me. I didn't put a lot of time into investigating this so maybe there is another reason than Wayland. Anyway I'm using Pi now

That issue points out that it is probably a dependency problem.

The other problem is that they let a package manager block the UI and either swallow hard errors or unable to progress on soft errors. The errors are probably (hopefully) in some logs.

A dev oriented TUI should report unrecoverable errors on screen or at least direct you to the logs. It's not easy to get right, but if you dare to do it isn't rocket science either. They didn't dare.

The Android arm64 Chrome build is clearly worth it to them, as is the Chrome build for ARM Chromebooks.

Before this point they probably didn't think that arm64 Linux was a worthwhile target to support (especially since Chromium was available on arm64 Linux anyways).

I'm not sure what has changed in the desktop/laptop ARM Linux market that changed their minds - or maybe they want to put their shoulder behind that market.

You've been able to build and run Chromium on ARM Linux for a long time (I'm running it right now), it's just that they haven't provided an officially branded Chrome.

This is a good thing. While Chromium works well, there are a few things (like syncing) that is a bit of a pain to set up.

To run conda-forge arm64 Linux binaries on Android in termux requires proot-distro because the ABIs are slightly different FWIU.

What is necessary to run Android ARM64 binaries on Linux ARM64?

Android Studio, LineageOS or BlissOS's outdated Android containers, a runtime like vinegarhq/sober that emulates just enough of Android.

An Android binary that makes Linux compatible syscalls only (that doesn't require Android libraries that aren't compiled for Linux) won't work will it?

Most programs want to interact with various system libraries and system services though. Android and your typical desktop Linux system share pretty much nothing aside from the kernel.

My guess is that the reason is the same reason that there aren't official updated Android containers

If you mean something like an Android app, the answer is that there's a ton of system stuff that the app depends on, it interacts with more than just the kernel.

  CC= clang
  CXX=clang++
  $CC hello.c -o hello_android_c
  $CXX hello.cpp -o hello_android_cpp -static-libstdc++
  $CXX hello_asm.cpp -o hello_android_cpp_asm_syscalls_only -ffreestanding -nostdlib -fuse-ld=lld
  find -name hello_android -exec readelf -l {} \;

on that note, it would have been nice if they also clarified if this means they'll be shipping an official "chrome for testing" for arm64 linux, too.

Also curious about this.

Bionic (software) https://en.wikipedia.org/wiki/Bionic_(software)