samtheprogram's comments

On: OpenCode – Open source AI coding agent

[samtheprogram]

Definitely not Wayland related, or so I doubt. I'm on wayland and never had any issues, and it's a TUI, where the terminal emulator does or does not do GPU work. What led you to that conclusion?

[lairv → samtheprogram]

This issue: https://github.com/anomalyco/opencode/issues/9505

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

[Yokohiii → lairv]

https://github.com/anomalyco/opencode/issues/14636

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.

[samtheprogram → lairv]

That is wild. Thanks for the info.

[dboon → lairv]

There's a desktop app which uses Tauri. Unrelated to the TUI.

On: Bringing Chrome to ARM64 Linux Devices

[samtheprogram]

I'm confused, how does Chrome work on ARM64 Android phones today?

[danans → samtheprogram]

The reason they didn't release Chrome for arm64 Linux almost certainly wasn't about technical feasibility, but rather about it being worth the support costs.

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.

[oofbey → danans]

Support? This is Google!

[danans → oofbey]

Support in this context means bugfixing, performance/crash testing across devices and chipsets, security updates, etc, not "phone/email support".

[vinkelhake → samtheprogram]

This is "just" about providing the official Chrome binary to ARM64 "desktop" Linux.

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.

[westurner → samtheprogram]

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

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?

[mort96 → westurner]

A fully statically compiled Linux ARM64 binary which only interacts with the kernel through syscalls should run no problem on ARM64 Android. From the kernel's perspective, there is no difference between a "Linux binary" and an "Android binary" because the kernel in Android is Linux.

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.

[westurner → mort96]

Why is it easier to run a Linux ARM64 binary on Android than to run an Android ARM64 binary on Linux?

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

[mort96 → westurner]

I don't know what you mean by an "Android ARM64 binary". If you make an ELF file containing ARM64 machine code, it doesn't matter to Linux whether you meant for it to run on Linux in an Android system, on Linux in a desktop GNU system, or on Linux in some environment with without much of a userspace at all (such as a stripped down initramfs environment).

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.

[westurner → mort96]

.

  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 {} \;

But go binaries don't require (bionic) libc unless you compile with CGO_ENABLED=1

[pjmlp → mort96]

Only if they restrict themselves to the officially supported syscalls, otherwise Android will kill the application.

[hugs → samtheprogram]

they probably meant desktop. i do browser test automation (selenium, vibium), and the lack of google chrome on arm64 trips up new users frequently. the workaround is to just use chromium, but that's a confusing extra step for some if it's not automated and hidden for you.

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.

[kelvinjps10 → hugs]

Don't most people use chromium instead of chrome anyways on Linux?

[hugs → kelvinjps10]

most people just click the "internet" button and use whatever was already pre-installed.

[kelvinjps10 → hugs]

I meant Linux users and chromium is the one that's already in the repos and doesn't need extra work. The default browser in most distros is Firefox

[drnick1 → kelvinjps10]

Yes, and the last thing we need is Google's cancer spreading to Linux.

[bloomca → samtheprogram]

Maybe Android has its own libc? So they compile it for Android, but not for general Linux.

Also curious about this.

[westurner → bloomca]

Android's libc is called Bionic.

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

[hparadiz → samtheprogram]

The Chromium project builds many things. The Android version is just one of those things.

[CJefferson → samtheprogram]

It required custom glibc patches, and getting videoes to work required some kernel stuff as well.

This is a combination of getting stuff merged upstream, and removing the need for some more specialist features.

On: Create value for others and don’t worry about the returns

[samtheprogram]

He deletes posts after they are no longer relevant. Given how people dig dirt up on people and take them out of context long after that context is forgotten, more people should do that (or delete social media altogether).

On: GPL upgrades via section 14 proxy delegation

[samtheprogram]

Linus never cared about that use case of the GPL. He cared about the source code sharing.

On: Welcome (back) to Macintosh

[samtheprogram]

Tangeltial, can we still run custom Darwin kernels? IIRC that was blocked under security pretenses.

On: Meta’s AI smart glasses and data privacy concerns

[samtheprogram]

And?

On: How we rebuilt Next.js with AI in one week

[samtheprogram]

The irony of this in the README:

- Node.js production server (vinext start) works for testing but is less complete than Workers deployment. Cloudflare Workers is the primary target.

On: Apple patches decade-old iOS zero-day, possibly exploited by commercial spyware

[samtheprogram]

And now everyone else is aware of it too... including anyone marginally above a scriptkiddie.

On: Why E cores make Apple silicon fast

[samtheprogram]

Catalina and Mojave were the closest releases in terms of quality that we got to Snow Leopard. Catalina in particular since it was the release that removed more 32-bit cruft (like Snow Leopard before it).

On: Solving Shrinkwrap: New Experimental Technique

[samtheprogram]

I came to say something similar; on Android Firefox, scrolling on the page is stuttery.