I should do that. I have almost 900 Steam games, the vast majority of which I have never touched. Over the years with sales and Humble Bundles, I've just hoarded the games because I might someday want to play it.
Instead all I seem to do is replay Donkey Kong Country 2 and Streets of Rage 2.
> It starts with much worse quality (not Linux' fault), like worse displays, borderline unusable fingerprint scanners, etc.
Interesting; one of the primary reasons I bought my current machine (Thinkpad Gen 2 AMD P16s, rolls right off the tongue) was because it was one of the few laptops I could find that had a 4K screen. The screen on this computer looks pretty good. Everything looks sharp, relatively high-contrast, and it gets very bright.
Honestly this has been the least-headache-inducing Linux laptop I've ever had.
You're right about the battery life. Even with Sway, and even mucking with powertop, I still don't get nearly as good of a battery as I did with my Macbook. I haven't had the issue with suspending though; I've had the system suspended for multiple days and woken it up with plenty of battery.
> People who complain about Linux usually either insist on customizing it (as you noted) or run it on hardware that it doesn't work well on.
Even as someone who has customized the hell out of my desktop, it does kind of annoy me that people act like you "just" need to customize it.
"Customizable" is (often) just a synonym for "incomplete". Instead of giving you a full operating system, you have to "customize" it. Or, realistically, finish it. For example, much as I love the Sway desktop, I really don't feel like the stock package is decidedly unfinished and you need to install/make plugins to make it actually usable.
> If you are willing to buy special hardware to run macOS, why not the same for Linux?
Agreed. I like macOS, but macOS is a very walled-garden, and for the most part you can only run it on very specific, curated Apple hardware. Of course it works properly...they have a very finite set of hardware to test, which is untrue with Linux.
If, when you buy a computer that you plan to run Linux on, you preemptively make sure that the hardware is compatible [1], then it usually works fine. When I bought my mother-in-law's Thinkbook, I made sure that the main hardware worked fine (e.g. graphics card, wifi, audio, etc.). It did, I installed Mint on there, and she seems to like it.
[1] https://github.com/NixOS/nixos-hardware Even if you don't run NixOS, this is useful; if the laptop you're buying has very few or zero hacks required, it will likely work out of the box.
I am a pretty die-hard NixOS cultist, but I will admit that I actually like macOS. I used macOS almost exclusively from 2020-2024, until I bought my Thinkpad that I have now, and I never really disliked the operating system (though I did have issues with that particular laptop because of the i9 CPU's propensity to thermal-throttle).
Despite me preferring it, it is hard for me to say that desktop Linux is "better" in any kind of objective sense than macOS. I do think that desktop Linux is significantly better in most senses than Windows, but macOS is a stable, easy-to-use distro that performs fine. While I kind of hate the "Just Works" slogan it has, I will admit that that's significantly truer than Linux. It's 2026, and I still have issues having Linux properly work when I plug in an external monitor into a laptop.
All that being said, what I like about Linux is that it can run on basically anything, including existing computers that you (or your relatives) likely already have, and it will likely perform better than Windows if for no other reason than it won't be filled with as much bloatware bullshit that most OEM Windows' has.
A good Macbook is pretty pricey. A Macbook Neo is cheaper, but you know what's even cheaper than that? Extending the life of the computer you already have!
I'm fairly happy with my obscenely over-customized NixOS Sway desktop, and I probably don't really understand the sunk-cost fallacy so I'm unlikely to ever leave, but I don't blame people for doing so. As long as they don't defect to Windows...
I remember a million years ago, when I was writing apps with Cordova/Phonegap, I would use Web SQL to do all my storage [1]. This kind of reminds me of that.
I always thought that there should be an easy way to export it, but I don't think that ever materialized.
I ended up just getting Claude to hack together a compatible-enough S3 thing for my self-hosted Sourcehut releases. It took like 45 minutes and it seems to work well enough (though I haven't done exhaustive tests because "good enough is good enough" for this).
The S3 API is pretty well-documented so getting something compatible with it is trivial for modern AI tools.
> One thing I think Lamport falls short is that his writing is not easy to read and understand
Interesting; I actually grew to be a fellow admirer of Lamport primarily because I actually found his papers to be a lot more approachable and relatively straightforward.
Every time I see one of these articles I will, very briefly, get optimistic that people will move to an operating system that isn't terrible, and then realize that most people will literally just forget about the bullshit they put up with Windows.
I don't know what kind of reality distortion field Microsoft generates, but for reasons that are still unclear to me, people will literally simply forget every single awful thing Windows does.
People will (correctly) call out the jankiness of desktop Linux, but tacitly imply that Windows doesn't have jankiness. They will forget all the times that Windows Update bricked their computer, or all the time that their "repair" tools were literally just no-ops, or their copy-paste feature not working, or Microsoft literally breaking fucking Notepad, or the "System Restore" tool not actually restoring anything.
Desktop Linux certainly has its issues, I'm not so deluded as to say that it's perfect, but I really feel like its bullshit-level is lower. Oh, and since it supports filesystems that didn't coexist with dinosaurs, the snapshotting actually works.
Instead, I'll be stuck playing tech support for Microsoft's shitty products for my parents until the heat death of the universe.
I'm not. It seems to be something that affects nearly every person who uses Windows by choice. It's actually kind of a testament to Microsoft's marketing that they can continue to release terrible, broken products and people still keep purchasing them.
The alternative to Windows for the majority of people is MacOS. Throw out or sell your old PC and get a Mac, they can be had for cheap in great condition second hand. Or an iPad with a keyboard, which is best for the elderly or other people who need to just pay bills, read news, and write e-mails.
Another reason that users put up with Windows is simply because that's what the computers at their job have. The employer has decided on Windows, and when the Windows/Office users get back home from work they don't even touch a computer.
I think desktop Linux has improved significantly, and I do think that most people would be fine with one of the more normy-friendly distros like Mint, but I think macOS is a lot more approachable for most people.
I set up my mother in law with Mint, and she seems to like it just fine, but honestly if the MacBook Neo had been around when I bought her that laptop I probably would have just done that instead.
In a bit of fairness to my dad, he does use most of the features of the Windows version of Excel more than literally anyone I know, including the VBA and the like, so there would be a learning curve going to the Mac version of Office or migrating to OnlyOffice or something.
I tried showing him my laptop running Winboat but he was unimpressed. Maybe eventually Valve will figure out how to get full-fat Office working with Proton.
I genuinely had not heard of anyone actually using a spinlock in production code until I started using LMAX Disruptor a few years ago.
I was always told that they were an anti-pattern, and I think that generally that is a pretty good rule of thumb, but I guess like most stuff in CS: there are always exceptions to "good rules of thumb".
I still haven't actually explicitly written a spinlock for anything in production, but Disruptor has shown me that there are cases for it.
Before we had futexes in the Linux kernel, spinlocks were used to boostrap the implementation of everything else in the user space threading library.
If you have futexes you can try to grab a lock with an atomic operation and if that fails, go wait on the futex via system call, so there is no need to spin. Spinlocks then remain useful as an optimization, because there are situations in which it is cheaper to spin around a bunch of times until the thread on another processor gives up the lock, than to take a trip into the kernel.
You can also spin, but with a scheduler yield in the loop; we don't normally think of that as a spinlock. That's what you fall back on after spinning some number of times and failing to get the lock.
In the Linux kernel, spinlocks are the low level primitive. They are very efficient because unlike user space threading, they are not faced with guesswork about scheduling. They are "surgical".
To be really pedantic, it's a spin wait, not a spin lock in disruptor. You are waiting for a sequence, not mutually excluding some resource. Many threads can watch the same volatile at the same time without blocking each other.
If you have an application where your threads are pinned to dedicated cores, and those cores are all isolated from general OS scheduling, then it's the lowest latency means to synchronize arbitrary things between threads
Entering the kernel with a futex wait or wake under contention costs a couple of microseconds, whereas a spinlock will cost you double digit to low triple digit nanos depending on cores/sockets etc
Thanks for sharing. Can someone tell me what does this paragraph mean?
> Use a lock where you tell the system that you're waiting for the lock, and where the unlocking thread will let you know when it's done, so that the scheduler can actually work with you, instead of (randomly) working against you.
I have “implemented” a sleep lock in xv6. Is it what he meant? What does the Linux scheduler “know” about it and will do differently? (Trying to figure out what does “work with you” mean)
In simplest terms: if you don’t tell the kernel that you’re waiting, the scheduler assumes you aren’t and will wake you up and let you spin, to the detriment of other threads that aren’t waiting.
If the OS knows that a thread is waiting for a lock, the scheduler will not bother to schedule it until the lock is available.
In general, it’s tempting when you’re bound by lock latency to skip the syscall overhead of sleeping. But a lot of the time that’s a code smell that there are other inefficiencies in the system and you should rethink how you’re scheduling work.
The basic idea is that a lock should be something the OS is aware of, so that while a thread is blocked on a lock, the scheduler never tries to wake it at all, and when it is unlocked, the scheduler can wake up the thread that's waiting on it immediately. If the scheduler isn't aware of the lock, it'll just try to wake up the thread periodically, often just wasting CPU when it's still blocked or kept asleep when it could be running.
I think he means that if the OS knows about locking, it can manage a list of "waiters" to quickly know which thread to wake (resp. let sleep) once (resp. before) the lock is released.
> Note that even OS kernels can have this issue - imagine what happens in virtualized environments with overcommitted physical CPU's scheduled by a hypervisor as virtual CPU's? Yeah - exactly. Don't do that. Or at least be aware of it, and have some virtualization-aware paravirtualized spinlock so that you can tell the hypervisor that "hey, don't do that to me right now, I'm in a critical region".
I can't be the only one who learned this the hard way by cramming too many vCPUs onto too few physical cores and initially wondering where the high load and latencies came from.
One use case I’ve found is for a lock that you don’t need to acquire. For example, you need a lock to read a cache entry, but if you can’t acquire the lock after a few spins, you can just proceed without the cache. For fine-grained locking, a spin lock can have a significantly lower memory overhead than a full futex.
ARMv8-A has atomic CAS, unless this is some silly definition thing where it's "a system that has the behavior of atomic CAS but is named something else."
Maybe that's the trap I'm falling into? From memory it doesn't have any actually atomic operations, only an ll/sc sort of mechanism - which I've never really thought of as an atomic operation?
Though it's true you can end up with the same end result, in that you can just keep trying the operation until you accidentally do a read-modify-write that's ended up - well, "atomic" is a valid way to describe it.
So maybe it is good enough to count, though personally I'm still not quite convinced.
Yeah. I would call ll/sc atomic. Wikipedia's current verbiage:
> Load-link returns the current value of a memory location, while a subsequent store-conditional to the same memory location will store a new value only if no updates have occurred to that location since the load-link. Together, this implements a lock-free, atomic, read–modify–write operation.
I thought it might be fun to have a “proper” search engine for my laptop, so I wrote a thing (with my fingers! No Claude Code or codex here!) to scan my home directory and put data into OpenSearch so I can search stuff. [1]
For that matter, I also decided to self-host SourceHut because I will no longer be in compliance with their new policy. I have the flakes set up to inject them on my server [2]. This was very AI assisted.
[1] https://git.brucewillis.sexy/~tombert/fs_index I promise it’s safe for work, despite the URL. That’s just my dev URL that I play with. Code is still a mess though, so proceed with caution. I will eventually clean it up.
Instead all I seem to do is replay Donkey Kong Country 2 and Streets of Rage 2.
reply