Alternate perspective: I use the heck out of session restore, and it has driven me nuts that it hasn’t worked properly under Wayland.

I tend to use different virtual desktops for different projects, so being able to reboot (because of a kernel update and needing to load a module or something) without losing and having to rebuild that state is is super valuable.

…I probably should have checked the byline before posting. It does still come from the same material, just a little more directly.

There’s some weirdness on that because she did some important but not-very-public work at IBM in the 60s with their ACS/“Project Y” effort that did what we later call superscalar/multi-issue processors like …20 years before those terms existed. As part of that she wrote a paper about “Dynamic Instruction Scheduling” in 1966 under her pre-transition identity that is a like retroactive first cause for a bunch of computer architecture ideas.

There was almost nothing about that work in public until Mark Smotherman was doing some history of computing work in the late 90s, put out a call for information about it, and she produced a huge trove of insider information after deciding it was worth exposing the provenance. There’s a neat long-form LATimes piece about the situation which is probably the primary source for the history in OP’s link.

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.

They don’t have to be specified in a monolithic fashion, but some things - like the input plumbing and session management examples I made - do have to be specified for for software to work when running under different compositors. FD.o basically exists because we already learned this lesson with other compat problems, and solved it without putting it in the X monolith - it’s why things like ICCM and EWMH happened; there were more details than were in the existing APIs that everyone needed to agree on to make software interoperate.

Competing implementations are great, but once you have significant inertia behind competing implementations which are not compatible or at least interoperable, you’ve fragmented the already-small Linux market share into a maze of partially-incompatible micro-platforms. We’re not going to have compositing and non-compositing, we’re going to have 3ish (KDE/Qt [kde], Gnome/Gtk who aren’t even doing documented protocols, and Everyone else - mostly [wlr] extensions) incompatible sets of protocols for basic functionality.

Looking at the slow bitter process to extend or replace components once implementations that rely on them exist, that’s not something to count on. Remember how it took 15 years of contention to eventually transition to D-Bus after CORBA/Bonobo and DCOP? That’s whats about to happen with things like the incompatible gtk and qt session management schemes. And that resolution was forced by the old HAL system using it, not the other parties involved getting their shit together of their own accord.

One place we’re about to see innovation is wayland-stack-bypassing workarounds. Key remapping is currently in that category, the wayland protocols suite punted… so instead, keyd sniffing all the HID traffic at the evdev and/or uinput layer and outputting the rule-edited streams to virtual HID devices. That one does have a certain global elegance (works on ttys!), but it’s also layering violations with privileged processes.

I will preface that Xorg is obviously an unmaintainable mess of legacy decisions and legacy code, and I have both a machine that runs Hyprland and a machine that usually starts Plasma in Wayland mode so the Wayland situation getting to be more-or-less adequate with persistent irritations here and there… but Wayland is trauma-driven-development. It’s former xorg developers minimizing their level of responsibility for actual platform code, but controlling the protocol spec, and in the position to give up on X in time with their preferred successor.

Essentially all of the platform is being outsourced to other libraries and toolkits, who are all doing their own incompatible things (Which is why we have like 8 xdg-desktop-portal back-ends with different sets of deficiencies, because portals were probably designed at the wrong level of abstraction), and all have to figure out how to work around the limitations in the protocols. Or they can spend years bikeshedding about extensions over theoretical security concerns in features that every other remotely modern platform supports.

Some of that outsourcing has been extremely successful, like Pipewire.

Some attempts have been less successful, like the ongoing lack of a reasonable way to handle input plumbing in a Wayland environment (think auto-type and network kvm functionality) because they seem to have imagined their libinput prototype spun out of Weston would serve as complete generic input plumbing, and it’s barely adequate for common hardware devices - hopefully it’s not too late to get something adequate widely standardized upon, but I’m increasingly afraid we missed the window of opportunity.

Some things that had to be standardized to actually work - like session management - have been intentionally abdicated, and now KDE and Gnome have each become married to their own mutually-incompatible half solution, so we’re probably boned on that ever working properly until the next “start over to escape our old bad decisions” cycle… which, if history holds, isn’t that far away.

