I wonder what will happen to XMonad as the Wayland future actually seems to be approaching. I suppose nothing yet.
But, I was an i3wm user, and now it’s hard to imagine going back to X11. I run SwayWM on NixOS and using Linux any other way feels archaic now. Yes, I do genuinely understand how that seems absolutely ridiculous, but honestly, it does. Other than the occasional stability issue or bug, it really feels like the future is arriving: smooth rendering, predictable latency, hardly an imperfect frame, heterogeneous DPI with no effort, no need to string along GNOME or KDE services to configure input devices or manage displays, yet to experience any problems with sleep/resume, and with NixOS, a simple, centrally managed configuration for my whole OS (including Sway) and any patches, git-versioned. It isn’t perfect, but it is almost as good as promised. I just recently setup a new desktop by grabbing a recent NixOS USB stick, formatting the drives, git cloning my configs, and running the installer, and one reboot later I was in my environment with Sway, all of my applications, my configuration…
I’ve tried versioning my dotfiles before, but this seemed to both be more tedious and still not really accomplish what I wanted. My desktops and laptops are single user, so I can just use NixOS to manage system-wide configs instead and get 99% of what I actually wanted.
I’ve digressed a bit into stuff very unrelated to WMs, but the software around your WM is important when dealing with tiling WMs. Nobody wants a bespoke pile of complex configurations that could break on an upgrade without warning, and that has never been more important than with minimal WMs.
> Wayland: It's becoming increasingly clear that the days of X11 are over and some Linux distros are already switching to Wayland. We're committed to keeping xmonad on X11 stable and alive as long as necessary, but if time allows, we should explore the Wayland ecosystem and figure out what it means for xmonad. Do we go all in on waymonad? Shall we try to keep xmonad a pluggable window-management component for another Wayland compositor? Honestly, we don't know yet. This one is a bit of a stretch goal: we might need more than one person full-time to actually make this happen.
Elsewhere in this thread, I wrote about some concerns I have about waymonad and xmonad on Wayland in general: https://news.ycombinator.com/item?id=28796909 The gist of it is that I'd like to keep the compositor and WM separate, because a) xmonad is reconfigured by compiling/restarting, b) I don't think the Haskell runtime is good for handling input and presenting frames, c) I don't want to maintain a compositor :-).
Hello, long time user first time commenter. ;) Just came here to say that because of this post I went and sponsored XMonad. I want it to survive for decades to come.
Oh, that’s good news. I’ll have to follow along when there’s more progress.
I am surprised, at least somewhat (and as someone with very little Haskell experience,) to hear Haskell may not be a good fit for the compositing bits. That’s a bit disappointing because the stability of Xmonad is probably a big selling point, and even more important with a Wayland compositor, but most of the Wayland compositors have quite a lot of C code. Maybe the same will wind up being true of the compositing bits of the Wayland equivalent of Xmonad.
I can see the utility of using Nix for managing dependencies of software you're developing, because that can be horrific to deal with and Nix makes it fairly elegant to do, depending on what ecosystems it's being used with.
Using NixOS to manage your whole system, on the other hand, I don't think I'll ever get behind. Maintaining reproducible builds of my system, while being nice to have, doesn't really solve any problem that I actually have. On the other hand, it introduced a myriad of problems that plagued me on a regular basis before I switched away from it.
The first problem I had was that it added steps to a number of tasks I had on a regular basis. For example, updating or adding new extensions to VS code. Because NixOS is immutable, you don't get to benefit from just running a single update or install command within VS code like you would on a normal system. It becomes an annoying series of steps you have to carry out for each operation, all in the name of being convenient to hypothetically down the line. Multiply this by all the tools you use and it gets tiresome.
The other issue is that you raise the barrier of entry for every new piece of technology you want to experiment with. Now, in addition to learning how to use any tooling involved with the ecosystem, you have to figure out how to get it to play nicely with Nix. This works very well for some ecosystems, like Haskell, and not well at all for others. I was just getting started with Android development at the time, and just when I thought I had it working nicely with Nix, I would run into a new problem that would need investigation and band-aids.
I wish NixOS was more convenient to use than it was in my experience, because it's nice when it works well. But in my case it created more problems than it solved.
I just use VSCode largely like you normally would, with the augmentation that I start it from a nix-shell invocation. It’s not perfectly immutable, but I’m here to do work, not to perfect ideals. I can understand why some wouldn’t like this, it’s definitely not ideal. I think it’s not too bad though, at least for my workflow.
I don’t have issues with my configuration breaking. My NixOS configuration hasn’t broken due to updates in months.
I will say that some stuff is not easily encapsulated in Nix. Of course, you could always use virtual machines or Docker as an escape hatch. I’ve found this to be a fairly good solution in the somewhat rare event I need it.
My biggest problem with NixOS is the complexity. Nixpkgs is maintenance hell, and the Nix filesystem is so different from standard UNIX-likes that a lot of software plays kinda weirdly with it.
The real game changer is definitely the reproducibility though. At first, it seems useful for software development, but trust me, if you get deep enough in it is way more important for system management. If an upgrade does break, being able to rollback at boot is nice. But what is much nicer is simply the feeling of safety I have going in extreme tangents. I can try setting up Pipewire as my system audio daemon, and if I don’t like it, I can revert it like nothing ever happened. If I run into a bug that has a reasonably good patch stuck in code review hell, I can pull it into my local setup with overlays, replaceDependency and fetchpatch. Setting up IOMMU PCI-e forwarding to a VM is pretty hard, and it sucks that the configuration is basically stored in no specific place, not to mention having to memorize everything you touched to get there; on NixOS, this relatively arduous task was reduced down to about 30 lines of Nix combined with finding some IDs for my secondary GPU. Everyone knows that Linux has some serious super powers if you can exploit them; it is truly crazy what Linux is really capable of. With NixOS, I feel like I’ve gotten a lot better at utilizing the super powers Linux has to offer.
I just can’t go back to Debian or Arch after this, I’ve tried. Maybe NixOS isn’t the final answer, but I’ll be damned if it’s not a preview of the future.
I just can’t go back to Debian or Arch after this, I’ve tried.
I have had this feeling for some time as well. NixOS puts you on a power trip -- you can bring up and tear down systems in seconds; you can relentlessly experiment without repercussions; your repositories work reproducibly.
But I also learned that whether using NixOS is productive very much depends on what software ecosystems you are working in. When I was primarily doing Rust for work in Emacs, it worked marvelously.
When I switched to CLion (for various reasons), cracks started to show. CLion does not work well in combination with nix-shell, so when you switch often between projects, you end up with projects that don't build because you are not in the right environment. Currently, I am doing more Python development, and that is an absolute pain with Nix. You end up needing different sets of package versions (which are not packaged in nixpkgs) in different environments. If you need to change multiple packages in tandem, you want mutable state. The best you can do is to make a FHS environment with buildFHSUserEnv, which kind of works, but is not very smooth. At which point you realize that you are basically fighting the system.
Then there are the niches that are not well-covered. Over the past year or so, I have had to do GPU profiling more recently. Last time I tried, the usual NVIDIA tools (e.g. Nsight Systems) worked very badly on NixOS. Of course, it's a big proprietary blob with all kinds of FHS assumptions, but you need to get work done.
These are not all failings of Nix or NixOS, it is more that there are a lot of software ecosystems out there that are not really prepared (yet) for an non-FHS, immutable world.
but I’ll be damned if it’s not a preview of the future
I think for most Linux users, Fedora Silverblue is probably more of a preview of the future. It doesn't have all the features that NixOS provides, but it does have many that matter (immutable base system, atomic upgrades/rollbacks), while going further than NixOS in other departments (verified boot, SELinux, git-like store of blobs). It sticks to FHS, so a lot of existing software continues to work.
Edit: this comment is about NixOS on the desktop. I think the server is a completely different story.
Another approach is to use a main stream distribution in combination with the nix package manager. You can then always fall back to the distributions native packages.
> It’s not perfectly immutable, but I’m here to do work, not to perfect ideals. I can understand why some wouldn’t like this, it’s definitely not ideal. I think it’s not too bad though, at least for my workflow.
This was my train of thought at the time, too. But now you're just using software normally, but with an extra step, and no NixOS benefit.
> I will say that some stuff is not easily encapsulated in Nix. Of course, you could always use virtual machines or Docker as an escape hatch. I’ve found this to be a fairly good solution in the somewhat rare event I need it.
It's true, escape hatches exist. But they are solutions to problems you are _creating by using nixos_, which did not occur on a normal FHS system, and require time and energy investments to solve them. And those problems are landmines lurking in every piece of software you will ever adopt in the future.
> At first, it seems useful for software development, but trust me, if you get deep enough in it is way more important for system management.
I don't doubt this is true. But there is a cost of time and energy to get deep enough in it, and I was unable to convince myself that it was worth it during my time using the OS. I really wish that weren't the case, I love the idea of NixOS, I just can't justify learning it for a singular personal system, because it forces you to have a deep understanding of the Linux-y systems you're encapsulating, and the Nix-y layer on top.
That is fair. And I’d say the last thing I’m trying to do is convince people to use NixOS, rather just explain why I can’t escape it. I definitely understand that it is imperfect and an enormous time investment.
> I just can’t go back to Debian or Arch after this, I’ve tried.
I tried to solve many of the same problems in Arch Linux with aconfmgr. It attempts to achieve reproducibility by using a model where the state of the entire system must be represented in the configuration file, and it helps transcribe any changes back to the configuration (unlike classic configuration managers, which only manage what is declared).
Maybe weird, but as NixOS user my dotfiles stay unmanaged. I VFS cache mount an S3 bucket using rclone(1) which gives the same home directory experience on all machines. Normally that would be something NFSv4 could provide, however the advantages of this setup are a) I can access HTTPs from most places without firewall issues b) takes just one binary.
I ultimately went with unmanaged dotfiles as well, it seemed like the most sane option. I host all mine on github so on NixOS machines I would just clone the repo and symlink to it as needed like I do on regular FHS systems.
I, like many other NixOS users, fully understand your sentiments. Let me explain why I stick with it and use it in all of my computers.
First off, I have a quite special environment for work. I like to customize many aspects of my desktop, and having my environments on other machines to work similarly is a tedious task, especially when having more than two computers you use daily. NixOS solves this issue very well.
What makes it hard is how docs are not that great for Nix or NixOS. What all of us have to do is to read other people's dotfiles and the nixpkgs monorepo to understand how things work and what can you do with it. It is extremely hard in the beginning, even for people like me with over 20 years of Linux experience. It took me about six months to finally being able to get it.
There are some new terms you hear when you first start using NixOS. One is flakes, that is very vague and academic at first, but when you understand what it does it is almost as hard to go back to Nix without them as it is for seasoned NixOS user to go back to using other operating systems. With flakes, you have two files:
- `flake.nix` lists inputs, such as git repositories, of nix build instructions for fetching packages and functions to your system.
- `flake.lock` is like your normal `Cargo.lock` that sets the exact commits of all inputs, freezing the versions of all software in your system.
This means I can mix things really nicely in my system. I can use the master branch of Sway, the pgtk version of Emacs with Wayland support from the emacs version control (not even master branch) and mix and match things from different NixOS versions. I can even fork the NixOS monorepo, do some changes and add them to all of my systems before my PR gets merged.
The `flake.lock`, which I commit to my repository, forces every single computer I have to use exactly these versions of the software with the configuration I give. It will always lead to the exact same result when I `nixos-rebuild switch`. When I want to update my packages, I go to the repo and say `nix flake update`, then switch to the new versions and only if everything worked with the new packages, I commit the `flake.lock` and it works everywhere else the same.
The other nice thing I learned, is while at first the nixpkgs feels like a crazy mess and hard to grasp, it is actually one of the best package repositories I've used. Being a package maintainer is easy and a PR that follows good coding standards gets merged to the main repository no matter how experienced Nix developer you are. See my first package I started to maintain:
These 23 lines of nix will fetch the package with the given tag from GitHub, check the file download SHA256 sum matches the given, check the vendored libraries SHA256 sum matches the given and then will just use the system `buildGoModule` function to compile the package and put it to your system. When their CI catches changes here, it will build a binary cache for the derivation, so most users won't even need to compile anything, but get a binary derivation with exactly the same result as compiling it by themselves.
And it's easy to see what gets added to your system. You can see the repo and read the code. You can use your editor, go on top of `buildGoModule` call and jump to definition, and you can read the definition what the function does. Now some users are running bots that just go through many packages in the nix repo, change the versions and SHA sums if they have updates and automatically generate pull requests, saving the maintainers the work to do it manually.
I understand this is not for everyone. But I hope I also could make you understand why there is no way of going back to systems like Arch Linux, Ubuntu, Windows or macOS after getting some proper taste how to do things with NixOS.
I run Debian's Chromium package on a 32bit NixOS machine, since cache.nixos.org stopped providing non-essential builds for 32bit a few years ago and I building Chromium from source myself was too slow.
My solution was to fetch a Debian filesystem, chroot into it (using proot) and run 'apt-get install chromium'. The result is an immutable Debian with Chromium installed. My chromium executable is then a script which chroots into that filesystem (again using proot) and runs chromium.
It's not reproducible, but it's simpler than maintaining a list of all the required .deb files and their SHA256.
You sort of have that with NixOS as well, with eg. steam-run that provides a debian-like chroot and can run most executables. (You can also modify it to include any dependency you like, that will get installed to standard locations)
There has been a lot of effort around building tiling compositors for wayland. With wlroots, it’s getting a lot easier. I believe waymonad is trying to bring xmonad to wayland but the project is going pretty slow last time I checked. But I share your sentiments. The last year has been awesome as a Linux user. Wayland, pipewire, proton are all so awesome, I really get excited thinking about what we’ll get in the future.
As a user of traditional KWin-style desktops, I think Wayland has a lot of tiling compositors (sway being mature-ish, though far more unstable for me than others in my testing months ago), but not enough KWin/Windows 7-style compositors with XFCE-level snappiness and performance (KWin is slow everywhere and buggy as hell on Nvidia), and Windows 7/KDE style Aero Snap. I'm rooting for Wayfire to work well (at which point I may write a set of window management plugins), but it doesn't work well on Nvidia (I'm waiting for them to support GBM).
waymonad has a somewhat more active fork here: https://github.com/L-as/waymonad, but it's still just a one-man show that got picked up at ZuriHac 2021 and then failed to gather sufficient momentum.
As a maintainer of xmonad upstream, I'm watching the waymonad project to see where it goes, but I have some concerns about its architecture which I'd love to see addressed before we'd officially endorse people to try switching. This is a copy of a message I sent to fellow xmonad developers a couple months ago:
> We should certainly take a look sooner or later. From a quick glance, I have some concerns about the general design of it:
> It's a compositor and window-manager in one. This is typical for Wayland, but there are lots of disadvantages:
> * Restarting the WM is just like restarting X: session over. Unacceptable for xmonad/waymonad, as we don't reload config, we recompile and restart. Someone is apparently working on making Wayland compositors restartable, in general: https://indico.freedesktop.org/event/1/contributions/20/, though.
> * Another consequence of the WM and compositor being one is that they share memory leaks and GC pauses and signal handlers and whatnot. As much as I love Haskell, I'd prefer frames from an FPS shooter to be presented on screen by something else. Oh and did I mention the compositor/WM also handles input, making any GC pauses doubly painful?
> * Aside from operational issues, this also means all of that needs to be implemented. There's https://github.com/swaywm/wlroots/ (used by waymonad), a library that supposedly lets individual Wayland compositors implement less code, but it doesn't seem to be nowhere near what X gives us: we take care of window management and all the input/output handling is taken care of by other tools with their own configuration and tools. It simply doesn't seem to work that way in the Wayland world. There are other options like implementing a shell plugin for Weston, or possibly other libraries, I don't really understand the landscape.
> I may be wrong on some of these, as I didn't actually try to compile and run the thing.
> Anyway, I am convinced it'd be best if the compositor and WM were separate processes, ideally maintained by separate teams. You know, that old “do one thing and do it well” philosophy. And I have no idea how difficult would it be to make things work this way. If someone were to work on this, discovering the answer to this question would be one the first things to do.
I should probably clarify the wlroots handling IO thing: what I meant is that with Xorg, there are command-line tools like setxkbmap, xinput, xset, xmodmap, xcape, xrandr, autorandr and possibly others that a user can use to interact with the X server and tweak stuff, and from what I understand these don't have equivalents in the Wayland world that would work across WMs/compositors. I could be wrong, though, perhaps wlroots does have a standard protocol for such things and such tools already exist?
I'm the (mostly negligent) original author of waymonad.
Minor GC stalls are not an issue for reasonable framerates right now.
Major stalls are in the order of a single frame. Which I considered acceptable, but YMMV.
I fully agree on the issue with restarting. I had some ideas about how to improve that, but never got around to doing any of that.
wlroots was my choice, because I like the guys and worked with them on the project. Other libraries (most relevant probably libweston) are a bit more "fully featured" but also slightly less flexible.
> I fully agree on the issue with restarting. I had some ideas about how to improve that
Can you perhaps share some of those ideas? Might be something I haven't thought about. :-)
> wlroots was my choice, because I like the guys and worked with them on the project. Other libraries (most relevant probably libweston) are a bit more "fully featured" but also slightly less flexible.
Is that still the case today? I mean, I haven't really spent any considerable time researching the Wayland landscape, but I was under the impression that wlroots gained considerable momentum in recent years while weston is still just the reference compositor, but not really used in any well-known Wayland compositor.
I've been out of the scene for a couple years now (essentially since I switched from student to full time), but it's mostly the goals.
wlroots is the de-facto standard library used by almost everything but the big 3 DEs. But it's still designed and intended to be mostlyl bare bones, and doesn't have a scenegraph or other nice things.
OTOH it got stuff like damage tracking and I think there were plans to add an optional library on top for some scenegraph stuff.
My main idea around persistance was a wrapper core code, that loads the higher level library. So we could switch out the library as object inside the main code.
At the same time, I'd have used this chance to experiment with hot-path loops that avoid the Haskell runtime, but run in native code. To avoid the previously mentioned GC stalls.
Though in practice, that gets closer to the X model, where we split the display server and window manager with a proper API.
We'd still have more control on what we want async and what we want sync. And it'd be up to experimenting how much of the display manager should be exposed as library functions or just driven from the outside.
Other ideas like serializing state and passing that in some way could work to some degree, but are probably not worth it. Maybe with some help from CRIU stuff, but I'm unsure about OS portability of that.
In general, the big learning I'd like people to take, which is mostly unrelated: don't try to do multi-seat. xmonad has a neat design, and the attempt to add multi-seat broke so much stuff. It's not worth it for a probably <.1% feature.
Out of those persistance ideas, I'm still very much in favor of simply separating the compositor/WM into separate unix processes. Feels like the right thing to do.
If I ever have to take a job that doesn't let me install Sway, I'm in trouble. Having windows haphazardly piled on top of each other makes me very anxious and stressed out. It did before I switched, and is why I switched, but now I've had a taste. I know how pleasant window management can be.
> Having windows haphazardly piled on top of each other makes me very anxious and stressed out.
I've found that overlapping windows makes sense for "gui" like applications: Half of the screen is too small for a web browser or a graphical email program or an IDE.
So these days I make do with a program that allows me to use keyboard shortcuts to move the current window to a specific position and size (different shortcuts for different positions and sizes). In this way, I spend very little time moving windows around, as I just need to hit the key for the position I want.
Also, I don't tend to move windows around, e.g. my terminal is always at the same spot, and my browser is also always at the same spot (different than the terminal). So I don't have to touch a window often.
Which program so you use? I felt that xmonad just broke too many flows and was too big an investment as a user, but I'd like to be able to control my windows without using my trackpad
Right now I use Hammerspoon for macOS. I used to use Phoenix. On Windows there was AutoHotkey. On X11 I think the twm family allows you to move Windows to specific positions and sizes. There was also sawfish. Maybe wmctrl is a relatively modern thing and works with Gnome and KDE and other environments. What to do on Wayland I don’t know.
Yabai, a tiling wm for MacOS, is very good. I too was forced to use a Mac for my job and Yabai met my tiling needs as well as anything could have. Try it out next time you have to use a Mac!
I have a sway/linux laptop from 2017 and a 2020 intel macbook pro. The hardware in the mac is nearly double the real world performance but the way the windows move with yabai feels incredibly slow and janky.
And the hotkeys are a pain in the arse compared to sway, I resorted to skhd and karabiner elements working cooperatively.
Notes:
yabai needs a scripting addition, and new versions of it seem to need you to manually reload it.
skhd and yabai both need "accessability" access in settings, new versions seem to need to be re-added (and the old entry that you approved before gets a "No icon" icon which makes it feel jank and confusing, like, you think you enabled accessibility but it complains)
yabai also needs you to disable system integrity protections.
And added to that: most macOS windows can't be resized, so they fall off the screen or leave half a screen empty.
Honestly it was not a pleasant experience and was one of the main reasons I went back to linux, despite the subpar software support of things like zoom (which doesn't allow screensharing on wayland)
To be honest, i really really get angry having to shuffle around window's having windows overlapping another etc, having to work more then one hour on a "non tilling desktop" starts the "what where they thinking!!"-though replay in my head.
> I wonder what will happen to XMonad as the Wayland future actually seems to be approaching. I suppose nothing yet.
Nothing, it isn't like Xorg will stop working and a lot of the infrastructure between current X11 and Wayland servers is shared anyway.
The standalone Xorg server may or may not get an official update from its original maintainers but there are enough users out there that if something breaks or doesn't work and someone implements it, it'll be picked up by others.
It isn't like X11 is tied to the current most popular X server, if enough people feel like it it will be forked - Xorg itself is a fork of a fork (XFree86) of a fork (X386) after all.
First, it's not that Wayland is bad, but it's simply not there yet. It still needs more time and effort. Nothing is wrong with this. What's wrong is trying to shove that thing into people's throat.
Second, NixOS is overrated for desktops. It's good for reproducing specific environment, but, unlike servers and dev envs, in desktop environments, changes are made from both software and user side frequently and sometime radically. ROI is significantly lower, and NixOS still can't save you from long-term breakage.
What I can say is that you're just riding on hypes, and never looked into the true abyss. If you're into rock solid systems, nothing can beat full-time suckless. Ditch those "modern" stuffs like systemd and smart DEs, and you get perfectly predictable system. Do that on Debian, an you have nothing to babysit at all.
Maybe it's just the current Pop_OS version messing up something, but I've got huge issues now on Wayland. Windows occasionally only get redrawn while I move the mouse, which is super annoying while typing some text. Browser windows I don't use for a minute regularly become just grey squares with tab bars.
I only use one screen, so I'm pretty sure I'll switch back to something Xorg-based sooner or later. It's not perfect but at least it always remembers to redraw windows.
Love to hear more about this, DPI is one of the big problems I continue having on xorg. 4k screen makes this hard. How is the story on backwards compatability with xorg? Do stuff like zoom screenshare work?
I am currently running NixOS on my desktop primarily, which is just off-the-shelf AMD CPU/GPU parts. X570, 5950X, RX590. I picked AMD (repeatedly) because it offers excellent performance grunt and good open source drivers.
I do have a laptop running NixOS, but it is just a Thinkpad T60p from a few years back. It works OK, but I can’t say I strongly recommend this. I was at least able to get Intel’s cool GPU virtualization technology working under NixOS, but the iGPU in that laptop makes me wonder why one would do that.
I can’t stand macOS no matter how much I try. It feels like that GIF of Sideshow Bob stepping on rakes but in UX form. I have genuinely tried, since Mac OS X 10.4 to be exact, every few years, and I do actually still use macOS, but it would be impossible to use it as my daily driver.
Anyways, you didn’t qualify “hours” as being relative to any other timeframe, so I’m not sure if you literally mean you’ve spent less than one hour configuring your machine and/or discussing its configuration. However, you seem to wear it as almost a badge of pride, and I even sense some condescension, and I find that pretty silly. That’s like being proud of not learning another language. If you wanted to argue my time investment was worthless, you would have to know it gained me nothing versus just using macOS. However, given that I decide what’s worth my time, this is honestly pointless. I actually enjoy trying to improve my setup, especially in ways that makes my life easier.
It’s easy to see a bunch of Linux nerds talking about text editors or WMs and conclude it’s a waste of time, but I disagree. It’s only a waste of time if you have no interest in exploring it. As for the tangible benefits, I may very well have more macOS experience than you do Linux experience, so from what standpoint are you qualified to even judge that, even that angle were truly relevant?
Even if I loved the macOS interface, I sure as shit don’t love Apple. How much would I have to pay to get performance equivalent to my 5950X on macOS? Is there even such a thing? I could use Linux/KVM to make an AMD Hackintosh setup, but I better be careful to spend under 60 minutes on configuring it lest I sacrifice my benefits.
Sometimes you read comments that feel like it's written by you. Hey there!
I'm almost the same, but 3950x instead of 5950x. I used Mac OS X between versions 10.0 and 10.4, and can never go back. It gives me anxiety, even now when I have a M1 machine in the cloud from work I mainly use through SSH, the system just feels like it fights hard preventing me of doing what I want.
I sure hope so open hardware continues being a thing, and we're not forced to some proprietary way of doing things. I still have fun with computers and operating systems. I love to experiment, and finding things out is the only reason I'm in the business of programming.
Not taking time to configure an environment I spend most of my day in is as unthinkable as not decorating my home. I've used OS X. It was my primary environment for a few years, and there's no way I'd be happy using it on a day to day basis without spending ages trying to replicate a setup similar to what I have on Linux.
OS X works fine if you're content with it's limitations. It becomes a straight-jacket if you're not.
I used to think like this and ran Linux on Macbooks.
I have to say that overall, nowadays, the environment doesn't affect me much, most of the time is spent inside a text editor and the rest is inside a browser.
The widespread use of docker removed the need for most package management (the worst thing about Windows and Mac).
I use nix-darwin to manage most dependencies on Mac which is okay, albeit not a great experience (nowhere close to nixos on Linux).
I'd rather use Linux + sway when given the choice but I can, stoically, make work with pretty much anything.
I don't see a reason to stoically put up with an alternative I consider inferior for my use.
Maybe for junior devs lacking the leverage to decide what they want to run, but thankfully I don't have to put up with that.
(It's of course fine to actually prefer OS X, but putting up with it if you don't is another matter)
Most of my time is also spent inside editors or browsers, but the window manager matters a lot - to the point the majority of config changes I've made on a stock Ubuntu install is my window manager config.
Of course it's decoration. The choice of style and materials used in furniture is a central part of interior decoration.
Even choosing furniture purely based on function is a stylistic statement.
In any case it's obtuse to focus on this as the point of my statement was clear: that customizing an environment you spend much of your day in matters - that applies whether you only care about function or care about appearance too.
Last time I installed MacOS, I couldn't even ls in a terminal without digging through settings and permissions (I accidentally hit cancel on the pop-up). It used to take me days to beat a new MacOS install into submission, let alone hours.
OS X was going great until an OS upgrade meant no more 32bit apps. Utterly unforgivable.
It’s the OS equivalent of making an unrepairable device. Linux and the piles of mutant userspace hanging off of it may well be pretty inconsistent and janky, but you can actually take a wrench to them — they are repairable.
(Solved my problem by running a win32 version of my app instead, in 32bit Wine on Debian.)
Some people are happy to lease a Hyundai for 3 years. I’m more into owning my own bikes, and doing all my own maintenance :)
First, I strongly recommend using a tiling window manager. There aren't many logistical things you can do to improve your programming output but this is one.
I used XMonad for many years and finally had to give up and switch to i3, so I would recommend using that
The first problem was that they broke my configuration file with every release. I'm not a Haskell expert so fixing it was very time consuming
The second is that their gnome integration is quite bad. Also it's different for every combination of XMonad version and Ubuntu version and eventually I hit a combination that I couldn't get to work
So it was great when it worked but it didn't always work, and I'm now a happy i3 user
I seem to post this in every tiling window manager story comment section but if you are on Ubuntu an extremely easy way to try out a tiling WM is to install Regolith and select it at login (you can always go back, but you won't want to):
From their homepage: "Regolith is a modern desktop environment designed to let you work faster by reducing unnecessary clutter and ceremony. Built on top of Ubuntu, GNOME, and i3, Regolith stands on a well-supported and consistent foundation."
I'm not affiliated with the project, just a happy user.
Just a little note that we (AwesomeWM team) have stable APIs since 4.0 and each releases no longer break the API. We also have reached 90% code/behavior coverage (from 0% in < 4.0 days).
From a maintainer PoV, this is often a pain since AwesomeWM exposes most of its internal guts, but with enough compatibility code and Android style API levels, we still manage compatibility pretty well.
I know this thread is almost 20h old. But, I started using awesomewm maybe 8 years ago, decided on a look and config and haven't changed it since, every computer i use have the same setup, it is indeed awesome! Thank you so much for your time and dedication, it's a pleasure to use
Yeah, if you started using `git-master` around ~7 years ago, it hasn't broken ever since. The last breaking release was v4.0 in 2016, but it was in development for years before that in the git-master branch. 3.5->4.0 was a pretty nasty upgrade process since we had to nuke a lot of the unsustainable things one last time (https://awesomewm.org/apidoc/documentation/17-porting-tips.m...).
I just use a one line config that selects the gnome integration. Always worked great for me on Ubuntu. I think there is little reason for most to do much configuration of XMonad.
I've used numerous X window managers, and XMonad is my favorite. (I've tried to switch to i3, by using it for a couple years at work, while still XMonad at home, but XMonad is still more productive for me.)
One thing that I set up in `xmonad.hs` is `additionalKeys` that switch to or launch particular programs. For example:
My layouts are standard, and I mostly work from the large window on the left, and then the windows on the right are only wide enough to fit 80 columns in terminal or Emacs.
myLayout = tiled ||| Mirror tiled ||| noBorders Full
where
tiled = Tall nmaster delta ratio
nmaster = 1
ratio = 1/2
delta = 3/100
Occasionally I switch a window to fullscreen or switch to the big window taking the full width. When work needs the full screen or multiple windows at once for long at all, I usually switch to desktops 2 and later, and keep 1 for comms like email and chat. When docking laptop, work ends up on the external monitor in front, and then comms/monitoring is on laptop to the side.
I used to have a status bar and system tray, but got rid of them. The only thing I miss is having a clock I can glance at, so I wrote a key sequence that runs a script that uses `osd_cat` to temporarily overly the current time and date, time in other zones I'm dealing with, and battery status.
One thing I find missing in xmonad vs dwm is the notion of tags. Being able to summon and banish groups of windows at a time was something I found pretty handy.
This is relatively new, but XMonad is currently running a crowdsourcing campaign to sustain its further development (and maintenance). I hopped in to sponsor recently, and would recommend to do so to all XMonad fans!
I've used XMonad for >10 years. I love it and hate it at the same time. I love XMonad layouts! I hate that I have to write Haskell to configure it. I no longer have the patience to relearn the minimal amount of Haskell necessary to make config changes, so I've frozen my config and not touched it for the last 4 years.
But its really hard to switch off it! I've tried i3 and really like that it has a network based API, but not having automatic layouts is really a deal breaker for me. It seems like you should be able to port the XMonad layouts to i3, but in reality their models are different enough that I doubt you could ever make the same layouts in i3 and have it work exactly as it does in XMonad.
> but not having automatic layouts is really a deal breaker for me
there is layout saving on i3 now and it works pretty well.
basically you build a layout on a workspace, dump it to a file, adjust window selectors so that they swallow the correct windows, and then you can apply it a piacere.
i3 has manual tiling by choice and it isn't necessary to port automatic tiling to i3 itself. You can make a service that utilizes i3's IPC that does that. And of course people have done so[1-3].
I'm aware of i3's IPC and those tools are not even close to getting back to a normal XMonad workflow. Again, I think the layout models are different enough between the two projects that it would not be possible to build XMonad's auto layouts in i3.
Since various people are asking about xmonad-like tiling in wayland:
I wrote Vivarium[0] specifically to be a wayland compositor that behaves exactly like my (fairly simple) xmonad config, but it's a relatively new/unstable compositor and nothing like xmonad internally.
River[1] has a fantastic tiling model via user-provided executables, which makes it very flexible and probably a good fit for many people wanting something xmonad-like.
Waymonad[2] exists as a direct xmonad-like compositor, but I think development has been basically stalled for a long time. Sometimes there's discussion about reviving it though (edit: see https://news.ycombinator.com/item?id=28796909 for more up to date detail).
Japokwm[3] is another compositor with xmonad user roots, but again its own tiling model.
I haven't used a tiling WM but I'm intrigued by the idea. I have reservations, specifically that I have really poor eyesight so I honestly don't know how many windows I could usefully put on a screen anyway. But still, piles of windows are a mess.
But here's where I always get stuck on such things with Linux in particular:
1. It's usually a whole new set of keybinds I have to learn. I feel the same way about tmux/screen, emacs and vim and the like. For the others I get that there is a point because you can use all of them in vt-environments (eg over ssh connections). Whatever the case, they all represent a cognitive load that I have difficulty motivating myself to summit. You just get a lot of behaviour for free with a traditional mouse UI;
2. An esoteric scripting/configuration language, in this case Haskell for XMonad (it seems?). Often the out-of-the-box defaults will be sparse and/or rough and you'll have a whole bunch of conflicting advice on how you should modify that.
This works for many people and I"m genuinely happy for you.
Are there any tiling WMs that are a little more... accessible?
> I have reservations, specifically that I have really poor eyesight so I honestly don't know how many windows I could usefully put on a screen anyway.
Although I have a very good eyesight, my eyes tire fast when I look at small things.
I browse HN with 240% Zoom on 23" 1920x1080; vscode: font "Iosevka SS16", font size 33px.
So because of that I use i3 WM (...I have never used other tiling WMs):
On every virtual desktop I press Win+w (or sometimes Win+e if the monitor is rotated) to enable "Tabbed container layout"
and then I can switch between windows immediately by Win+Left and Win+Right.
With Win+w all windows use 100% of the display width and 99-100% of the display height (I also set border width 0px and disabled taskbar/statusbar), i.e. they are maximized.
Windows have no their own title bar, but you can see the window titles on the very top of the screen.
Since a window can use more space, I can use bigger fonts without being shown almost nothing.
Well, KDE probably too has an option to launch windows maximized by default, but probably not the other features.
> 1. It's usually a whole new set of keybinds I have to learn.
I use the i3's defaults:
1) Win+1..9
2) Win(+Shift)+Up/Down/Left/Right
3) Win+D (similar to Gnome's ALT+F2)
4) rarely Win+Shift+Space (disables tiling for a window)
5) rarely Win+Space (enables tiling back for a window)
That's all (also Win+Shift+j to reload the i3 config but I didn't remember this hotkey for years).
But if I had a 46" 4K monitor, I would use i3 as most others do (i.e. multiple windows are shown at the same time).
One big advantage of most tiling WMs is being able to navigate without the mouse, so there's always going to be some keybindings to learn.
You might like Regolith, which is basically an opinionated i3 setup you can install on top of Ubuntu as a set of packages. It integrates with Gnome and is ready-to-go out of the box, compared to manually installing and configuring i3 and its accessories.
It's also available as a LiveUSB and complete install if you prefer that route.
The keybindings for XMonad are pretty similar to the keybindings for GNU screen - if you already spent time getting comfortable with screen, it won't take you too long to pick up.
dwm is a tiling window manager with very similar keybindings to XMonad, and it's written in C. I used it for a bit before I switched to XMonad... I mostly discovered that if you were fine with the default configuration, they were largely interchangeable, but XMonad had a more sizable community and much more options for configuration. The config is also not that bad to copy/paste and treat as just a bizarre config file syntax (of which I think we've all used many).
Personally I think a tiling window manager works at least as well with 1-2 windows on the screen as with tons. I actually don't use one now (I'm mostly on Windows for work) but I extensively used it on my netbook which didn't have the screen space to effectively use more than two windows.
I use stumpwm, but to be honest I think I barely added any config options. Sloppy mouse focus was one and another to take screenshots with flameshot. Sloppy mouse focus in particular is huge. Works well with a tiling wm imo. The cursor tells me where my focus should be much better than a thin little outline moving around the screen. I was intimidated by all the lispiness of wms until I realized that I'm pretty content with out-of-the-box functionality and google got me the rest of the way.
Similarly, I've memorized new window and new horizontal/vertical split for tmux and that's like...98% of my usage so I'm set.
vim definitely requires more effort, but the payoff for me was making it so that I'm always either in the terminal or in firefox. I still use the arrow keys to move around in documents and I've been using it as my daily driver for work for years.
As a result, I have two monitors, one dedicated to firefox and one to the terminal (includes vim + db clients + everything else). I don't split my terminal like crazy, almost very tmux window is fullsize. I split vim 3-4 times at most and make use of a buffer-switching list thing that's way more intuitive to me than remembering the vim commands to cycle through them.
Most of the reason I use a wm is because for two applications, I don't need window decorations and it just seemed like a waste in general.
For the amount of power-user tools I use I feel like a totel poser. But it works for me, and I think that's what matters.
> Are there any tiling WMs that are a little more... accessible?
Yes! Pop shell by system76. It's an extension to gnome and not its own window manager so you get stuff like volume keys, screen brightness indicators, status bars display settings, and so on for free instead of needing to piece together a separate solution for every tiny thing.
You can do everything with a mouse if you want. I've started with just using a mouse and every few weeks I try and learn a shortcut or two for what I do most frequently.
I used to use xmonad but now use pop-shell. Only because of the great gnome integration. It's not as advanced as xmonad but gets me 80% of the way there.
I used i3wm for many years. It's great. However, at some point I felt fatigued and decided that I didn't
need the additional complexity and manual labor. Sure, I may save a few seconds every day, but I also lose a bunch maintaining my config file and providing basic funcionality that is not out of the box. Nowadays all major desktop environments have great tiling features and extensive keyboard shortcuts -- especially KDE Plasma, which is what I use now.
I recommend a TWM if you have the time and the energy for that, if you want to tinker a lot your environment. It can be pretty cool, but also a drag. There's always some little thing to fix, and basic things are simply not part of the package. So be prepared to write scripts and use third party tools with varying degrees of documentation for many things you take for granted on a desktop environment.
Regarding your other concerns, you can literally change all keybindings on i3wm, so you can make them follow the logic you're already used to. And i3wm is great for working fullscreen as well.
There was a time when I knew a few screen/tmux bindings but I'm afraid that's been relegated to history. For years now I've used tmux in concern with iterm2 so everything I do is with a mouse/trackpad.
But flipping between full screen apps is probably where I need to be so I'll check it out. I appreciate the suggestion.
Maybe 12 yrs ago, I developed some scripting in FVWM to simulate tiling. My thinking was, why do I need background and overlapping windows? It worked kind of, then I came very quickly to xmonad, but abandoned it (I do not understand haskell; maybe I should) So then came i3 for some time, but I never became a big fan of the tree layout.
Eventually, I found my way with qtile [0], written and configured in python (which I do speak sort of). It is extensible, simple and just works. I use it daily for nearly a decade now. What I like, qtile has modules to manage the window layouts. My favorite is the xmonad-clone which mimcs basic features. But efficient enough for me
0: http://www.qtile.org/
Another tilingwm I like to mention is spectrwm [1] which I use as a backup. I cannot say that qtile never had issues. But it is also a long time ago I used my backup. qitle is now in my OS repo, so I don't need to build and install my self anymore.
1: https://github.com/conformal/spectrwm
That said, many thanks to xmonad for opening a path and inspiring other projects
Just 2 0 0 0 lines?!? That's really saying something. I wish it was available on macOS.
OT: I've falling back in love with Haskell after reading Ben Lynn's astonishing adventures (https://crypto.stanford.edu/~blynn/compiler/) and it's still super awesome for explorative programming.
I believe dwm[1] by suckless is around 2000 lines of C. That used to be my go-to for a WM until I got too used gnome. As much as I loved the simplicity of that style of window manager, I am far past the days where I'd delight in tweaking my Linux installation to my personal tastes. If I could have a git repo with a static config that just built my OS the way I like it with minimal messing around, I would love that. I've heard NixOS is meant to work like that but I haven't found the time to try it. Perhaps someone here can enlighten me?
That's exactly how I use Nix—I have a repo that can reproducibly build the same NixOS setup across my machines, and I can even share a large chunk of the config with my work Macbook.
Once I got over the hump with Nix, I found it easier to manage and improve my Linux configuration than on "traditional" distros I've tried (Fedora, Ubuntu... etc).
Unfortunately, the learning curve was pretty brutal, and I don't think I would have made it over without using Nix for development (without NixOS) first on both my projects and at work.
I found the Nixos learning curve easier when I started with nust nix-shell and then home manager on Debian and macOS. It let me focus on building up workflows in nix for particular tasks and I’ve slowly worked outwards towards overlays and full nixos deploys.
> I am far past the days where I'd delight in tweaking my Linux installation to my personal tastes. If I could have a git repo with a static config that just built my OS the way I like it with minimal messing around, I would love that. I've heard NixOS is meant to work like that but I haven't found the time to try it.
NixOS is neat.
And "OS setup from git repo" is something NixOS is excellent at.
However, the effort it would take for you to come up with your own NixOS configuration would be much greater than what it would take for you to just re-configure your system each time & keep notes (or write the commands down as scripts).
This was the realization I came to when I booted up a NixOS VM to start building my configuration. I recently borked my Arch install and had to start from scratch. It took me about 4 hours to get my system back where I left it — all I brought with me were my dotfiles.
I just cannot imagine I would spend less than 4 hours figuring out NixOS and its DSL. Even if I setup a fresh OS twice a year I just don’t see it being worth my effort — beyond learning a cool new OS.
Arch works well for me and I like the package ecosystem / rolling releases.
Nix’s payoff is moving to use it for dev projects as well as your base OS config. I’ve been using it instead of the standard mix of brew/bundler/nvm/etc. everyone uses to setup their development environment for React native or instead of pip/venv and couldn’t be happier: no globally installed tools with conflicting versions, just a .envrc and a shell.nix in each project. (No one else on the team uses nix this way, but, in a year or so, I’ve not run into any issues)
Checkout pop she by system76. They call it a tiling vm but it's just a gnome extension. It's got full mouse support so you can memorize the high-frequency shortcuts and use your mouse for the long tail.
And actually XMonad itself is less than that. Running `scc xmonad/src` shows 1800 lines of code (excludes blanks and comments). Including the Hashell binding to X11, developed by XMonad's team, that is ~760 lines of code, means the entire project is above 2000, which is still close. Indeed impressive.
XMonad is the one thing I miss dearly from Linux since I had to switch to a Mac. With some effort, yabai [1] on Mac can approximate XMonad well enough (mainly, multiple workspaces, automatic tiling, focus follows mouse, and a few other key bits).
My killer feature. It makes having multiple monitors so much more productive. I don't want one larger screen with a big dead spot in the middle. If I want a large/wide screen I will just go out and buy one. I want more places to put stuff.
Bspwm is great too if you're interested in trying a tiling window manager. Have been using it almost exclusively for the last 2 years without too many problems.
I've always found tiling WMs to be quite nice on small screens, but a chore on large screens. I use a 27 inch 4k screen currently and much prefer gnome or xfce. i3/dwm/xmonad was great on my x220 thinkpad.
I'm on a 32 and 27 in monitor and there is nothing better than having a tiling wm. The available space is so large I really don't want to touch the mouse to put something into the right position.
To add to the rest of the discussion. I've tried different tiling wms. Starting with qtile (written in python) to awesome, xmonad i3 and now I'm on sway. I think xmonad has the best way of dealing with multiple screens (tags are essentially independent of screen), which I missed originally when moving away from it. Fortunately there are some python scripts to emulate the same behavior on i3/sway.
Some tiling wms at least can handle floating windows just fine so you can pick and choose. My bspwm setup uses one floating workspace and the rest tiling, so I switch to the floating one for apps or tasks where it feels easier.
But I prefer tiling most of the time on a large screen too, mostly because makes manipulating windows with a keyboard faster to have a simple, predictable layout. In practice I usually end up with 2-4 windows per workspace, with a few with 1.
I've been using XMonad for over 10 years now. Originally I went with Awesome but then decided I liked still having a normal desktop environment and XMonad's integration with Gnome was really easy.
The way I've done this has changed a bit over the years, these days I drop a file in .config/autostart letting xmonad replace the normal window manager after Gnome gets itself sorted out.
I tried but couldn't get used to tiling window managers. Even learned a bit of Haskell to write XMonad config files once.
I like to be able to have one application on top of another and especially not using the WHOLE partition. Don't create artificial constrictions for yourself. Some applications are designed to work only with a specified width and height.
I guess it's fine if you use your computer just for the command line stuff.
I don't know about other wms, but in i3, floating a window is just a matter of pressing super+space. Moving it around and resizing is very ergonomic as well, it's just super+left click drag and right click drag respectively. The really nice thing about the resizing is that you don't have to hit a tiny window border target with your mouse, super+right click just snaps to the nearest border of the window you're in.
My guess is that most other tiling wms would have a straightforward way to float windows as well.
They all do. People who leave comments like this have never actually used a tiling WM. Or they claim to have “tried” but never bothered to find out how it works.
With XMonad it's also pretty straightforward. You can do it for specific applications by using the window class in your config's manageHook (like: className =? "KeePassXC" --> doFloat).
In my configuration, I also have it set up that if I hold the mod key and drag a window with the left mouse button, it becomes floating. Mod+drag with the right mouse button resizes it, pretty similar to the i3 setup you mention.
If Sway had the support it deserves and a larger developer base to actually work decently with Nvidia cards, there would be no competition really. Under Wayland, it’s definitely the best WM experience anyone can wish for.
I understand the whole issue with nvidia and their asinine drivers, so no need to come down on me. Hopefully things change in the future with Nvidia cards, I absolutely love the experience Sway provides on integrated intel gpus.
Yeah. I'm using Sway as a daily driver and it's pretty amazing. It's a shame that nvidia is what it is, though. Every ~month you'll get a crash which really shouldn't happen. Not really sure that nvidia will ever come around to working nicely on Linux, though. The best we seem to have from them on any open source front is nvidia-docker :/
RX 580 for Sway. A RX 6800 XT would be great, but they still cost a lot. The new ones work really well with linux, is what I hear. But you should follow the latest kernel versions, due to lots of bugs being fixed at the moment by AMD.
For passthrough, just have another graphics card and follow the Arch wiki for installation. It works quite well:
I have recently moved to Sway on Wayland from AwesomeWM. While I like most of it, I miss the level of customization though - is there some really advanced Sway config out there?
Does anybody have good suggestions for a good WM on Wayland? I know SwayWM is quite popular, but I was wondering if there are any other good ones out there.
dwl is a dwm port to Wayland. Haven't used it myself but I do use dwm and find it quite enjoyable, although with a bit of a learning curve if you want to get into configuring it or adding functionality yourself.
That's a very good question, since the page shows five screenshots and one photo of a multi monitor setup for me. In addition, there's a link to https://wiki.haskell.org/Xmonad/Screenshots
I think the screenshots disappear (instead of just going into a single column mode) on very small screens, so people looking at xmonad.org from a mobile phone may not see them. Hm, we might want to fix that, perhaps.
But, I was an i3wm user, and now it’s hard to imagine going back to X11. I run SwayWM on NixOS and using Linux any other way feels archaic now. Yes, I do genuinely understand how that seems absolutely ridiculous, but honestly, it does. Other than the occasional stability issue or bug, it really feels like the future is arriving: smooth rendering, predictable latency, hardly an imperfect frame, heterogeneous DPI with no effort, no need to string along GNOME or KDE services to configure input devices or manage displays, yet to experience any problems with sleep/resume, and with NixOS, a simple, centrally managed configuration for my whole OS (including Sway) and any patches, git-versioned. It isn’t perfect, but it is almost as good as promised. I just recently setup a new desktop by grabbing a recent NixOS USB stick, formatting the drives, git cloning my configs, and running the installer, and one reboot later I was in my environment with Sway, all of my applications, my configuration…
I’ve tried versioning my dotfiles before, but this seemed to both be more tedious and still not really accomplish what I wanted. My desktops and laptops are single user, so I can just use NixOS to manage system-wide configs instead and get 99% of what I actually wanted.
I’ve digressed a bit into stuff very unrelated to WMs, but the software around your WM is important when dealing with tiling WMs. Nobody wants a bespoke pile of complex configurations that could break on an upgrade without warning, and that has never been more important than with minimal WMs.