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.

You can still readily get crank hand drills, I have a (vaguely) modern one that I use for situations where I want the control/tactile feedback and/or have restricted access or the like. It covers a different set of problems than the standard cordless.

Mine is Fiskars branded and a little plasticky (and not the version they sell currently). I like it enough that I’ll get a nicer one if I kill it.

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 near instant heat up is a big part of how I ended up with my Bambino with its “Thermojet”(Thermoblock coil thing) heater.

3s from wake to ready, it takes longer to grind and prep than to heat. I usually pull a blank shot through the clean portafilter into the cup I’m going to pull the shot in so the downstream parts aren’t crashing the temperature, but that’s still seconds.

Ascaso and Decent have more up-market offerings with thermoblock heaters that are similarly fast but offer more control. I wasn’t 5-10x price compelled for my needs, and I’m certainly not over 100x price in to that thing… But it is a great feature that the commercial derived machines don’t do.

I share my SK40 for espresso (usually morning) and aeropress (usually afternoon), and have definitely left it set for the wrong thing occasionally.

The aeropress is a little stiff to press if you put espresso grind in it, the product is usually fine. The underextraced 10ish second espresso shot is a lot more disappointing.

Another Tears of the Kingdom here.

I’m like … 5/3 subscribed between professional and personal obligations for the next several months, so don’t have time for that in my life.

When I got around to Breath of the Wild in late 2020, I arranged it so I could basically take a vacation from reality to Hyrule for over a week with it, and the experience was delightful, so I want to hold off until I can properly enjoy it.

I did similar things at the ends of periods of over-obligation with Fallout: New Vegas and Skyrim (earlier, but both years after their release), I’m a sucker for disappearing into an open-world RPG as a vacation.

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.

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.

I’ve never been much of a poster (not even 2 posts/yr for the almost dozen years I’ve had a reddit habit), but I was a regular commenter in various specific-interest subs.

I am, as a rule, no longer contributing content to Reddit, since they’ve made it clear they plan to finish their transition from “hosting communities” to “extracting value from users.” Frankly, it’s not as much of an imposition as I feared, because many of those communities seem to be broadly taking the same attitude.

I’m actively trying to comment heavily here to to try to help establish communities. If I had a little more free time I’d do some posting and/or try to help spin some successor communities for my interests.

I’m somewhat surprised to learn that each Snowmobile unit is only about 100PB in a 45x8x9.6ft highwall shipping container

Gonna ballpark in stupid units to see how wrong my intuition that that’s not very dense is:

Assuming dense but not hot new thing spinning rust, 16TB per 34.5 cubic inch standard 3.5" disc.

(100PB/16TB)*2 (assume at least two spindle redundant) is about 12,000 discs, so about 414,000 cubic inches of just discs without any of the supporting equipment.

A highwall shipping container is like 5,900,000 cubic inches, so only like 7% of that thing would be discs.

Or, accommodating a little bit of the support, let’s say it’s just full of those commodity 90-bay 4U storage servers. Those are 19" x 7" x 26.4" (3511.2 cubic inches) for 1440 raw TB each, again 2 spindle redundancy so you’d need about 140 of the things for 100PB, round up to 500,000 cubic inches of those… still less than 9%.

Yeah, unless I did my math radically wrong, that’s surprisingly not very dense.

Oh, it is, I just meant my instance has had its keys rebound so I haven’t run into that problem.

When last I looked miniflux wasn’t quite as featured a solution as I’m looking for (I keep a lot of notes and such embedded in my DB), but it is pleasingly simple.

Ah, I’ve had the googlereaderkeys plugin enabled forever so I don’t even know what their default keybinds are. Unless I see something super compelling (or a serious problem with tt-rss and its ecosystem) I’m unlikely to change, but I like to keep my ear to the ground on the space.

Since you’ve used both, what are your feelings on FreshRSS vs. tt-rss?

Around the death of google reader, I set up a tt-rss instance, imported all my saved stuff, and I’ve been using it continuously since (I’m technically in an unsupported configuration because I set it up long before docker became the preferred then only supported configuration, but it just keeps ticking installed like a normal piece of software on a rented VM).
I’m generally super pleased, and it’s my primary mode of content consumption via browser + Android App, and I use the “note” and “share with note” features pretty extensively to plumb to some other folks with similar setups.

Fox (the main tt-rss dev) is clearly an asshole, and there are some geopolitical complications because he’s a Russian national, but he’s made an excellent focused piece of software. I’ve considered looking seriously in to FreshRSS, but have a lot of inertia and at a glance it looks like it’s missing a few features.