I'm the only one talking to you. You've convinced nobody else that you're even worth speaking to. Honestly, you sound like the weenie who tried to publish that bootlicking pro-military letter. Wanna go be the second person to sign it? You certainly aren't doing anything worthwhile with your time here on Lemmy.

I've been using NixOS for nearly a decade. It took me several days to understand the filesystem layout, and I had the advantage of knowing some capability theory beforehand. However, once I understood the Nix store, my paradigm shifted and I haven't had any further "unexpected troubles."

As far as I can tell, AppImages and Flatpaks are extraneous, heavy, improperly isolated, and propagate a sprawling filesystem which is hard to secure. Compare and contrast with Impermanent NixOS, which only persists data that the user has explicitly marked to be saved and has systemwide caching of installed applications.

Maybe you should actually try one before sharing your thoughts.

You claim you have a list of packages, but you've revealed none of them. This is somewhere between the angry politician waving a list of enemies and the dishonest teenager claiming to have a romantic partner in terms of convincing me. Look, you have the time to write something like fifty Lemmy comments per month; I think that you can write the twenty or thirty lines of Nix required to build your pet package. It's a shitty carpenter who blames their power tools and a shitty scientist who makes empirical claims without evidence.

I'd love to link you to their Wikipedia pages, but both of them are redlinked. As far as I can tell, Dr. V. Ronald was an educator who moved from Canada to the USA as part of the whole Xerox PARC thing and probably was valued for mainframe experience; does anybody have a full bio? The current maintainer is Ron Sunk, who did a full run at MIT up through postdoc before going to Red Hat. The names are a coincidence; runk implements what we now call Sunk summation, after Sunk's thesis. (As you might guess, that's an instance of Stigler's law, since clearly Dr. Ronald discovered Sunk summation first!)

Also, as long as we're here, I want to empathize a little with Sunk. The GUIs that folks have placed on runk, like GNOME's Gunk or Enlightenment's enk, look very cool, and there's rumors of an upcoming unified number-counting protocol that will put them all on equal ground. But @MossyFeathers@pawb.social wasn't joking; Dr. Arnold's code literally only reads punch cards, and there's a façade to make it work on modern Linux and BSD transparently. It predates X11, if that's any help. The tech debt is real.

The nixpkgs community has been operating and maintaining nixpkgs-update since 2018. Earlier in the thread, you were shown the infamous Repology graph; it's also linked from the nixpkgs-update documentation. We already have a concerted plan to offer the freshest ports tree in the world and are executing on it. If your particular pet package isn't available, then contribute it yourself and the bot will ensure that it stays fresh and updated.

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.

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.

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 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.

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.

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.