CppNix isn't slow because of C++, it's slow because its evaluation strategy (tree-walking an AST without any optimizations) is slow. Rewriting in Zig or Rust will not necessarily help; the structure of the compiler needs to be better. That said, Tvix is a Rust rewrite which uses a bytecode interpreter, and it is faster, but it's not a drop-in replacement like Lix. I prototyped a faster evaluator in RPython; see this LixCon 2026 video for my summarized notes to the Lix community.

Nix store transactions will never be instant. You've probably never thought about atomicity and durability for your configuration-file edits, but it's a desirable thing, right? Nix writes to a SQLite database for every transaction. This is not going to be a big part of your runtime as long as CppNix is so slow at evaluation, but it's the reason why trivial builds, like your derivations that merely copy text to the Nix store, take so long.

Clearly @[email protected] is a yinglet.

You need SRE concepts. First, if you break it then you fix it; in a system where anybody can make a change, it's the changer's responsibility to meet service objectives. Second, if your boss doesn't find that acceptable then they need to appoint a service owner and ensure that only the owner can make changes; if the owner breaks it then the owner fixes it. Third, no more than half of your time should ever be spent fixing things; if something is constantly broken then call a Code Yellow or Code Red, tell your service users that you cannot meet your service levels, and stop working on new features until the service is stable again.

Under no circumstances, ever, should anybody stay late. There should only be normal business hours, which are best-effort, and an on-call rotation which is planned two months in advance. Also, everybody on call should be paid hourly minimum wage on top of salary for their time.

Because frankly, Ronald (the current maintainer, not the original author) is very competent. I say this as somebody who has personally been yelled at by Ronald at a kernel summit; I didn't deserve it, but none of his technical points were wrong. I like to think of myself as the kind of person that, given enough time and documentation, can maintain anything; I think it'd still take three of me to do Ronald's job. (Well, "job." I think he technically works for Red Hat or something?) Not to excuse his conduct, just to explain why he's not been replaced yet.

Sounds like it's time to start training code-writing models on leaked Microsoft source code. Don't worry, it's not like it'll "emit memorized code".

I remember learning recursion twice: once for Fibonacci and once for Hanoi. It did take a while to click but it unlocked recursion schemes and dynamic programming.

It's because the Booleans sometimes are flipped in display-server technology from the 1980s, particularly anything with X11 lineage, and C didn't have Boolean values back then. More generally, sometimes it's useful to have truthhood be encoded low or 0, as in common Forths or many lower-level electrical-engineering protocols. The practice died off as popular languages started to have native Boolean values; today, about three quarters of new developers learn Python or ECMAScript as their first language, and FFI bindings are designed to paper over such low-level details. You'll also sometimes see newer C/C++ libraries depending on newer standards which add native Booleans.

As a fellow vim user with small hands, here are some tricks. The verb gU will uppercase letters but not underscores or hyphens, so sentences like gUiw can be used to uppercase an entire constant. The immediate action ~ which switches cases can be turned into a verb by :set tildeop, after which it can be used in a similar way to gU. If constants are all namespaced with a prefix followed by something unique like an underscore, then the prefix can be left out of new sections of code and added back in with a macro or a :%s replacement.

Other way around, actually; C was one of several languages proposed to model UNIX without having to write assembly on every line, and has steadily increased in abstraction. Today, C is specified relative to a high-level abstract machine and doesn't really resemble any modern processing units' capabilities.

Incidentally, coming to understand this is precisely what the OP meme is about.

Most consumer-grade NICs have a default MAC address which is retrievable with device drivers, but delegate (Ethernet) packet assembly to the OS. If the OS asks the NIC to emit a packet, then the NIC often receives the packet as a blob, DMA'd from main memory, and emits the bytes as octets. Other NICs do manage packet assembly, but allow overwriting the default MAC address. By the time I was learning Linux, we had GNU MAC Changer available in userland with the macchanger command, and many distros have configuration for randomizing or hardcoding MAC addresses upon boot.

I want to say that this is all because olden corporate network management policies could require a technician to replace a NIC without changing the MAC address, but more likely it is because framing and packet assembly was not traditionally handed to a second controller, and was instead bit-banged or MMIO'd by the CPU.

Yeah, writing your own squeeblerizer sucks, but there's no better option. GNU Scrimble can be used off-the-shelf as a passthrough, so the only real tasks are implementing Squeeb's algorithm and a sprongler; then, your entire pipeline is merely something like:

