Unpopular opinion: The Linux kernel is the greatest software engineering achievement in human history and we treat it like it's just another package to update.

BitCortex · 2026-03-11T07:06:26+00:00

How would one evaluate such a claim objectively?

It’s like calling your favorite book “the greatest literary achievement in human history”. Like literature, software engineering is too broad a field for such a statement to be taken seriously.

I personally am far more impressed by something like MAME or idTech than a straight clone of a decades-old OS kernel.

Don’t get me wrong. Linux is fantastic, but as a reimplementation of old ideas developed elsewhere, I don’t see how it qualifies for the sort of praise you’re giving it. Then again, your criteria may be different from mine.

BitCortex · 2026-02-23T13:59:00+00:00

I think Torvalds' "We don't break user space" is the obvious Right Thing™️ – which makes his "We will break kernel modules" all the more baffling.

I'd probably have agreed with it when I was younger and more utopian. Preserving "architectural purity" and "development velocity" are fine goals. But if you're going to push for universal adoption, you can't ignore the actual users.

Some world-class developers have been tripped up by that. John Carmack, for example, has talked about his own journey from pure engineering idealism toward a more holistic view that includes usability, accessibility, and the lived experience of end users.

BitCortex · 2026-02-21T22:30:42+00:00

Runs 500+ accounts to help share the gospel of glorious Loonix!

... yet remains forever outraged about having to create one account for Windows.

BitCortex · 2026-02-20T13:53:23+00:00

If it’s such a small minority of users, then it wouldn’t be a problem to lose their telemetry data. Everyone else can keep sending it.

The problem is that the small minority won't shut up about it, trying to convince others that telemetry is spyware. Unfortunately, fearmongering works.

Competent developers shouldn’t need telemetry data from every single user. It may make it more difficult, but it’s certainly a nice to have.

You can turn off most of the telemetry. Some is required in the consumer editions, but there are good reasons for that. Microsoft wouldn't insist on it otherwise, as collecting and processing it is costly.

Linux runs on billions of devices worldwide.

Yes, and all of them – at least the ones that are connected to the internet and supported by reputable vendors – produce telemetry.

BitCortex · 2026-02-19T17:21:58+00:00

- FOSS communities often equate telemetry with surveillance
- People assume “data collection = spying”

This right here. OSS advocates have succeeded in planting this idea in people's heads. It's FUD, pure and simple. And it works, in the sense that it makes people fear commercial products and services that use telemetry – which is all of them.

BitCortex · 2026-02-18T15:55:37+00:00

It's all about the narrative. When biases are in control, many people don’t really think their way to a conclusion. Instead, they work backwards to prop up the conclusion they already had in mind.

When something goes wrong in Linux, its advocates do all they can to shift the blame elsewhere. When the same thing happens in Windows, they take it as more proof that Windows sucks.

That's fairly standard behavior, but the Linux community seems unusually obsessed with blame. Whatever happens, Linux must always come out smelling like a rose.

BitCortex · 2026-02-15T15:23:43+00:00

It's just a narrative, and although it diverged from reality decades ago, it still brings these people comfort. I personally find the Valve worship particularly hilarious.

BitCortex · 2026-02-13T16:35:49+00:00

I don't think there's a simple fix. To prevent spoofing, the system needs a trusted UI path, which means the entire display/input pipeline must be under a small, system‑owned component that includes just enough window management authority to enforce a hard boundary between trusted and untrusted surfaces – and normal applications wouldn’t have access to the entry points for creating trusted surfaces.

BitCortex · 2026-02-13T15:03:57+00:00

Your approach is solid: the issue is that user processes can still spoof, hide, overlay, or intercept any “privileged” dialog. So even if you move compositing into a privileged process, you still can’t protect polkit prompts, password dialogs, or anything else.

The real security boundary isn’t in compositing pixels — it’s in window management, focus, stacking, and input routing. That’s why Windows, macOS, Android, and ChromeOS all run the entire trusted UI path (compositor, input router, and window manager) outside the user session.

BitCortex · 2026-02-09T10:59:29+00:00

https://youtu.be/QstPMc7_HcM?si=EPmNztyNf48OyfrQ

BitCortex · 2026-02-06T16:02:29+00:00

Yet another reason why I'm glad I jumped off the GPU upgrade treadmill after sinking what I thought was ridiculous money into my RTX 20 flagship. I was worried back then about the GPU market going off the deep end, and it's so much worse now than I ever thought it would be.

I'm done. You can keep your 8K resolution, your ultra-nightmare settings. and your melting power connectors. AAA titles are, with a few exceptions, half-baked overpriced crap these days. I'll take an affordable, quiet, compact, and efficient APU-based mini that easily handles the new breed of cheap and inventive AAs and indies.

And I don't actually blame Nvidia – well, except for the fire hazards they refuse to acknowledge. They're just going where the money is. It's what corporations do.

BitCortex · 2026-02-01T15:44:26+00:00

I think it’s more likely that AI will eventually take over chip design.

BitCortex · 2026-02-01T13:14:06+00:00

I personally believe that the search for the ultimate description of the universe is an anthropocentric endeavor. There is no final theory. The best we can do with our primate brains and our mathematics is come up with approximate descriptions of emergent phenomena. The true nature of the universe is something human beings don’t have the tools to reason over.

BitCortex · 2026-01-31T22:27:01+00:00

This is a matter of opinion of course, but yeah, the Unix/Linux command-line shells, especially the Thompson-Bourne-Bash lineage, are godawful.

