Follow

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

:D

@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!

@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 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"

@brion

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

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!