What's so interesting about tiling managers? I've been using i3. But my usage is so simple (I guess) that I have just a few windows maximized in tab mode, usually just two: browser and terminal. I rarely need to split vertically. To be fair I like i3 simplicity. But I'm not really "wooed" by i3. I may be missing something?
For me it the epiphany was that I either want one full screen window, or several windows side by side, I never want one window to obscure another window. And with our modern wide monitors I almost always want several windows side by side. Why do I have to line them up by hand?
The downside is that there are many poorly programmed applications that are unable to adjust themselves as the window manager requires(calling you out steam, or it just may be me but steam was not happy with a tiling wm), and model dialogs, which always suck, suck even more when tiling. But most tiling wms's support a float mode for just that occasion.
Tiles were a common early metaphor, And I think tiles are generally more useful but floats looked cooler in the ad copy and so that is what ended up as the dominant desktop metaphor.
On the subject of one window partially obscuring another window the only tech that makes that halfway tolerable is "don't raise on click" and "point to focus" This lets you look at the upper window while manipulating the lower window. two features not found on the major desktop systems. X11 has it's warts, and is very weird. But it is miles ahead in actual usability over it's peers.
Depends on your screen size. On my laptop, I follow pretty much the same pattern you do, so I actually stopped bothering with XMonad.
But on my desktop with two 27" monitors, I find tiling incredibly useful. It's really nice to be able to quickly arrange a mix of Emacs windows, browsers and random other programs to use all that space. If I need to closely read through some documentation while also looking at code, I can quickly open a browser next to the code window. Later, when I want to focus on just code, I can send the browser to the other monitor or to a different workspace altogether. And I can juggle "side" stuff (chat windows, OBS, music, whatever) just as easily.
The key thing is that XMonad with some lightly customized layouts gives me the operations to do all of this quickly without needing to think about it. It only takes a couple of keystrokes to get to the state that I want at any time and, after a pretty short time, those keystrokes became muscle memory. Using a mouse to drag things around is more intuitive and flexible, but it requires shifting my attention far more than just using a single keyboard command. (And thanks to ADHD, that kind of distraction can be a real drag on my mental energy!)
I've used dwm for years and recently switched to niri and really, really like it.
I'm with you, that tiling vertically is not useful. Niri aligns better with my innate mental model: just keep adding new panes to the right offscreen that I can scroll through, then I can swipe up and down for more lanes to do collections of different tasks.
I feel much more productive doing read/write tasks, like viewing tickets + code or PDFs + tickets and so-on
And of that interesting stuff, how much can't be had just by configuring the window tiling shortcuts in floating window managers to have the best of both worlds?
The japanese have it harder because "ai" means love. But perhaps "love" will be written in kanji while "AI" in katakana, so writing form is not confusing.
> Every time I try and learn Vulkan I end up getting confused and annoyed about how much code I need to write and give up.
Vulkan isn't meant for beginners. It's a lot more verbose even if you know the fundamentals. Modern OpenGL would be good enough. If you have to use Vulkan, maybe use one of the libraries built on top of it (I use SDL3 for example). You still have freedom doing whatever you want with shaders and leave most of resource management to those libraries.
> But you're right: ulimately the kernel is just a program.
Play a bit with user mode linux [1] the kernel becomes literally a linux program, that I believe you can even debug with gdb (hazy memory as I tried uml last time maybe a decade ago)
In theory you can also attach gdb to qemu running linux, but that's more complicated.
And User Mode Linux was the basic technology for dirt cheap (not so) virtual machines at some VPS providers 15yrs ago. This had some disadvantages, for instance you could not load custom kernel modules in the VM (such as for VPN), actually you could not modify the kernel at all.
It's 2000. Build failure was pretty much expected for any software. Probably a good idea to stay home and work through any problem. Nowadays you'll just fire up a build and go. And the build is probably finished before you're out of the door.
Yes. I never had problems with Linux itself and compiled kernels constantly. What I did have incessant problems with was compiling GNOME 1.2 and 1.4. SO MANY problems, just non-stop... it was always something. I learned a bit though, although not as much as I could have if I paid attention more.
> I get your point, but reviewing your own PRs is a very good idea.
Yes. You just have to be in a different mindset. I look for cases that I haven't handled (and corner cases in general). I can try to summarize what the code does and see if it actually meets the goal, if there's any downsides. If the solution in the end turns out too complicated to describe, it may be time to step back and think again. If the code can run in many different configurations (or platforms), review time is when I start to see if I accidentally break anything.
fuse probably isn't a good example here because you still have to enter kernel space if i'm not mistaken, then out again to the fs driver in userspace then probably back to kernel space (block driver). fuse has many upsides, but I don't think performance is one of them.
Well, you still have to enter the kernel to actually queue an OS-level thread w/ a futex. The kernel supporting being able to move stuff to userland sure doesn't guarantee better performance-- the main opportunity from that perspective is minimizing how often you cross the boundary.
You're 100% right that there are plenty of other considerations, often positive for lifting things out, like minimization of ring 0 attack surface.
Futex is a fine solution for locks and semaphores (FUTEX_WAIT/WAKE operations). It's been extended repeatedly to handle the needs of condition variables, priority inheritance, timeouts, interop with file descriptors and async/io_uring, etc... with the result that a lot of the API exists to support newer operations with oddball semantics and not a few genuine mistakes and traps (often undocumented). See the glibc condition variable code for how complicated this can get.
Also, while googling for some examples for you I was reminded of this LWN article from a few years back that details some of the issues: https://lwn.net/Articles/823513/
Just because the Linux futex call is currently a Swiss Army knife with some parts that add no value (which I do say in the article) doesn't mean that it's not valuable, or important.
The fact that Linux has extended it in so many ways is, in fact, a testament to it to how impactful the futex concept has been to the world of concurrency.
The fact that it's also at the core of other OS primitives does as well. At least on the MacOS side, those primitives do have much simpler APIs, as well. For instance, here's the main wait function:
The wake side is equally simple, with two calls, one to wake one thread, one to wake all threads. No other number matters, so it's a great simplification in my view.
Your fundamental point is that the futex is actually a pretty unimportant construct. Clearly I don't agree, and it's okay not to agree, but I really am struggling to see your counter-argument.
If futexes aren't important to good locks, then, if modern OSes all felt compelled to jettison the futex for some reason, you'd have pthread implementations do ... what exactly??
The WTF::ParkingLot example is interesting because it shows that you don't actually need futexes in the kernel to implement them efficiently; you just need something like a spinlock (with sane backoff!) to guard the userspace wait queue and a per-thread eventfd to wake up waiters.
Yes, you can do a good futex impression in userspace and add any missing functionality you need. Most importantly for webkit, I think, you get portability.
The advantage of futex provided by the kernel is ABI stability and cross process support.
reply