That’s misinformation,. Rob Pike, Co-Author of the first Unix, described in The Practice Of Programming, a book published in 1999, how they were fuzzing these tools.

I am using Unix/Linux for over thirty years now, and the older I get, the more I like it simple.

Debian with Arch in a VM, and Guix as extra package manager on top of both for programming projects. I use Debian for stable stuff and Arch for new stuff.

Stumpwm as manual tiling window manager, or i3wm, or Sway if the first is not available. Somtimes GNOME.

Emacs with language server (lsp-mode) for programming. Vim frequently at work for embedded tasks.

Gollum wiki or Zim wiki for knowledge management.

I am thinking since a while that AI tools, as useless as they are generally, could for once become helpful in checking freshly developed code. Even if the actual code is smart, most bugs are in reality pretty dumb.

By the way, in the medium term, generalizing this development from the kernel to general distro packages, this could be a good argument to prefer using a rolling-release distro like Arch, SuSE Tumbleweed, or Guix over “stable” Distros like Debian or Ubuntu.

Debian has real advantages (it has one of the fastest response times to security vulnerabilities), but rolling release distros do have the advantage not only that they in theory can update fast, but that the dependent packages only need to be compatible with the latest version to ensure stability.

You could think that this development puts open source projects at a disadvantage.

But this does not seem to be the case: AI tools can also be used to automatically disassemble and even decompile closed-source code machine code, leaving it open to the same kind of analysis.

And organizations have super high pain tolerance.

The organization slowly evolves along with the complexity in a demented kind of synergy and learns how to deal with it.

That rings so true.

But the thing is, pain is a warning signal. If you go jogging completely drunk and hit a tree with 6 mph, it will be painful, yes, but the pain will warn you not to do it again.

But what if you move 12 times faster?

If you drive a light motorcycle completely drunk and with no helmet, and hit a tree, pain will not be able to save you.

For company legacy codebases, yes they are dysfunctional but they have found a kind of precarious equilibrium in so far as they exist because they are making money and thus are useful by some metric. The slow movement and requirement to work somehow balances the unstoppable (with in company practices) growth of entropy and messiness.

And in a way, the money is an analgetic for the pain. Or more sharply, big companies act like junkies on a money drug because money is the only thing that ever counts.

Figure what happens if entropy is grown 100 times faster…

• The Jepsen project, which performs heavy testing of distributed database engines, and often finds bugs, is written in Clojure: https://jepsen.io/
• The Maxima computer algebra software is in Common Lisp
• The ITA flight fare search and pricing system is in Common Lisp
• and my beloved tiling window manager, stumpwm, is also written in Common Lisp

Emacs, for configuring the whole editor. (Has an own dialect, Elisp.)

Emacs has its own Lisp dialect because it is one of the longest-running software projects in existence. Work is underway to port its core to Guile, while maintaining Elisp compatibility.

Clojure, Racket and Guile are really nice. But especially Common Lisp is underrated - it is an interactive, compiled, high-performance language. What Lisps often suffer from is a lack of libraries compared to Python. For example, Clojure and Kawa run on the JVM. Guile has good POSIX bindings. Steel is implemented in Rust and can call into it, which means it can use its libraries.

Haven’t tried it, but functional programming methods (as in Clojure) combined with Datomic / Datalog sound interesting. It is said to be quite good.

The terms on the right to use user data in section 4.1 are also a bit surprising. I’d expect that from a social network like Facebook, but not from a text editor.

Oh, and I suggest to search the Arch wiki for suggestions for Linux software that match what you want to do. The packages named there are usually available in other major distros, too!

That also happens to be good advice if you want to reduce addictions that are caused by “addictive by design” platforms and parasocial media.

In a nutshell, it is like controlling smoking: Not doing it at all is often easier and costs much less energy, than controlling the extend of usage.

One reason for this is that such a decision shifts your sub-conscious fous from "Should I do this on Linux or Windows??“ to: “How do I do this in Linux - or what might I enjoy doing instead?”

You’ve inherited a 300k lines of spaghetti code. What do you do now?

Quit.

The grain of truth in this is that organizations which have accumulated a lot of technical debt tend to continue to be organizations which accumulate a lot of technical debt.

Let’s say you take a new student job as a kitchen helper in a restaurant, and on day one, you learn that people there don’t really wash the dishes - they just make them look somehow clean.

Do you walk to your boss and tell him: “Hey boss, I got an idea, we could wash our dishes, what do you think?”

It is different if you have more of a say, as in, you are the chef. You could leverage that good chefs are hard to find. You could point at customer reviews with complaints.

But as an apprentice, I would advise to look for a better kitchen. Especially since tidying up 300 k lines of spaghetti code will take many person-years.

Fix the warnings first. By all experience, later is never.

First specs, then a (perhaps semi-formal) API description, then implementation, then first tests, then fix warnings, then rigorous tests, then fix all bugs before adding more features. It sounds contra-intuitive, but you go faster this way.

My feeling is that might be a lack of choice here. So, just my 0.00002 cents, to supply you with a few more options:

• Just use Debian. It is boring but it will work.
• Or, Tumleweed has been named. But it is not maximally stable. Better, use Tumbleweed in a VM on top of OpenSuSE leap. That way, you have both superb stability and a very current system.
• You could also sell your nvidia card (let’s be honest, it probavly will only bring you grief), and get a AMD radeon which is fully supported by a libre kernel. Then, you can install Guix on it. Then you have a truly reproducible, very lean and organized system.
• If dropping the nvidia card sounds too extreme for you, you can also install Debian, and install Guix as a package manager on top of it. That will work because the Debian kernel supports the hardware. But don’t forget that NVidia is a nuisance, often. Well, you might have luck.
• Let’s say you are short on money and you don’t want a system that consumes too much RAM, since that has gotten expensive, man. So, you could get Debian with XFce as Desktop environment. Or, even leaner, you could get ICeWM.
• Or in case you want a very fast Lisp-based window manager with very fast, manual tiling, try StumpWM, say, on Debian.
• Or, if you want an automatic tiling WM, give i3wm or sway a try. Or GNOME with paperWM extension.
• GNOME would also run on Ubuntu, or on Mint. Actually, it is all Debian under the hood, mostly. Just easier to install.
• Or you want a privacy-focused Distro. Try Trisquel.
• Or, you just want to keep it simple, perhaps. In that case, I’d recommend Debian. Or, perhaps for the start, Debian-derived distro that is easy to install. There are plenty.
• But when you want to have it even simpler, get rid of the nvidia card. This really simplifies things.

You have to imagine Alice, Bob, and Carlos 25 years later, working on production code that was created like this.

XKCD on this: https://m.xkcd.com/2730/

By the way, I am currently working on a 20 year old code base that was in production use all the years and was continuously adapted. At least the people who wrote this were (more or less) knowing what they were doing. I guess I should ask for a pay rise…

Wait, you guys still haven’t tried cocaine?

Using it you can work with much more energy and focus! You don’t get tired either!

The thing is… to test such code, you often need to modify it first.

You see the problem?

You could try the Mikado Method. It is good for disentangling code with a mess of complex interdependencies.