Personal Website of Levi Neuwirth

I have very strong opinions concerning just about anything related to computation, including Operating Systems. Proceed at your own risk :)

Which Linux Distro / WM / DE do I use?

Trick question. I use two distributions as my main operating system. On my desktop, I run Gentoo with Sway. On my laptop, I run Arch Linux with a heavily modified Hyprland setup. My modifications essentially remove dynamic tiling from Hyprland, as I can't stand it, and make the tiling function identically to i3/Sway. I additionally use a UI that I have written in Quickshell, shell script, and Python. For about 14 months, I used i3. I switched primarily due to the security benefits that Wayland provides over X11; I have no hard feelings towards i3, and, in fact, still feel a strong love for it. I also interact with Debian and Red Hat Linux fairly frequently, as they are used by systems that I ssh into at Brown's Sunlab and High-Performance Computing Cluster respectively. 

I don't have a strict preference between Gentoo and Arch, but I do believe that for me they are the two distributions which work best. I do find that Gentoo is maintained far better than Arch is. I am active on both the mailing lists of Arch and Gentoo.

Rolling Release? Bleeding Edge? Stability?

On the contrary, I do have a very strong preference for rolling release distributions (like Arch, Gentoo, et al.) and a strong disdain for frozen release distributions (like Debian, Ubuntu, et al.). There is very little to be gained in terms of "stability" from freezing software updates, yet this practice incurs outrageous security costs, not to speak for the inefficiency it creates within the development teams of those distributions. Rolling release and bleeding edge are often confused - you do not have to be on the bleeding edge to use a rolling release distribution.

Desktop Environments?

Once again, I have a general disdain for desktop environments, and a strong preference for window managers. However, I also understand that many folks would prefer a desktop environment in the style that they are used to from other operating systems, so I encourage work on adequate desktop environments, of which unfortunately there do not currently seem to be any. If you want a refined desktop environment, I would recommend using MacOS instead of Linux.
  • The GNOME project seems to be led by ill-advised folks who take massive dopamine hits from subjecting the userbase to feature creep and bloat. They must have separated from GNU because GNU actually knows something about how to write quality software, while GNOME very clearly does not.
  • I have not tried KDE extensively, but I found that it was emulating Windows in terms of feature creep. I prefer a more minimalistic system.
  • I tried using Cinnamon out of curiosity, and found that it crashed roughly every 19 seconds.

One of the principal benefits of Linux and the Unix philosophy in general is customization and extensibility. When you use a desktop environment, this crucial aspect of the Unix philosophy is lost - control over your system is abstracted away to the authors of the environment, and they are most likely enthused by feature creep. On the other hand, a good window manager like Sway does nothing but handle windows, and otherwise gets out of your way. In general I am an advocate of an idea presented in the linked Wikipedia article: "Write programs that do one thing and do it well." 

I have not even made my case about how much more efficient use of a system with a window manager is over a desktop environment, because the above points are enough.

A word on compilation and static linking

In general, I prefer to compile code that I am going to run from source. I can apply the flags (much more conveniently with Gentoo and portage) that I would like, and play around with settings to see what works best for my system.

The primary reason I run Arch and not Gentoo on my laptop is just due to the constraints of the CPU. I cannot expect the laptop to compile as quickly, and the laptop is certainly not able to regulate temperature as well during compilation times. Compiling the Linux kernel on my laptop, for instance, takes 30-35 minutes.

I am an advocate of using static linking much more often than most people do. Usage of static linking is an actually beneficial way to use available RAM and system resources with results that one can profile, as opposed to doing so in the name of developer laziness (see "electron" below).

Systemd and glibc

I use both systemd and glibc on my desktop and laptop, but only out of reluctant necessity.

  • systemd has serious flaws.
    • It violates the core principles of the Unix Philosophy.
    • Seriously, don't refer to systemd as an "init system." That is about the least of what it does.
    • The large amount of tasks handled by systemd's bloat and non-modular design leads to increased attack surface and generally slower boot times.
    • systemd doesn't care about POSIX.
    • Lennart Poettering is a leader who often goes against the wishes and philosophy of the community, for better (technical ideals) or for worse (pragmatic ideals).
    • His choices lead to the situation described below.
  • glibc has serious flaws.
    • There is very little emphasis on security in glibc.
    • The vast amounts of bloat in glibc lead to increased attack surface in general.
    • The bloat is not justified by performance; glibc is far from the most performant standard library implementation.
    • glibc is "designed to be portable," yet it is highly Linux specific and essentially unsuitable for use with any other kernel. That seems to be the opposite of portable to me.

