cmm

yes. other possible arguments are overlays and package selection modifiers (like whether to include non-free stuff or stuff that is marked as broken).

well, let's see: bog-standard cgi, overbearing music that sounds like music in any other big recent(ish) "fantasy" production, stilted dialogue laced with awkward exposition, nobody among the cast seems to know how to fucking act (except the guy playing John Dee, he's excellent though also exactly the same as everywhere else, so he just steals every scene he's in), that stupid raven, shall I go on.

still watchable, weirdly enough, but just not good.

who addressed to? who's pestering you?

I just briefly skimmed the docs, so my observations may be inaccurate, but I got the impression that "stackful coroutines" are basically green threads (not C++20 coroutines, as the name might hint). Green threads need a dedicated stack per thread, with all that implies, and also I don't find the cute "magical" implicit yielding helpful readability- and comprehension-wise, but that's more a matter of taste.

It is either telling or a glaring oversight (let's assume the latter) that there is no comparison with Seastar, which supports both C++20 coroutines and callbacks, with helpful syntax sugar for latter (coroutines are still nicer though!), has green threads too (which it calls "threads"), and can use io_uring, dpdk, etc. Seastar is free, actively developed, and is used by real software with demanding performance and scaling requirements, so in light of Seastar existing I'd expect any new C++ async framework to approach the task of "selling" itself more seriously than "it's like Go or Python but in C++!".

> In fact, I believe overlays are also commutative.

No. But "nice" overlays probably should have this property, since commutativity means orthogonality.

1. home-manager is perfectly usable on any linux distro, that's in fact how the eventual transition to nixos started for me -- by porting my home config (on ubuntu, at the time) to home-manager. in fact I still keep my os-config and home-config repos separate, so my home config should still on non-nixos if the need arises

2. you don't need to "translate" any existing config files, it's perfectly fine to use them as-is.

regardless of the specifics here, stuff like this is liable to pop up a lot in the coming several years while NixOS is gaining more popularity but casual (as in "not willing to put in the effort of supporting off-beat distributions") OSS authors can still reasonably ignore it. the amount of patching that Nixpkgs packagers have to do sometimes is pretty extreme

when have you last tried to create a statically-linked binary that used glibc, and how did that go for you? or how about statically relinking a dynamically-linked binary you don't have sources for?

(but hey, I also felt cheated when I read how clodl works. the hope for magic is always there, isn't it)

Yes. Someone decided that having one process be the display server (which in the x11 world is separate) and the desktop shell, and have said desktop shell be able to run basically arbitrary js code, is going to work well. And it mostly does, as long as you are foregoing the js extensibility part; otherwise (at least in my personal experience) it's a complete disaster.

uh, you could do the "add site to home screen" thing in the old version too.

and in the new version, enabling the (very cool, by itself) "Open links in a private tab" setting does guess what to PWA's (but only if a tab for the specific PWA does not already exist, because of course)

it seems that the web has for at least a decade already been at the point where a search engine that is built to be useful by humans should (ideally, but apparently impossible with the current skewed incentives due to ad business considerations, overheated stock market, over-enthusiastic ML expert workforce, etc.) index only sites that opt _in_, vetted by humans.

there is a clear upper bound on the amount of total legitimate web content, and that upper bound is not prohibitively high -- linear on the total number of coherent-content-producing humans with only so many hours in a day and only so many years of adequate brain functioning (and not on the amount of whatever computing resources that are thrown in to support whatever algorithmic content fire hoses that the currently-dominant search engines contend with).

with laptops, it really pays to make sure your kernel as recent as possible

arbitrary mouse (or "mouse") button remapping in libinput (my understanding is that libinput itself supports it, but due to some security-related reasons it has to be configured on behalf of the logged-in user and the UI is just not there, or something). the upshot is that I cannot use my trackball the way I'm used to, and that seriously sucks.

yes, but have you tried writing macros in the GNU Make extension language and reading them the next day? dude.

(I guess what I'm trying to say here is that the 80% solution is not nearly as hard as that linked page makes it seem).

the horrible contortions listed on the linked page are required for the pathological "some of the targets that are built together got deleted, but the primary one did not" case, which in my experience Does Not Happen (or when it does, it is a symptom of deeply suspect practices -- like shitting where you ea^W^W^W^Wkeeping build artifacts and sources in the same directory, or relying on manually deleting artifacts to force a rebuild instead of getting the bloody dependencies right in the first place, etc.)

it's not the parsing per se that takes time on modern computers, it's opening and reading in all the scattered included makefiles. also what specifically Android build system is doing behind the scenes is, it runs a python script, which in turn runs find (or maybe several, I don't remember), to gather all the makefiles to include.

but parsing, once all the text is in memory? peanuts.

firstly, the upcoming version of GNU Make will indeed support multiple outputs in non-pattern rules (pattern rules always supported this, but pattern rules, uhh, have their own problems), using &: instead of :, resolving a bug from 2004. don't you just love the solid pace of those old GNU projects.

secondly, working around this was never very hard, albeit ugly: pretend your rule builds just one of the targets and have the other products depend on that one and simply touch themselves up to its timestamp.

I see that at this point in time Smalltalk and Lisp machines have become completely memory-holed (oh wait, Smalltalk & Lisp are interactive, thus "interpreted", thus obviously not compiled! I'll show myself out)

where, except for Windows, is requiring GNU Make a problem?

There's .ONESHELL for that (as long as we are talking about GNU Make)