From the perspective of somebody who's actually hacked on Linux: Most Linux maintainers, like most programmers in general, are full of machismo stemming from the inherent difficulty of writing C. It is extremely difficult to write correct C and nobody can do it consistently, so those maintainers are heavily invested in the perception that they are skilled with C. Rust is much easier to write and democratizes kernel hacking, which is uncomfortable for older maintainers due to the standard teenagers-vs-parents social dynamics. Worse, adapting various kernel interfaces so that they are Rust-friendly has revealed that the pre- and postconditions of interface methods were not known before; there is existing sloppiness in the kernel's internals which is only visible because of Rust-related cleanups.

Note that Linux is not a GNU project. GNU's kernel project is GNU Herd. "GNU/Linux" refers to Linux userlands populated with GNU packages. It's important not to be distracted by this; the kernel is agnostic towards userland and generally is compatible with any loadable executable that uses Linux's public syscall interface, so the entire discussion of Rust in the kernel is separate from anything going on in userland.

Most siblings are wrong! PRs written in Rust can be rejected. There are already multiple non-C languages in the kernel. Rust is sufficiently available on the platforms where it will be required for building kernel. Maintainers are only added after they have shown themselves to be socially reliable and they can be removed by other maintainers if they are unresponsive. The only correct sibling points out that Rust is different.

The author would do well to look up SGML; Markdown is fundamentally about sugaring the syntax for tag-oriented markup and is defined as a superset of HTML, so mistaking it for something like TeX or Word really demonstrates a failure to engage with Markdown per se. I suppose that the author can be forgiven somewhat, considering that they are talking to writers, but it's yet another example of how writers really only do research up to the point where they can emit a plausible article and get paid.

It’s worth noting that Microsoft bought PowerPoint, GitHub, LinkedIn, and many other things—but it did in fact create Word and Excel. Microsoft is, in essence, a sales company. It’s not too great at designing software.

So close to a real insight! The correct lesson is that Microsoft, like Blizzard, is skilled at imitating what's popular in the market; like magpies, they don't need to have a culture of software design as long as they have a culture of software sales. In particular, Microsoft didn't create Word or Excel, but ripped off WordPerfect and Lotus 1-2-3.

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.

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.

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.

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

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.