In principal, I would much rather use something like musl for my library and OpenRC for my init system, but these would incur too much of a usability hit. Unfortunately, we have reached a point where developers operate under the assumption that all Linux systems are going to use systemd and glibc, and so many programs that I use on a day-to-day basis would not work if I say switched my library for musl.

I take other hardening measures where reasonable and possible, such as compiling my Linux kernels from source and with most modules blacklisted.

Other Operating Systems

In the past I have daily-driven MacOS and Windows 8.1, Windows 10, and Windows 11. My conclusions about them are as follows:

  • MacOS is a fine operating system, but unfortunately subjected to telemetry and severe privacy violations.
    • If you don't mind those privacy concerns, and want a desktop environment that works, it is a good choice.
    • It's far better than Windows in terms of privacy, and also just about any other criterion.
    • At least some source is available (XNU)
    • It's a good place to learn about Unix commands and structure before switching to Linux.
  • Windows is perhaps the worst contribution to technology made by any organization in the history of technology.
    • Everything about Windows is about bloat, enshittification, advertising, telemetry, and inefficiency.
    • I remember back when the File Explorer actually did its job...
    • Seriously, Microsoft? You can't uninstall Edge, which itself is just a useless fork of Chromium?
    • You are a commodity to be bought and sold if you use Windows.
    • Microsoft implements the C/C++ standard libraries just to then create a copy of another programming language (clearly they only imitate instead of create), just to then run an entire web brower with every program instead of using the programming language they created?
    • "Security" is just a buzz term for Microsoft; they actually care about forcing you to buy new hardware when your old hardware would've done fine.
    • Windows BitLocker encryption was clearly not written by anyone who knows about how to do encryption.
    • Windows is ransomware: pay us, or your files that we discretely moved to OneDrive are gone
    • Any computer that runs Windows can be hijacked at any moment to forcibly install updates.
    • You can no longer use Windows without an account and internet connection.
    • NTFS is far from "new technology"; it should be called Obsolete Technology filesystem instead.
    • Windows 10 was a major tragedy when compared to Windows 8.1 and prior versions. It introduced widespread telemetry out of the box and advertising.
    • Windows 11 was even worse, pushing useless "AI" tech and horrifically insecure and indignant dystopian nightmares like Recall.
    • If you have a choice between using Windows and just not using a computer, I would choose not using a computer.
  • Weenix is the operating system kernel that I wrote in the first half of 2025.
    • It's better than Windows, which is essentially saying nothing.
    • It can't do networking, nor anything beyond simple text graphics.
    • It can run just about any simple C program / ELF binary in userspace, however.
    • It can do dynamic linking (but, you should consider whether dynamic linking is actually *really* any better than static linking...).

Electron

Electron is the worst development ever to occur in the realm of software. I vehemently refuse to use any program that incorporates electron (which I say is unworthy of capitalization) wherever possible, and I urge you to join me. Not only has electron significantly contributed to pointless software bloat and remarkable inefficiency - it has also distilled laziness and terrible programming habits into the workflows of many organizations and developers. If you take pride in writing code, whether for fun or for a living, do not use electron!

Anyone who programs with electron is essentially saying "I am so lazy or incompetent as a programmer that I can't take time to read documentation about native graphics frameworks on any platform and use them, so I would rather bundle a huge codebase (Chromium) which I've probably never seen, don't know anything about the inner workings of, and don't care enough to investigate, instead of taking the time to write a program the real way. Rather than build a program which uses reasonable amounts of resources and does not constrain the system, I would prefer to use hundreds of megabytes or even gigabytes of memory, incredible amounts of CPU utilization, and massively bloated binary sizes just to save myself a little bit of effort." 