We’re 15 years in to Wayland, and only in the last few years has it made it from “barely a tech demo” through “Linux in the early 2000s” broken, and in the last year to “problems with specific features” broken … and it is only 4 years younger than the xf86->xorg fork.

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 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’ve definitely had (good) blends were the components were taken to significantly different roast levels.

AFIK generally the components in blends are roasted separately for added control. Different beans behave differently in roasting so coffee that is blended then roasted will generally not be consistent anyway.

The separation lets a roaster take components to different levels to compliment each, eg. Roast a component with really good body but harsh flavor relatively dark to reduce the perceived bitterness, or keep a component you’re adding for fruity flavors or acidity light so you don’t suppress it’s desirable properties.

The former (harsh but big-bodied) thing is a common trick for Espresso in particular, a lot of really big-bodied beans tend to taste harsh, and that can be reduced with darker roasts without killing thr body. Robusta/Canephora (rather than Arabica) beans especially tend to be big bodied and highly caffeinated and hardy to grow…and have a major burning rubber note to their flavor. Good espresso blends often add some to improve mouth feel…but also cheap coffee products tend to use it, most instant or coffee flavoring starts as Robusta.

Single origin doesn’t automatically mean good coffee, but roasters who bother to source and label a single origin (which can sometimes be as specific as a farm, or broad as a country) will tend to be more mindful of that particular beans’ flavor. Also, smaller fancier roasters will generally sell fresher coffee. Beans that have been sitting roasted in a grocery chain’s “nonperishable” supply chain for months will essentially always be stale, and as soon as you get a taste for coffees that aren’t, you are cursed with that knowledge.

Single origins (and “weird” drying processes other than fully washed) will also tend to have way more character than “just coffee” which is fun and interesting but not always desirable. You can build really delicious (and consistent) coffee with blends in ways that might not be achieveable with a single bean.

I’m pretty fond of the Tru-Spec 24/7 design, especially in ripstop.

I have/had some 5.11s (the ones I had were a cotton that really retained moisture, the pocket layout is more obtusive than it is useful, and their waist elastic is the kind that makes mark-leaving bunches), a pair of those Vertx ones that try to hide the cargo profile (always found them a bit uncomfortable, also bunch-type elastic), some of the Duluth “Fire Hose” (great for manual work, too heavy and hot for casual wear), one pair of the tru-spec in cotton (pretty good)… And multiple pairs of both pants and shorts of the ripstop tru-spec 27/7 because they have a really nice waist elastic design, a pocket design that is actually useful for retaining stuff and tries to minimize profile when empty, the fabric breathes and dries well without feeling plasticy…

They slightly changed the interior of the pocket design a while back and it makes the retaining flap not quite accept my particular phone and adds an extra layer of fabric and hence added bulk/lost breathability to make an additional slot, which was unfortunate, but still, highly recommend.

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.

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.

As expected from the docs, that’s why I was surprised to see you mention Nix on a Chromebook, it seemed like order of magnitude wrong. 128GB is an unusual amount of local storage for a Chromebook.

I have a little Arch/Hyprland install that fits a comfortable environment in like 8 of the 16GB in my Dell 3189 right now - It was kind of a fun project fitting it and chasing down all the little annoyances, I think it all works now other than the lack of pluming to make use of the fold sensors, and an occasional ASoC bug for which patches have landed upstream in Linux or Pipewire since the last releases.

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.

How is NixOS on a Chromebook? The Chromebook I’ve been hacking on exists as a beater for trying environments without disrupting the (principally Arch+KDE on X) boxes I do my real work on, and I was thinking about trying Nix on it, but it seemed like the combination of 16GB eMMC and Nix’s propensity for large disc usage would make that difficult.

I just tried keyd a day or two ago and I’m super taken with it.

I just wanted to make Meta+Arrows generate PgUp/PgDn/Home/End because I’ve really grown to like laptops that do that with Fn (And I was playing with a hacked Chromebook whose keyboard does those soft with Ctrl+Shift+Arrow in software on ChromeOS so you’ve got to do something).

I’m quite impressed. The configuration format is sane, the daemon’s runtime footprint is tiny, and it works across VTs, X, and Wayland because it’s a virtual keyboard emitting events. The historical options have like…0-1 of those properties. Also the virtual keyboard takes bus ID 0fac:0ade, and who doesn’t like a god hex pun.

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.