If you want the Linux-circa-2004 experience back, just try Linux on ARM!

* everything compiles slowly
* distro-hopping to find better hardware support
* oops, you need proprietary drivers for that
* forum posts hold the authoritative documentation *and* code for your distro


@brion let me introduce you to BSD on ARM... *weeps*
@Clifford @brion yeah, but sometimes you don't get to pick which BSD you want to run on it
@cuniculus @Clifford @brion iOS is not BSD; iOS/MacOS is Darwin/XNU microkernel which has a *few* BSD components to make it not a scary weird Unix

The main issue with ARM is that there is no such thing as an ARM standard until aarch64. ARM is basically a devkit. Legos. The Erector Set.

You, as a business, take all these different components and glue them together and have the ARM chip fabricated. You may choose to throw away some instructions, use different generation cores, make whacky decisions like "everything is on a USB bus" and "the GPU bootstraps the CPU!".

Every ARM device/chip until recently needed to be treated like a completely different target. The only thing they shared were three letters: A R M

Thankfully these days are nearing an end, and we can have some sanity. But that's basically why the BSDs looked at this and said "fuck that, we aren't going to put that into our kernel".

Except NetBSD. Those guys... are very comfortable with Stockholm Syndrome. And they're good at wielding it.

@brion Hey I didn't realize the similarities until now! That means I can hope for much better support in the future, I guess. Yay!

@brion can confirm. I got keybase to work sans gui by beating the hell out of things, fought like hell to get Riot working (had to scrounge precompiled Electron), and had to accept a severely downrev Nextcloud client.

@halcy @brion did you know that Linux is literally the only Linux where the 32 bit variant doesn't fix the Y2038 time_t bug?

@brion @hirojin okay now tell me how the X support is. Do I get to hand edit config files?

@james @hirojin I managed to bork a system by changing desktop login managers and had to log in from recovery to re-configure it back. Does that count? :D

@brion Don't forget trying a lot of compiler flags to get a few more FPS out of the quake engine :D

@brion As someone using an Linux ARM laptop as their daily-driver, it feels like all of those points are 100% true.

Also, another issue I've encountered a lot is being forced to use a 32-bit kernel/userland on 64-bit hardware.

I bought a pi4 4gb to use as my home server and after I saw that the most newer raspbian isn't 64 bits I saw that I'll do a lot of distro hopping on it

@kumicota @Kat @brion it has an aarch64 kernel i think as in 64bit kernel
@blobyoumu @Kat @brion I don't mind to use arch there but I don't wanna to have to install everything on it so maybe I'll use some arch based distro on it
@kumicota @Kat @brion aarch is 64bit arm iirc, i didn't tell you to install arch xd
@kumicota @Kat @brion depending on what you want to do on it you could install gentoo and it would be 100% for sure aarch64 well with - march=native
@blobyoumu @Kat @brion I never used gentoo so I'll needed to learn how to do it before. But IIRC there's a way to use a 64bit kernel on raspbian and Manjaro is stable on it
@kumicota @Kat @brion oh right i am almost sleeping, didn't clarify that it is probably in repos or you have to enable the repo.

@brion bonus: download random binaries from random websites on the Internet put there by random people to run on your hardware like it‘s 1996!

@brion the good ole days of isapnp and printer drivers.. the nostalgia!

@brion Well my experience with running gentoo (with musl) on my BananaPi was fine, except for most recipes being non-stabilized it's the same as running on a bit slow x86.
I think *BSDs are fine too, tbh most distros sucks at portability and actual stability.

@brion I used the Raspberry Pi 3 as an actual desktop two years ago. At least the uniform platform made hardware support more easier.

@brion this just sounds like my experience with every type of BSD
@brion except replace "oops, you need proprietary drivers for that" with "oops, no drivers exist for that"


Or simply forget about Arm SBC and move to Arm64 servers. Just work with any sane distro and your account is much lighter as they cost insane money ;D

@brion I've always argued that ARM needed to deliver a coherent developer platform on laptop. Laptop is where development happens and in turn drives what cloud you push it too. But ARM blew it some years ago, and if you do the maths on watts/core for an AMD EPYC I suspect ARM have now missed the bus entirely thanks to the Intel / AMD fight forcing real competition in the x86 space. AMD also need to sort their laptop story out to get more cloud traction though IMHO.

Sign in to participate in the conversation
Mastodon for Tech Folks

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!