Programming Languages

  • My favorite programming languages are C and Rust.
    • Good C code is elegant yet easy to understand, and C has remained a very simple language in contrast to its hideous relative.
    • Rust makes writing memory safe code easy, and takes the best parts of object-oriented programming without forcing that paradigm on anyone. 
    • Performance and efficient resource usage are important to me, if you couldn't tell from my rant about electron.
  • I think that there are many other fine programming languages, but they are generally less ubiquitously useful that C and Rust.
    • Go is a phenomenal language that I try to use where I used to use Python, with really exceptional concurrency.
    • That's not to say that Python is a bad language - it is quite nice for AI-related tasks, scientific computing, within the shell, etc.
    • I prefer to use Python over R for statistical computing, but use both.
    • I quite like Lisp, but the parentheses syntax does at times drive me crazy. At other times it is quite useful for clarity
    • I'm currently (fall 2025) doing some work in Haskell and really enjoying it. This is a phenomenal language that I will continue to use as I learn more.
    • I have worked in both C# and Java in the past, and think both are fairly nice to work with in certain use cases, but I would now go with Go or Rust in just about any of the cases where I used to use them. In fact, I actually think Java is quite a remarkable language (and do not feel similarly enthused by C#.)
    • I don't know much about Zig yet, but I'm learning it and it seems pretty sweet.
  • There are a few languages that I think are absolutely awful and try to avoid using where possible.
    • C++ is insanely bloated, makes it easy to write unsafe code, and is just an unpleasant experience in general. I will use Rust anywhere that C++ might be used when given the choice, but unfortunately I'm still required to use C++ in many instances.
    • I understand where the design choices of JavaScript come from, but I find working with the language absolutely irritable and avoid using it wherever possible. This is part of why this website has no JS.
    • I find TypeScript to be a slight improvement over JavaScript, but still absolutely irritable to use.
  • Assembly depends a lot on what ISA is being used.
    • I find RISC-V assembly a great pleasure to work with. It's easy to understand, very well documented, and the design choices are excellent and explained thoroughly and convincingly in the documentation.
    • On the other hand I quite dislike working with x86 assembly, though I have gotten proficient at it from developing a kernel. The ISA is in general bloated and that makes it very nice for compilers but painful for humans.
    • I haven't interacted with ARM assembly before.
  • I am not a blind advocate of any programming "paradigm".
    • Using the term "paradigm" makes it seem as though languages can be classifed as if we were pattern matching in Haskell. In fact, languages are very unique and don't fit into such naive classifications, as badly as some of us may want them to. I discuss specific features of programming languages at more depth below.
    • I quite like functional programming, and enjoy writing functional code in general, but I also acknowledge that it is not well-suited for all tasks.
    • Similarly, I somewhat dislike writing pure object-oriented code (thinking Java style here.It feels like a grotesque amount of boilerplate is often required, but I also acknowledge that it is very well-suited for some tasks. (And, under the hood, implemented nearly identically to functional "paradigm" features.)
    • I appreciate languages like Rust allowing for use of the best parts of OOP and FP.
  • I have more well-defined opinions on specific features of programming languages than "paradigms" or other naive and lossy classifications.
    • I am really not a fan of garbage collection, but I understand why it is convenient to have. In any app where performance is an absolute priority, garbage collected languages should probably be avoided. Additionally, one might think that garbage collection improves safety due to preventing the memory safety issues that C/C++ are notorious for, but hear me out - let me play devil's advocate. Garbage Collection simply shifts the burden of memory management to the language runtime rather than the programmer, which has a net negative effect. This net negative is comprised of two negative aspects: first, the amount of code that all programs of the language have to implicitly trust increases, or, the surface area of the runtime increases - this is bad regardless of whether the code is terrible or code is perfect; it's bad in principle - and second, any memory safety vulnerabilites which are found will now affect EVERY program written in the language, not just the one where a programmer made an error. This can lead to devastating consequences.
    • I have a strong preference for static type systems and static scope. The more aspects of a language that are dynamic, the more ambiguity that is possible in programs of that language (looking at you, JavaScript) and the higher the performance impact incurred (looking at you, Python). Static types provided for what I think is the best implementation of OOP (Java) and, in terms of the functional realm, they all seem to understand this.
    • I think Rust and Haskell have unique ideas that more languages should adopt. Immutability should be the norm, and we should treat side effects like the plague.
    • I have a strong preference for native (POSIX) threads rather than threads implemented in the language runtime, like goroutines. The operating system provides interfaces to use for our convenient usage. Let's use them!
    • I am fascinated by proof assistants, especially Lean. Learning about them is a high priority of mine in my free time. Unfortunately during this fall semester of 2025, I have very little free time. I'm looking forward to pulling this one off the shelf soon.