$ gscrimble --passthrough --args -- ./your_squeeb | ./your_sprongler

Edit: Whoops! Forgot to mention, GNU Scrimble also has Snorble support out-of-the-box, and Scrimble clients have content auto-negotiation, so your_squeeb can just take JSON on stdin. GNU Scrimble is really nice for this sort of thing, just...big.

And if you want to sprongle directly into a database or etc. then you can write your_sprongler to taste. Full disclosure: I have a fairly fast implementation of Squeeb's algorithm in rpypkgs. However, I'd really recommend writing your own; it's like twenty lines of code you can copy from Wikipedia and it'll give you a good basis for extending it with your own desired changes later.

You can read snorblite's code if you need to figure out a specific sprongling technique, but it's way easier to just go look up the original SprongCode from SprongReg. Use a search engine to get around the university's paywall. This gets you the SprongCode UUID and you don't have to read code written by a batshit fascist.

You're thinking of architecture astronauts when talking about generics. The biggest win of the object-oriented folks was to get a garbage collector included by default; compare and contrast with Rust, which ended up not having garbage collection.

It's because most of the hard questions and theorems can be phrased over the Booleans. Lawvere's fixed-point theorem, which has Turing's theorem and Rice's theorem as special cases (see also Yanofsky 2003), applies to Boolean values just as well as to natural numbers.

That said, you're right to feel like there should be more explanation. Far too many parser papers are written with only recognition in mind, and the actual execution of parsing rules can be a serious engineering challenge. It would be nice if parser formalisms were described in terms of AST constructors and not mere verifiers.

Direct rendering infrastructure in Linux predates widespread use of "digital rights management" as a term of art by about two or three years. "We were here first," as the saying goes. That said, the specific concept of direct rendering managers is a little newer, and probably was a mistake on its own merits, regardless of the name.

It's the same controversy as it was last year and the year before that: should the military-industrial complex be allowed to benefit from the Nix commons? It's disappointing that you don't think that the ethics of our profession is worth more than the output of our labor, particularly when it comes to exploitation, mass surveillance, war, and genocide.

Most of us write flakes outside of nixpkgs. I'm still listed as a maintainer and get pinged, but I don't really care; anything I care about is already being actively developed out-of-tree. I doubt I'm the only maintainer taking that sort of quiet-quitting path.

Well, I don't want to pull the kernel-hacker card, but it sounds like you might not have experienced being yelled at by Linus during a kernel summit. It's not fun and not worth the money. Also it's well-known that LF can't compete with e.g. Collabora or Red Hat on salary, so the only folks who stick around and focus on Linux infrastructure for the sake of Linux are bureaucrats, in the sense of Pournelle's Iron Law of Bureaucracy.

Hi! Please don't link anything from this subdomain again. It was considered a plague back on Reddit, and this sort of content-free post shouldn't be encouraged here either.

[HTML and Markdown] are not grammatically Type 2 (Chomsky-wise, Context-Free); rather, they are Type 3 (Chomsky-wise, Regular).

This is at least half-wrong, in that HTML is clearly not regular. The proof is simple: HTML structurally embeds a language of balanced parentheses (a Dyck language), and such languages are context-free and not regular. I don't know Markdown well and there are several flavors; it's quite possible that some flavors are regular. However, traditional Markdown embeds HTML, so if HTML is not regular than neither is Markdown.

I once did a syntax-directed translation of Markdown to HTML in AWK!

Sure. The original Markdown implementation was in Perl and operated similarly. However, note that this doesn't imply that either language is regular, only that a translation is possible assuming the input is valid Markdown. Punting on recognition means that invalid parse trees have undefined translations, presumably at least sometimes generating invalid HTML.

Don't use OpenAI's outdated tools. Also, don't rely on prompt engineering to force the output to conform. Instead, use a local LLM and something like jsonformer or parserllm which can provably output well-formed/parseable text.

So, you've never known any Unix hackers? I worked for a student datacenter when I was at university, and we were mostly vim users; as far as text-editor diversity, we did have one guy who was into emacs and another who preferred nano. After that, I went to work at Google, where I continued to use vim. As far as fancy IDE features, I do use syntax highlighting and I know how to use the spell checker but I don't use autocomplete. I've heard of neovim but don't have a good reason to try it out yet; maybe next decade?

Nailed it. I think about this a lot: a sysadmin is basically a manager of dozens, hundreds, or even thousands of computers. But management is a poor way of orchestrating human labor; small teams usually operate better without management. So, is there a better way to administer computer systems as well?