I think patches have 3 approaches. First is use none because they are all bloat. Second is use the least possible. Finally the approach like uses. Apply as many as possible without breaking anything.
@Donald Mickunas Bloat is unnecessary things. What you define as necessary is why there is confusion. I'd say that obviously, the core functionality of the program is necessary. Additional functions can be see as the core functionality of a program, so I'd say they are also necessary. However, core functionality can be implemented in many different ways, and this, imo, is the main source of bloat. Unbloated software, imo, is thus impossible to achieve, just as it is impossible for software to not have bugs. There are only less and more bloated software, just as there are only less and more buggy software. These things must be balanced with ease of use and speed of execution. So, we have bloat, bugs, ease of use, and speed of execution. A perfect balance between all of these will never be achieved, and some users prioritize some things over others.
it is less than 2000 LOC lmao and it was promised it will always be. it takes nothing to compile and you can read it all in an afternoon brilliant software
I remember times when Luke did not want to try out dwm. I mailed him about it but he did not respond. I asked him to try it out on livestream, he said no. Glad now he is using it
@BronzeKaiser have you seen his script directory? A while slew of things in there that are impossible to implement on Wayland by design. "samedir" for example.
I think this is more of an argument for Free Software rather than suckless per se. An individual sufficiently proficient in C could patch bspwm just as easily as they can dwm.
Sure, but as he said the .h file is meant to be read/modified as a config file, which is different and removes a need for parsing. The argument wasn't "you've got the code, do whatever you want"
@@douwehuysmans5959 Glad someone else thinks that. By the time you've read, re-read, digested and mused bspc and its million options, you could have dwm set up the way you want, probably ten times over.
dwm is definitely easier to patch than the alternatives. whether or not this is a point in dwm's favor largely depends on whether you prefer the idea of patching C code vs. modifying behavior through external scripts vs. just having a bunch of options in the config file.
@@user-lk2vo8fo2q "Suckless" software is a fallacy. The software does not "suck less" than something else purely because it is small and "unbloated". IMO, users should not have to modify the source code in order to change options in the software. This is a huge barrier to another thing that people like from their software, Ease of Use. IMO, the way this should be done is to have a simple config file to enable options, and all optional parts of code should be separated out into shared object files which can be dynamically loaded at runtime based on the config file. Thus, if you don't need or want an option, you just don't use it and don't put it on your machine. This leaves you with an unbloated software with all the ease of use of many of the "bloated" softwares. Btw, "suckless" requires you to have a C compiler installed as well, so add that to your bloat.
@@anonanon9634 but "time is money" doesn't forbid you from participating in leisure activities does it? I do agree with you but if you enjoy customising new and different things then why not. Just to be clear I am not saying you're wrong I'm just showing another point of view.
Luke is going from one extreme to the other. Suckless is neat as a mental exercise and it is good in reminding us that sometimes one can accomplish less with more (think dmenu or tabbed), but maintaining your own fork just for configuration is dumb. BSPWM (Unix way) and StumpWM (Lisp way) a proper hackable window managers. The big issue is not editing config.h, that's really no different from a regular config file, just more work for the user and less for the developer. The real problem is that when you want to add a feature you have to import a patch. Patches grow stale and can conflict with one another. Each patch you add makes it harder to keep up with upstream and weakens the source code integrity. The last thing you want is for your terminal to become a security risk because you wanted scrollback in it. Software written in C is simply not meant to be hackable. BSPWM is a hackable window manager in the Unix way. Your configuration file is an arbitrary executable, from within which you call the bspc program to set up the editor. It can be written in anything, but shell script is probably the most reasonable choice. You get all of the shell's scripting features like if-conditionals or loops. What's more, you can also call bspc at runtime to configure the window manager while it is running. OK, that's nice, but can we also add new features to BSPWM? Yes, we can: the bspc subscribe command prints events from the window manager to standard output, we can then pipe this output into another program which then calls bspc again to affect the window manager. We can use bspc query to get information about the current state of the window manager. Putting all these together, I added a new feature recently: when there is only one window on a desktop I find it distracting to have its border highlighted. So I took the output of bspc subscribe, piped it into an Awk script, within the script I use bspc query to find out the number of nodes when certain events happen, and then I use bspc config to change the active border colour. It's six lines of Awk, much simpler and safer than messing with the source code. StumpWM is written in Common Lisp, so you can alter its source code live as it is running, unlike C which is completely static. You can connect you REPL to a running instance, poke around and hook up to events provided by its API. If you want to use hackable software, use software written in a hackable language.
yeah idk how luke has been using dwm without running into patch conflicts. they're not a big deal if you know C, since suckless' source code is categorically well written and easy to understand, but it is something you have to deal with when every update might require you to modify a bunch of C code.
in that way, qtile is very hackable as well, but the python way. Good reasoning about code getting stale and merging upstream back, really puts words to my feelings
"Bspwm is pretty good" - And hangs on 2080Ti, on Threadrippers, on x399 platforms, on RAIDed NVMe, and basically on everything that is not i5 with spinning rust. Out of 3 PC and 1 laptop - only laptop worked. Regarding instability, it's second only to QubesOS as whole - that doesnt even recognize RAM correctly if is 64GB quad channel
@@jonathanhirschbaum6754 I am not quite sure that I have experienced the instabilities that you just mentioned with Bspwm. So far I have found it works flawlessly on 3/3 of the devices I have chosen to install it on (of varying hardware). No issues at all. Personally I have found it strikes the perfect balance for my needs. However, that being said, you use whatever works best for you. I love that there is a DE / WM out there for everyone. :)
Luke says: "There's certain point where you can not modify it anymore, you can't ummm... you know there are so many things there are in their config file" What are those things? I was expecting the examples. I have never reached a moment in where i3 didn't allow me to do what I wanted to do... maybe my imagination is too short. I handle the screen bright from the i3bar with my mouse wheel or a key shortcut, I manage the bluetooth with keystrokes, the system updates from my i3bar as well..... I need to know what is there that I can not do. Well, okay, I don't use gaps, I use regular i3. I don't need nor want gaps. Maybe that's the source of all problems, not having enough features for gaps? :P I don't know. I am totally not convinced, needed real good examples, got none.
gaps is a superset of i3 that adds some additional (unnecessary imo) features, so it's definitely not that. i think the main complaint people have with i3 vs. dwm is that how windows are displayed is pretty rigid. every window in i3 is tied to a particular position in a particular desktop. whereas with dwm windows are more abstract and you can do things like have the same window appear on multiple desktops or dynamically change the way the windows are tiled (without actually changing their place in the abstract window tree). i use i3 currently, but i'm thinking about switching to something else because i don't like having to manually choose where a new program window is going to appear. dwm is more like a stack where when you launch a new program it appears in the "main" window spot (what exactly that means depends on what layout rules you have active at the time) and then you control where the window is displayed by moving it up or down in the stack.
@@anonanon9634 yeah that's a very handy feature. i was talking about something different though. in dwm windows aren't tied to any particular desktop. they exist in an abstract tree and are displayed based on how they're tagged and which window display rules you have set, including the possibility of being displayed on multiple desktops at once.
I know you didn't axe me but, I thought I'd share my experience. The point at which you can't modify it any more is the point where patch conflicts become unresolvable. And that happens relatively quickly depending upon the patches you need and the order in which they are applied. In my case, I got center, fakefullscreen, noborder and then the conflicts began. Scratchpad, dwmc, pertag, xrdb, vanitygaps, swallow, dracula, restartsig all had to be massively reworked after applying the patch (in many case by hand because the diffs are garbage and not well maintained against the current master) to the origin/master and then merging into my own branch. You need to do it this way so you can keep orgin/master clean because any future changes in origin and you'll have to rebase (basically a patch of all your working patches). Its a pain in the peehole getting the workflow down but outside of having to apply crap patches (which should make the patcher ashamed) patching is easy upto the point where your knowledge of c limits your ability to resolve conflicts. And all this just you do a thing that other window managers ALREADY DO! And in most case better. Don't get me wrong, dwm is a fun little tinker toy for precocious newbs but you'd be better of at tty with screen than with dwm. But beyond just using dwm as a learning experience there is no case to be made for using it daily. It is just garbage. fvwm (lol) is better, 2bwm ratpoison all better
@@cstrovn Yes, but is better to compile first with "make" and then do "sudo make install". Compiling as root can lead to weird situations and is better avoided. For example, suckless programs will generate a config.h if is not present, that config.h will be owned by root and annoy you later on.
@@cstrovn in Lukes build yes, but if you grab dwm from github you will need to make your changes in config.def.h (for Luke uses config.h which is not ideal) or make changes to Make file so that make works properly. In my case I change make file so that "make clean" removes compiler leftovers and config.h. Do this because changes are made to config.def.h as to keep patching simple since most patche diffs are against config.def.h and not config.h. Makes no sense to nuke config.def.h and keep config.h....m,ust be bloat. LOL
When you apply patches that weren't necessarily designed to work together you will end up with badly designed software. There's no way around it. That is why people collaborate in open source projects. You may end up with a more or less bloated software but it will definitely be better designed.
@@AZEMBadlen I think karb94 point is that it is more than a flaw. This approach is fundamentally broken. It is great if you can make it work for you, but it will turn into a mess long term. There is a very good reason software development practices have tended towards separating configuration and code. Mixing the two is a seductive anti-pattern.
This. To get tabbed to work the way I wanted, I had to apply 3 or 4 patches, and manually resolve conflicts between them -- literally editing lines of C code, which is too autistic even by my standards. So now I have to keep the patched source code backed up somewhere so I don't have to go through the same process next time.
I guess, if you want this kind of config, then you really need to work with the devs to add the features you want. But, you can separate out those features into shared object files, and dynamically load that code (feature) by editing config files. I don't know why, but I feel like this could be "bloated" in some way too.
Nice! DWM sounds Awesome! I also think learning C can be really useful for performance enthusiast users. You can code at a lower level, modify Linux even more deeply, and have an easier time learning other languages since so many are "inspired" by C because of their similarities. There's also Game Dev libraries too! ❤️
bspwm > dwm dont @ me E: To clarify, dwm has an arbitrary LOC length (even though that's basically meaningless because I've seen 3k LOC run faster than 1k LOC) while also being a wm...and a taskbar...and a hotkey daemon.
I also use bspwm, mainly because dwm's gaps were uneven (even literally just copying Luke's build) and I don't really like the tree structure or w/e. bspwm runs a shell script at start and that's it. I'm cool with bspwm+sxhkd+an external status bar. Plus, hell dwm needs a dozen patches in order to get basic features. I don't hate dwm, but it's not for me.
@@bograham6221 gaps are kind of pointless IMO. I don't use gaps. I keep my build pretty vanilla tbh, besides a few extra tiling modes, my preferred keybinds, and mouse warping. It's pretty usable to me, I don't know what else you need. But that just probably goes to illustrate luke's point. Some people may prefer to make it look fancy or give it gaps, I just want something functional that lets me get my work done the way I want to. Also, you could easily remove dwm's status bar and keybinds and opt for sxhkd + an external status bar anyway. Also, the way that dwm manages tags and monitors is really unmatched IMO. You can select multiple tags, group a single window to multiple tags, or any combination thereof. Plus you get an extra set of tags with each monitor, and each monitor can also be in a different tiling mode.
Since your video on bspwm, I have been using it. And imo it's one of the few WMs that truly follow the Unix philosophy(ie do one thing and one thing only). The entire bspwm can be configured from terminal, it's also very minimal and works really well out of the box
Even for using hotkey you need an external program, plus writing scripts can be in any language, so If you like C use C, you like python use python, if you like bash(or Posix shell ) write in that. Ultimately following the Unix philosophy at its core. Brilliant
I would gladly use something like bspwm if it came with dwm-style tiling. Tiling based on splits like in i3 or bspwm just always felt extremely clunky to me. I'm sure with some scripting magic it could be emulated but that would just be too much of a hack imo.
I feel like this would have been a little more of an effective PSA if you made a follow up video addressing the patches you like to apply and comparing some of the "WAY BETTER FEATURES" instead of just showing the website. Just a thought.
Ah I see you're using DWM, I use KDE myself. I know these tiling window mangers are supposed to be better, but you know what they say. Old habits, they die hard.
oh wow I just 1) found out about Sway, and 2) found out how easy it is to manage 2 monitors: wiki.archlinux.org/index.php/Xrandr#Manage_2-monitors & github.com/Ventto/mons#examples thanks for the comment kind stranger^^
You gotta admit, A lot of patches you want get merge conflicts you might fail to resolve. St's ligatures patch is not compatible with scrollback and boxdraw, for instance.
I was doing too much things on my xfce4 and then I just started to use dwm and no complain about my wm anymore. Its beatiful, its good for work and pretty lightweight.
Tried dwm a bit it look good but the config file is a bit too hard to understand, I don't even know how to edit a keybinding. i3 is for WM what GNOME is for DE, you can't recommand dwm to everyone.
woot woot.. switched from i3 to dwm on my personal machine two days ago.. switched on my work machine today.. stoked.. many thanks to our intrepid unix explorer Luke.. Sincere thanks
First time seeing Luke's keyboard, though I haven't actively looked for it before. As somone who is really passionate about config management, I highly recommend checking out a 40% keyboard like a planck. There's a lot of efficiency to be gained by having all the keys within reach of your fingers, not moving from the home row position.
After i3 I tried dwm for a year, it was OK but organizing patches is a pain in the ass. Then there where the conflicting patches which sometimes where easy to solve, and sometimes not so easy (Some patches where not updated for the latest dwm etc). In the end I gave up on it when I wanted dwm to do something (can't remember what it was) but could not get it done without substantial changes to its source code which I could not be bothered with. Then I fell in love with bspwm. The fact that you customize it with shell scripting felt a lot more unixy to me. Also the fact that it does one thing and one thing well (no status-bar or keyboard inputs). bspwm is extremely configurable, and I can't think of anything that dwm can do that bspwm can't. And even if there was, just do what you do with dwm and edit the bspwm source code (I really doubt you'll ever need to). For once I think I'm ahead of the curve and bspwm will become the new cool.
About the first point: "source code is the config file" is definitely nice, but next level on that is the whole Lisp based Emacs paradigm, and WMs like Stumpwm. I mean they used the same idea for space missions to modify the running code for a satellite. Here's the story: "An impressive instance of remote debugging occurred on NASA’s 1998 Deep Space 1 mission. A half year after the space craft launched, a bit of Lisp code was going to control the spacecraft for two days while conducting a sequence of experiments. Unfortunately, a subtle race condition in the code had escaped detection during ground testing and was already in space. When the bug manifested in the wild-100 million miles away from Earth-the team was able to diagnose and fix the running code, allowing the experiments to complete." Same goes for your WM, or your Editor.
I would use dwm if it didn't have the bar at the top and if it was tree based instead of stacking. Sure, you can edit that in, but at this point you could write the window manager yourself, so I'm using bspwm.
i use awm. it's dwm with a bunch of lua scripts on top of it and i like it that way. maybe i'll plunge myself into the dwm meme one day, but i'm good for now
Luke, can you do a video on the vis text editor? What are your thoughts on it? Would you prefer it as a more minimalist alternative to vim given that it doesn't have a built in file manager?
> considers simple, portable config files "bloat" , muh minimalism > has to git clone, vim edit, make install for minuscule of changes for terminal, window manager, etc > meanwhile package manager has been eternally btfo cause of wandering binaries spitted out by random make installs > muh "spend time to make your setup efficient" (yet switches tools faster than the "brrrr machine") But I like your videos Luke, keep up the good work 😜. Please consider making a video on pdf annotation on linux (Zathura can't do it) and what do you use for managing research papers and ref. management? What do you think of Zotero?
"cause of wandering binaries spitted out by random make installs" You can change (or find out) the path in a Makefile, more often than not it'll be somewhere in /usr/local
I guess it would be pretty easy to hook a package build and install script into the general recompile workflow if you really want the package manager to be aware of suckless stuff.
> Editing source variables less bloated than parsing config files > You don't have to git clone every time wtf > Install directories located in make file > You dont have to do that/no one forced you to do that
What I am wondering, what happens with your highly configured source base, if there is an update/patch to dem? It would overwrite all customization wouldn't kt?
I doubt it would overwrite the config you would have to go and download the new version and try to patch it to be like your current config at least i would guess
What is your dual screen setup for dwm? I'm having trouble setting it up similar to my previous bspwm build where my laptop had all the desktops and main bar, and I used the second screen as a desktop that kept all the windows present as i switched desktops. On dwm, it's treating each tag as a full desktop with different size screens. It doesn't treat the external monitor as a separate desktop. I've tried several xrandr configurations but no luck any suggestion on mimicking the bspwm behavior on dwm? I believe you had a similar bspwm setup.
Is there a good dwm patch to turn it from a dynamic tiler into a manual tiler? Because otherwise, there's no use comparing i3 and dwm. I like the whole deal with window containers. I like being able to designate the left half of my display as a tabbed area and the right side as a tiled area (it's like suckless tabbed but actually sucks way less)
Plugin systems are usually designed to not conflict and break other plugins. I think the quality of the patches shows the group of people flocking to dwm are mostly concerned with looks and replicating what they already had in a Desktop Environment.
Good arguments. But what about updating? If a new version of the baseline or the patches comes along, how hard is it to update? I imagine it is not as convenient and transparent as pacman -Syu. Can anyone with experience please elaborate on that?
It's kinda funny that dwm has those kinds of limitations (like 2000 SLOC etc.) while being designed to work under X11 which is arguably one of the most bloated parts of Linux. Time to go Wayland.
You can patch all the WMs around for the features you need. I3-gaps is a fork of i3. DWM makes it easier to modularize the features you need, but it is like artisan work. May work for some who have the time and willingness to try. It is like scrapbooking for computer nerds.
I'm still not convinced, maybe you can help me understand. Our goal is to have our software do exactly what we want and do it well, in other words, involve the least amount of work to get our desired outcomes, that includes keystrokes, thoughts, crashes/bugs, manual fixes, config changes, execution time, etc. Changing behaviour the suckless way is done in two parts, modifying variables in the .h file and bringing in patches. The suckful way has a select group of patches pre-applied and the modification is abstracted away into a config file. We don't lose much by parsing the config at runtime vs. compile time with the suckless option so the argument comes down to being selective in what code is present, which brings us to your second point. Your argument is that the suckful option might not have the feature we want, so suckless is better because we can patch it. This is an argument for FOSS more than it is for suckless in my opinion and i3 fits that requirement. If some niche feature is missing, you can fork i3, create a patch, publish it on Github for collaboration, make an AUR package and have the patch applied when the package is compiled. This should apply to a minority of users, because if the majority want that feature it warrants being brought into the mainline project or creating a new project from a fork. It's more involved than just flinging your patch at the project maintainers to add to their repo, but honestly both are going to be relatively uncommon. On the other hand, if almost everyone brings in at least one patch with the suckless option you open up the possibility of having conflicting patches or introducing bugs that arise through an almost uncountable number of permutations of patches. I'm also assuming your package manager doesn't take care of all this for you which means extra work of fetching new source code, patching it and compiling it manually whenever you see fit or make configuration changes. This means you might miss out on improvements in the way of bug fixes or security fixes. The underlying reason we avoid bloat in practical terms is that it can increase our chances of encountering bugs or possibly increase execution time, which goes against the goal I mentioned above. The solution of removing everything down to the skeleton seems like overcompensation, since we need to invest time to make things work reasonably. The mindset here seems to be that we can't do something poorly if we simply do nothing at all. Sane default behaviour and easy configuration is the happy middle ground, it just happens that some projects are terrible at that - I don't think i3 is an example of one though. Maybe I'm missing something because I have never tried suckless software, maybeour goals are different and I just don't understand yours since I've only watched a few of your videos. Would love to be convinced suckless is better but I don't think this video did that for me.
The only thing keeping me from dwm is that in some games, cs:go being one them, I get 10% less FPS. I don't know why, the window manager should not matter, I am pretty sure it has to do with monocle, fakefullscreen, or maybe some other patch. I should try vanilla dwm. Bspwm has such sane default configs that it keeps me from customizing. Where as my dwm build was actually really nice, with a lot of work put into the look and feel.
The problem with patch is that if the version has changed between the time the patch was made and the time you want to install it, it may not patch at all, I lost A LOT of hours trying to fix that for sure and I have never succeeded...
I don't understand why XMonad isn't mentioned more often here. It's also configured by directly writing and compiling source code, but it is way more flexible and extendable that dwm. In the end, I find haskell much more hackable than C.
Because besides 3 schizophrenics who unlocked the forbidden knowledge of what monad is without getting memed to death with reddit copypastas, noone knows how to use Haskell.
I've been considering using awesome, since I'm a programmer and I can set it up completely to my liking while using a more powerful base than dwm... but it takes quite a while :) Currently using sway (the wayland clone of i3)
Hey just a note that basically everything you pitched as an advantage of DWM is also mostly true for AwesomeWM. Don't think it's fair to lump it with i3 in your description
I used to be dwm guy but now I've moved to i3 for sake of simplicity and it works out of the box for me. All I do is just tweak a little things here and there (usually keybindings). Guess it all comes down to that, mod-ability vs simplicity and I went with the latter.
Timely video, I've been tempted to go back to dwm which is one of my old favourites. The only thing i always struggled with was applying more than one patch, cos the lines of code being shifted around and hunks failing. I know you're supposed to just manually fix those but I always struggled with it for some reason.
Interesting that Luke doesn't "get" Emacs despite liking dwm because the config is just the source code. This is also the core philosophy of Emacs - the editor is infinitely extensible and customizable because any user configuration is simply more Emacs Lisp source code.
Emacs is a life commitment. Its like joining the Mafia, the only way out is death. Once you go Emacs.. its down the rabbit hole. You forget about mundane tiling window managers, you forget about ricing terminals, trying out Linux distro's. You wouldn't have time to make videos. Emacs becomes your life. You write your final will and testament in org-mode.
I start using linux for 1.5 years now and i use your i3 config for 1 year. If you do a video for changing the bind and explain it ( i read you man page ) i can try our dwm build buit for now it's a litle hard for a " novice user " to change a lot of code to match like my i3 config
Just try not to depend on config files and read a little bit and write your own . this way i was able to get to a fairly good level i mean i could survive and m using it just 4months now so you should do a better job it aint that hard
