PAPPP

That’s credible.

I find the hardware architecture and licensing situation with AMD much more appealing than Nivida and really want to like their cards for compute, but they sure make it challenging to recommend.

I had to do a little dead reckoning with the list of supported targets to find one that did the right thing with the 12CU RDNA2 680M.

I’ve been meaning to put my findings on the internet since it might be useful to someone else, this is a good a place as any.

On a fresh Xubuntu 22.04.4 LTS install doing the official ROCm 6.1 setup instructions, using a Minisforum UM690S Ryzen 9 6900HX/64GB/1TB box as the target, and after setting the GPU Memory to 8GB in the EFI before boot so it doesn’t OOM.

For OpenMP projects, you’ll probably need to install libstdc++-12-dev in addition to the documented stuff because HIP won’t see the cmath libs otherwise (bug), then the <CMakeConfig.txt> mods for adapting a project with accelerator directives to that target are

find_package(hip REQUIRED)
list(APPEND CMAKE_PREFIX_PATH /opt/rocm-6.1.0)
set(CMAKE_CXX_COMPILER ${HIP_HIPCC_EXECUTABLE})
set(CMAKE_CXX_LINKER   ${HIP_HIPCC_EXECUTABLE})
target_compile_options(yourtargetname PUBLIC "-lm;-fopenmp;-fopenmp-targets=amdgcn-amd-amdhsa;-Xopenmp-target=amdgcn-amd-amdhsa;-march=gfx1035"

And torch, because I was curious how that would go (after I watched the Docker based suggested method download 30GB of trash then fall over, and did the bare metal install instead) seems to work with PYTORCH_TEST_WITH_ROCM=1 HSA_OVERRIDE_GFX_VERSION=10.3.0 python3 testtorch.py which is the most confidence inspiring.

Also amdgpu_top is your friend for figuring out if you actually have something on the GPU compute pipes or if it’s just lying and running on the CPU.

Neat.

I set up some basic compute stuff with the ROCm stack on a 6900HX-based mini computer the other week (mostly to see if it was possible as there are some image processing workloads a colleague was hoping to accelerate on a similar host) and noticed that the docs occasionally pretend you could use GTT dynamicly allocated memory for compute tasks, but there was no evidence of it ever having worked for anyone.

That machine had flexible firmware and 64GB of RAM stuffed in it so I just shuffled the boot time allocation in the EFI to give 8GB to the GPU to make it work, but it’s not elegant.

It’s also pretty clumsy to actually make things run, lot of “set the magic environment variable because the tool chain will mis-detect the architecture of your unsupported card” and “Inject this wall of text into your CMake list to override libraries with our cooked versions” to make things work. Then it performs like an old GTX1060, which is on one hand impressive for an integrated part in a fairly low wattage machine, and on the other hand is competing with a low-mid range card from 2016.

Pretty on brand really, they’ve been fucking up their compute stack since before any other vendor was doing the GPGPU thing (abandoning CTM for Stream in like a year).

I think the OpenMP situation was the least jank of the ways I tried getting something to offload on an APU, but it was also one of the later attempts so maybe I was just getting used to it’s shit.

Don’t trust that they’re 100% compatible with mainline Linux, ChromeOS carries some weird patches and proprietary stuff up-stack.

I have a little Dell Chromebook 11 3189 that I did the Mr.Chromebox Coreboot + Linux thing on, a couple years ago I couldn’t get the (weird i2c) input devices to work right, that has since been fixed in upstream coreboot tables and/or Linux but (as of a couple months ago) still don’t play nice with smaller alternative OSes like NetBSD or a Haiku nightly.

The Audio situation is technically functional but still a little rough, the way the codec in bay/cherry trail devices is half chipset half external occasionally leads to the audio configuration crapping itself in ways that take some patience and/or expertise to deal with (Why do I suddenly have 20 inoperable sound cards in my pulse audio settings?).

This particular machine also does some goofy bullshit with 2 IMUs in the halves instead of a fold-back sensor, so the rotation/folding stuff via iio sensors is a little quirky.

But, they absolutely are fun, cheap hacker toys that are generally easy targets.

The argument was that if you put all your static resources in /usr, you can mount it RO (for integrity, or to use a ROM on something embeddedish) or from a shared volume (it’s not uncommon to NFS mount a common /usr for a pool of managed similar machines).

…that said, many of the same people who made that argument are also the ones that went with making it so systemd won’t boot without /usr populated anymore, so that feature is now less useful because it has to be something your initramfs/initcpio/whatever preboot environment mounts rather than mounted by the normal fstab/mount behavior, and the initcpio/initramfs/dracut schemes for doing that all (1) require a redundant set of tools and network configs in the preboot (2) are different and (3) are brittle in annoying ways.

It still works OK if you’re using a management tool like Warewulf to manage configs and generate all the relevant filesystems and such, but it’s a lot more fucking around than a line in fstab to mount usr once the real system is up like the old days.

Systemd-boot didn’t start as part of systemd, it used to be gummiboot (joke in German, it’s what those little rubber inflatible boats are called).

Systemd absorbed and integrated it in 2015.

It did start at RedHat with Kay Sievers and Harald Hoyer, which makes it unsurprising it was absorbed.

I’ve been transitioning to it as my default choice, I’ve never liked grub2, so I defaulted to syslinux for a long time, but lately systemd-boot is even less of a hassle.

Sure, drop me a note with the details and I’ll see if I can give you a hand. I’m not super expert in all the specifics of the Chromebook ecosystem, but I have good general computer/Unix skills and have hacked a couple so I know where to look for resources.

The 2.5 development only tree had a ton of behind the scenes big long projects that weren’t visible to users until the stable 2.6 dropped and everything suddenly changed.

Like a complete redesign of the scheduling code especially but not exclusively for multiprocessor systems, swapping much of the networking stack, and the change from devfs to udev.

If you hold udev up next to devd and devpubd that solve similar problems on the BSDs, it’s a clear leap into “Linux will do bespoke binary interfaces, and DSLs for configuration and policy, and similar traditionally un-UNIX-y things that trade accepting complex state and additional abstractions to make things faster and less brittle to misconfiguration” which is the path that the typical Linux pluming has continued down with eg. Systemd.

A lot of modern Kernel development flow is about never having that kind of divergence and sudden epoch change again.

Suggestion: the Search key under your left pinkie emits SuperL (aka. Meta, same as a Windows key), and it is an great way to make up for some other keyboard weirdness Chromebooks have, and map to WM controls.

I recently discovered keyd, an excellent system-wide key remapper that works as a tiny daemon that intercepts input events and re-emits them as a virtual keyboard, and have it mapping Search+Arrows to PgUp/PgDn/Home/End (like a lot of laptops do with Fn+Arrows, or ChromeOS does with Ctrl+Shift+Arrows). I’ve already run into a couple other folks doing the same because it’s such a clean solution to the Chromebook keyboard.

AFIK GalliumOS has been unmaintained for over a year, and most of the patches they used to add are now in mainline, so long term you may want to consider a different distro - it’s probably OK for a while still though.

The CB3-431 is device name EDGAR. You’d most likely pull the write protect screws and flash a UEFI payload into the firmware, probably using Mr. Chromebox’s tooling and payloads. Most modern Chromebooks boot Coreboot with a depthcharge payload, and it can either be coerced to boot something different with a lot of effort, or easily swapped with a Tianocore UEFI payload to make it behave like a normal PC. Once flashed, it’s an ordinary Braswell generation PC with 4GB of RAM and 32GB of storage.

The S330 is an ARM machine built on a Mediatech MT8173C. Installing normal Linux on ARM Chromebooks is substantially less well-established, but often possible. It looks like those are doable but you won’t get graphics acceleration, and the bootloader situation is a little klutzy.

Of the two, the CB3-431will be easier and better documented to bend to your will.

The major limitation with Chromebooks is really just that there isn’t much onboard storage, so you’ll want to pick reasonably light software (A distro where you pick packages on a small base install or at least a lighter spin will be preferable) and avoid storage-intensive distros (eg. Nix or the immutable-core-plus-containers schemes whose packaging models have substantial storage overhead are probably unsuitable). You may have a little hassle with sound because many Chromebooks have a goofy half-soc-half-external-codec sound layout for which the Linux tooling is still improving - a pair of annoying PipeWire and Kernel bugs that sometimes cause them to come up wrong and spew log messages got fixed last week but aren’t in a release yet.

They aren’t fancy machines, but hacked used Chromebooks make great beaters.

I’ll give them a little credit: OS X is not quite built on a verbatim copy, it’s cobbled from a few open source and licensed parts, and a not-insignificant amount of in-house development some of which is contributed back upstream.

NextStep started out as more or less the 4.3BSD userland hosted on the Mach 2.5 kernel instead of the monolithic traditional Unix style kernel the BSDs are built on, with a DisplayPostScript based UI (large parts licensed from Adobe) layered on top.

After Apple bought Next (or Next bought Apple with Apple’s money, because Apple’s management at the time was staggeringly dysfunctional and almost all the management after the dust settled ended up being Next people), they made major changes. NextStep/OpenStep tended to perform not-that-well because of additional overhead passing things in and out of the microkernel, a problem many microkernel based Unix-likes had, so they updated to the OSFMK 7.3 Mach variant, the BSD code to versions from FreeBSD, then hybridized it by pushing some pieces that traditional Microkernels ran in user space into kernel space for performance reasons, resulting in the XNU kernel that essentially every modern Apple product runs.

They also completely replaced the GUI layer with something custom and proprietary - the original plan for what became OS X was to use the Display Post Script system + a hosted classic environment, but 1. Many third party developers revolted against needing to make a ground-up new port of their software in a totally different environment and 2. the Adobe licensing costs were higher than the price of a normal PC, which was kind of OK for Next competing in the workstation market, but not OK for Apple selling consumer machines.

Apple publishes the open-source parts including most of the kernel (lately an increasing portion of drivers and platform support stuff are distributed as object files not under the open license) on a regular basis, formerly under the name “Darwin” which could be built as a pretty typical BSD-like OS, but in a way that’s sufficiently community hostile to prevent anyone from really building successful derivative projects or contributing back to it. I think the most recent attempt was called “PureDarwin” and last I checked they’ve been stalled for about 2 years.

The engineer in charge of kernel stuff for the NeXTStep/OpenStep/Rhapsody/OS X family from inception in the late 80s to 2006 was Avie Tevanian, one of the original developers of Mach.

One who does use a lot of FreeBSD parts where it’s not entirely clear how much they contribute back is Sony. The CellOS and OrbisOS that the PS3 and PS4 used are close relatives of FreeBSD, and it’s possible they hid their contributions via contractors or consultants to not expose internal plans…or they just leeched, it’s not really clear.

Forking Linux would involve taking on a huge maintenance burden, so everyone just uses it, though often basing on an older version and/or with some custom patches. That is typically how healthy open source stuff works.

Companies DO put brand names on systems built on top of Linux (or a BSD) all the time though, often ones that don’t make it obvious that’s what it is. ChromeOS and Android are both Linux based, but Android doesn’t ship most of the UNIX-y parts that are typically layered on top, and instead uses their own (also largely open source) components. ChromeOS is actually a fairly close relative of Gentoo with a few custom pieces.

Google has their own internal project for a kernel called Fuchsia, and it’s really interesting modern OS development that they’ve assembled a bunch of experts to work on… But it’s increasingly unclear if they plan to deploy it on customer facing products.

A ton of appliance type devices are basically very tiny custom Linux systems, often assembled with tools like Yocto. A lot if the vendors who sell components to go into said devices contribute code and/or money to Linux and Yocto, in order to make their products more attractive to device builders and avoid having to make and maintain their own tooling.

Most consumer routers are basically Linux (usually with a minimal userland like BusyBox), often essentially shitty old customized versions of OpenWRT. Sony alpha cameras? Customized Linux. Off on the BSD side, CellOS and OrbisOS that the PS3 and PS4 run, respectively are modified FreeBSD. Open Source OSes and tooling are everywhere because making, maintaining, and building tooling and developer support for an OS that runs on especially relatively large modern computers is a big, hard project, so very few entities try to do it themselves.

Relevant place to ask: I’ve been trying to find a reference for the earliest Emacs that could host a terminal emulator or subshell in a window.

Multics emacs appears to have had both split windows and a character-at-a-time input and output mode as far back as 1978 for use as a SUPDUP and/or TELNET client, which is currently the earliest I’m aware of. Ancient ITS TECO EMACS had splits pretty early on, and may have sprung the necessary character plumbing earlier - but I’ve never found any reference material to confirm/deny.

It’s a fringe to a larger interest, which is that I’ve been trying to document the history of terminal multiplexers, especially in the Window (1986)-Screen(1987)-Tmux(2007) tradition (as opposed to the historical meaning which we’d call terminal servers). I’m slowly becoming convinced they came about after the advent of floating window GUIs hosting multiple terminal emulators. If you were super connected and could get access to one, sometime fairly early in the window between the 1973 introduction of the Alto and the surviving 1979 manuals the Alto program “Chat” could run multiple telnet sessions in floating windows (I’m also looking for a more precise date for when Bob Sproull made Chat able to do that trick). Several other early graphical systems like Blit terminals (1982 inside Bell, commercial as the 5620 in 1984) and early Sun Windowing System of early SunOS (1983) could also do multiple floating terminal emulators, so they were common by the early 80s.

Because the 36-bit DEC lineage had pretty robust psuedoterminals all the way back into the mid 1960s ref, a lot of hackers did a lot of fun shit on PDP-10s with ITS and TENEX and WAITS, and Stanford and MIT had PDP-10s connected to fancy video terminals by the mid 70s, it’s IMO the most likely place for the first terminal multiplexers to emerge… if I could just find some documentation or dated code or accounts.

They’re both simple text formats, but Hyprland uses a “key = value” type config with section labels. Sway is largely compatible with i3 config files which are more like an unstructured script.

Most of my machines are KDE on X, but I have one where I’ve been feeling stuff out in Wayland-land. The most appealing thing I’ve tried has been Hyprland with Waybar. It’s a little bit of a kit in traditional WM fashion, but easy to configure from straightforward config files, fairly light, and not “Just like this X WM, but broken because of missing Wayland functionality” (I know, I know, it’s not technically Wayland deficiencies, its “not yet complete extensions”, because it’s all extensions, the Wayland protocol itself does almost nothing).

I’ve been using Kitty for a terminal emulator and it’s pleasing as well.

I haven’t found a launcher I love, I have fuzzel right now and the only major issue is it doesn’t currently support mouse interaction, and I prefer a “use whichever input device your hand is on at the time” to keyboard-only.

Originally it was a governance structure thing.

Now, Rocky is aiming to hold RHEL bug for bug compatibility, and Alma is giving up on that and situating to ABI but not bug for bug compatible.

Most Chromebook’s firmware is Coreboot, but it’s running a Depthcharge payload instead of UEFI (or BIOS or whatever). Mr. Chromebox maintains UEFI Coreboot payloads and install tools for a wide variety of (x86) Chromebooks, which can be used to flash a normal UEFI payload and boot normal OSes. It’s strictly possible to boot normal Linux systems on a the Depthcharge payload modern Chromebooks use, but uh… here’s the gentoo wiki on it, it’s a substantial pain in the ass.

Gonna give too much answer:

Arch is an “Install what you want” distro - the base installation is quite minimal (eg. No gui by default), and the defaults mostly follow upstream - so there isn’t much inherent heft.

If you pick light software it stays light, if you install bulky stuff, it gets bulky.

That said installing most of the major binary package distros (eg. Debian, Rocky) with the same package selections will be of similar size and runtime bulk. There are exceptions, eg. Nix is probably an unsuitable choice on a machine like a Chromebook with small storage because its package managent model keeps a lot more stuff around to enable some neat flexibility/compatibility tricks. Likewise, distros that depend heavily on Snaps or Flatpacks (eg. Silverblue, increasingly Ubuntu) will tend to use more disc space and have some runtime penalty that will be more noticeable on a low end machine.

Arch is “rolling” model, so they track current upstream fairly closely and just upgrade indefinitely. This means things are always fresh but change when they change, some other distros, like Suse Tumbleweed are similar. Stepped release distros like Debian Stable or Rocky try to keep things as consistent as possible for the support period of the release (but upgrading from release to release is likely to be more of a hassle).

There used to be some Chromebook specific distros like GalliumOS that carried patches for the common issues and pre-selected suitable weight packages, but as things got upstreamed they became unnecessary and died out.

Yup.

I have a little Dell 3189 2-in-1 that I originally got used just to see what the ChromeOS fuss was about and hack on.

I’d rooted it, and played with the various hosted/injected Linux options (like chromebrew and the 1st party Linux VM stuff, neither of which was great) while it was under support, but some time after it went AUE I went ahead and flashed a Mr. Chromebox UEFI payload onto it and just slammed normal Linux onto it. It basically “Just Works” though that’s thanks to considerable efforts in the Coreboot port and Kernel because there is a bunch of cheap bullshit (badly plumbed i2c input devices, that stupid bay/cherry trail style half integrated audio setup, etc.) in the hardware. I had briefly flashed it over a couple years ago and that hadn’t all been smoothed over yet back then.

Lately its an Arch system playing with various Wayland options - Hyprland is ricer bullshit, but it actually does a pretty decent job at being not wildly broken compared to the big environments in Wayland mode, tiling makes good use of the not enough pixels, and the search key in the left pinkie position makes a great WM key.

It’s not a nice computer, an N3060 with 4GB of RAM 32GB of emmc and a 1366x768 panel is distinctly in craptop territory these days, but you can also get them for like $50 now because no one wants past AUE Chromebooks, and they make nice beaters - and unlike refurb SFF boxes, SBCs, and similar usual sub-$100 beater options, they come with a screen and keyboard and battery.

S9

I’m still using my S9. Size is about as big as I want to deal with. Indicator LED is great. 3.5mm jack is great. SD socket for local storage. Camera is still fine. Qi charging is one of the few gimmicks that hasn’t turned out to be useless. Screen is drastic overkill. Design is a stupid friction-less glass egg, but that’s easily fixable with a minimalist case. Performance is still perfectly adequate.

It’s long out of support, but I’m finding the market wildly un-compelling, and will probably just roll with it until something renders it unusable.

For the most part, I’d rather have native packages. I’m not deeply philosophically opposed to secondary packaging systems, and only mildly opposed to “ship the whole dependency tree in an archive” software distribution methods (lookin’ at you NextStep/OS X style bundles), and see their potential especially on platforms with no/bad native package managers or to bring in specific software that would pose a compatibility problem for the host system… but they never seem to work nearly as well as native packages, and the two big players on Linux have problems.

As far as I’m concerned, they’re just taking the old last-ditch practice of “I have this piece of recalcitrant software that is incompatible with the rest of my system, so I’ll throw it in /opt with its entire dependency tree,” replacing opt with a bunch of bind mounts, and doing so with varying degrees of additional tooling.

The sandboxing is a nice idea, but it seems like in practice the models on both snap and flatpack are simultaneously restrictive in ways that make them annoying-to-unusable for many tasks, and too sloppy to provide reliable security guarantees.

They make debugging problems harder because you can’t check functionality from another program because they likely don’t share libs. ldd is a lot easier than spelunking around with eg. flatpak list --app --columns=application,runtime until you find a “peer” to test.

If I need a one-off piece of software that is a compatibility nuisance on my host distro (but not so much of a nuisance it needs to go in a container or VM, which is a pretty narrow window), I’ll usually reach for an AppImage because unlike the other two, they’re actually fairly standalone and don’t involve a big invasive runtime/tooling system.

The Immutable-core OSes that depend on them are kind of the same way at the moment. Fundamentally a pretty neat idea, but so far I find them super frustrating in practice. Nix is …different… to work with, but is likely a more elegant scheme to solve the same class of problems.