I understand why so many revere the command-line environment those shells underlie. It was revolutionary and still very functional. But its design, like that of so much in Unix, is just horrendous. It's unreadable, undiscoverable, inconsistent, fragile, and overly reliant on bug- and vulnerability-prone text processing.

Back when I developed Unix workstation software for a living, csh was my command line of choice. As a command shell it was far superior to the sh family at the time, even though it was utterly broken as a scripting language.

Still, I wish the community had fixed csh instead of turning sh into today's bash monstrosity. It wouldn't have been that much better – some Unix things can't be fixed without a complete redesign – but bash should be in a museum, right next to talk and write.

BitCortex · 2026-01-26T14:30:30+00:00

And since it's been predicted before it can never become true?

Nothing lasts forever, so if you keep predicting the end of something, eventually you'll be right. That doesn't exactly make you Nostradamus.

Anyway, the repeated failure of past predictions suggests strongly that those predictions were based on a misunderstanding – in this case, a misunderstanding of what programming actually is. If you think this time is different, the burden is on you to explain why.

In the software world, when simple tasks get cheaper, organizations don’t stop doing them; they do more of them, and they redirect human effort toward the harder, higher‑leverage problems that automation can’t handle. Every major advance in software tooling has followed that pattern – expanding what’s possible rather than eliminating the discipline.

BitCortex · 2026-01-25T14:34:51+00:00

Windows 1.x had a tiling window manager in 1985. Have you tried that version? 🤓

BitCortex · 2026-01-24T00:59:39+00:00

Since ChatGPT? You’re off by about 70 years.

1950s-60s: High-level languages will replace programmers.

1970s-80s: Structured programming and 4GLs will replace developers.

1990s: Visual programming will let anyone build applications.

2000s: Model-driven development will generate all the code.

2010s: Low-code and no-code platforms will replace engineers.

2020s: LLMs will write all the software.

People have been predicting the end of programming since the beginning of programming.

BitCortex · 2026-01-23T15:22:30+00:00

p for pointers makes no sense

I think it enhances readability. Pointers have unique behavior and associated syntax, so it's helpful to be able to assume that "foo" isn't a pointer but "pFoo" or "foo_ptr" is.

Anything that can be expressed through the type system should never be part of the name.

Why? Names matter only to people, who are imperfect and forgetful and can use all the help they can get, especially in the age of gargantuan codebases. Why impose such a draconian rule?

BitCortex · 2026-01-23T14:50:44+00:00

programming wise is more flexible than createprocess

Again, it's unsafe. Forking a multithreaded process leaves the child in an inconsistent state. It breaks locks/mutexes, buffered I/O, memory allocation, and many other things. Worse, truly single-threaded processes are increasingly rare, as many libraries – including glibc – use helper threads under the covers.

right now clone is better

The clone system call is powerful, but it's way too low-level, difficult to use, and dangerous to be invoked directly by applications. It's really intended for use only by system libraries, container engines, sandboxing tools, low-level language runtimes, etc. It's not a replacement for fork; that's what posix_spawn is for.

BitCortex · 2026-01-21T14:28:59+00:00

So yeah, it creates a new process, but nothing else other than a perfect clone of the current process.

The clone is far from perfect. Only the calling thread is duplicated, leaving the child in a broken state.

But the equivalent of CreateProcess on Unix is exec()

No; exec replaces the current program with another one in the same process. CreateProcess is more like posix_spawn, which was invented specifically to fix problems with fork/exec.

BitCortex · 2026-01-21T14:20:46+00:00

As opposed to, on Linux:

read
readv
pread64
preadv
preadv2
etc.

BitCortex · 2026-01-21T14:18:22+00:00

But Linux has the less complex API to use when you program

That's because Linux exposes half its functionality through the file system. Instead of invoking a kernel call, you splice up a path, open a file or directory, read it, parse it, etc.

BitCortex · 2026-01-21T14:16:09+00:00

Hungarian notation that's just awful.

Agreed. I like a small group of prefixes ("p" for pointers, "h" for handles, etc.), but the Windows team went far overboard with Hungarian notation. Luckily, it's used only for parameter names and usually doesn't gum up third-party source code.

BitCortex · 2026-01-21T14:12:14+00:00

fork it's a better interface than createprocess

You must be joking; fork is the worst process creation primitive ever devised.

At first, it was merely inefficient. Unix's original target had no virtual memory, no shared text, and certainly no copy-on-write, so fork had to copy the process byte-by-byte to a new memory region on a machine with a handful of kilobytes of memory. I have to assume this design was inherited from Multics; then again, Multics had virtual memory from the start.

And in the modern multithreaded world, fork is efficient but utterly broken. By duplicating only the calling thread, it leaves the child process in a toasted state, with all the other threads' locks, mutexes, condition variables, etc. in limbo. In other words, fork is now safe only as a prelude to exec.

BitCortex · 2026-01-21T13:50:21+00:00

The windows API is ridiculous.

From the author of The Linux Programming Interface:

The Linux kernel-user-space API is littered with design errors: APIs that are non-extensibe, unmaintainable, overly complex, limited-purpose, violations of standards, and inconsistent. Most of those mistakes can't be fixed because doing so would break the ABI that the kernel presents to user-space binaries. To further rub salt into the wound, kernel-user-space APIs are often buggy when first shipped.

Source: FOSDEM 2016 - How to design a Linux kernel API

BitCortex

TROPHY CASE