In terms of the standard principal programming paradigms, Python is on the right-hand side in the "Shared state" column. Note two interesting things: first, Python's box is represented by Java and OCaml; second, the box has two labels, "Sequential object-oriented programming" and "Stateful functional programming". Python is technically a prototype-based language like ECMAScript, but it can be seen as either object-oriented or functional depending on whether we think of prototypes as classes or closures respectively.

Note that unlike "Imperative programming", represented by Pascal and C, Python has closures. It does have closure quirk, also called lambda quirk, which ruins an otherwise-lexically-scoped language, but folks with lots of Python experience are used to working around closure quirk. Python functions are not procedures; they are sugar for objects with a .__call__() method.

If this is your first time with the principal paradigms, please keep in mind the following quotes. First, from the associated book:

More is not better or worse than less, just different.

That is, Turing-completeness doesn't have a canonical set of computational features. Second, from the chart PDF:

Two languages that implement the same paradigm can nevertheless have very different "flavors" for the programmer, because they make different choices on what programming techniques and styles to facilitate.

This is for short-lived cloud-allocated (virtual) machines which have an IPv4 address but not necessarily a DNS presence. When there are more than a handful of machines, name management becomes its own unique pain; often, the domain names of such a machine are an opaque string of numbers under some subdomain, and managing the name is not different from managing the raw IP address instead. Similarly, for the case of many machines all serving a wildcard (e.g. a parking page) allocating a single IP-address certificate might be preferable to copying the wildcard certificate to each machine.

As you point out, though, SSH exists and has accumulated several decades of key-management theory. Using HTTPS instead of SSH for two machines with one owner is definitely not what I would do. I've worked at all scales from homelabs to Google and I can't imagine using IP-address certificates for any of it.

Now, with all of that said, if Let's Encrypt were available over e.g. Yggdrasil then there would be a use-case for giving certificates directly to IPv6 addresses and extending PKI to the entire Yggdrasil VPN. That seems like a stretch though.

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.

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.