I was there, Gandalf. I was there 3000 years ago, when we edited ~~x11~~ xorg config files by hand. I will gladly pay any price in bloat to never have to touch that nonsense again.
And the perpetual underlying vague threat “if you get your modelines wrong you could destroy your monitor”. I suppose I started with XFree86 and switched to xorg whenever Gentoo did.
> Creating custom modelines is far from fun activity, bloat or no bloat.
Last time I did that was in the nineties, when I was doing stuff like running CRT monitors at weird resolutions, like 848x612 instead of 800x600 so I know more about modelines and modelines computation than most.
And yet I don't even remember last time I had to manually edit modelines: 38" monitor @ 3840x1600 pixels and 34" monitor @ 3440x1440 are all working with stock Xorg config.
Monitors have been detected fine at their native resolution since, what, two decades now!?
It's not just about resolutions, but about refresh rates more importantly.
For analog monitors it made sense that autodetection was bad. Digital ones should be reasonably well served by EDIDs that you'd never need to make your modelines, but there are edge cases like the one I described above. Bad EDIDs also happen.
The only HiDPI setting I toggle is Xft.dpi in ~/.Xresources
This scales fonts in gtk3, and is used for the scale factor in firefox and Qt apps, and is recognized by most apps using something custom.
> For lightweight WMs there are lightweigh compositors exists.
I think that if you're going to take a holier-than-thou, software purity and perfection stance. You probably should make sure to proofread.
If you're gonna be judgemental about other peoples stances and refuse to admit to the existence of such a thing as a "reasonable tradeoff". Talk down to your audience with section headers titled "Compositor (no, not that thing from Wayland)". Maybe make sure what you've written is actually correct.
cool if you want to stay with 30-year-old desktops like fluxbox, but I'm not about to give up my KDE when I have plenty of ram to spare - the plasmoids for system monitoring alone are simple to set up and useful. Yes, I know there are standalone alternatives. Some things (imo) aren't worth optimising.
But to each their own - I'm sure someone will be all into "debloating" like the author.
I do not give up on my openbox. I use it with LxQt. Now there is a Labwc, similar to openbox. It uses its XML spec for config and is similar. But I am still on X until all issues are resolved. Can I use openbox on KDE now? It used to be possible, I can choose WM in LxQt. Back then every WM had a --replace option.
Hrrm. That may still be the case, but on modern systems it doesn't really matter anymore.
By modern systems I mean anything since about 2010 with enough RAM. On such systems, even end-of-life/support Intel Kaby Lake Core-I5/7(t(35Watt)) with 4 or 8 cores, and 32GB RAM I couldn't care less about Plasma(KDE), even when they are downclocked to 800Mhz mostly.
On more modern systems even less so.
I'd like to see a demonstration of that fastness, which translates into tangible usability benefits. Not some synthetic microbenchmarking shit.
I tried it, because I still know FVWM2. Was refreshing for a while, felt good because I still could 'do it', but that's it.
The only things I can imagine profiting from it would be running stuff which is at the limit for your physical RAM, where every wasted Megabyte decides between swapping to death, or running through smoothly. But then there is IceWM, which is good enough for such cases. With the exception of FVWMs excellent handling of large virtual desktops.
Essentially, I do want to stay with PI-PIII-level hardware at most. Things were much simpler back then and the percepted lags were much lower. If I swap the HDD with an SSD in a typical PII desktop running NT4, everything happens just instantly. I'm not even talking about DOS and clean beautiful text mode/turbo vision interfaces. On my Threadripper I wait a couple of seconds for a text editor or a todo list to start.
My quality of life didn't improve much in the PIV+ era. I can play 4k videos now, but the software is much slower, UIs are ugly and, more importantly, inconvenient because there are no native toolkits anymore, just the browser and it dictates the idioms UI designers can use.
Also I want local-first software which does not pipe all my shite to some shady guys, not unreliable plaintext storages somewhere in over the continent.
I don't want to pay subscriptions for everything. I still can run what I purchased 15 years ago but I don't have the option to own anything in this modern world.
I was there, Gandalf. I was there 3000 years ago, when we edited ~~x11~~ xorg config files by hand. I will gladly pay any price in bloat to never have to touch that nonsense again.
And the perpetual underlying vague threat “if you get your modelines wrong you could destroy your monitor”. I suppose I started with XFree86 and switched to xorg whenever Gentoo did.
That was only for fixed frequency CRTs. They were rare even when CRT was pervasive. And, yes, you could (I did) break them feeding wrong frequencies.
Immediately did ctrl-f "modeline" and was pleasantly surprised
I remember having to write XF86Config by hand.
EDIT: of course there's an xkcd for that: https://xkcd.com/963
How much of this wonderful legacy configurability is supported by Wayback (https://www.phoronix.com/news/Wayback-0.1-Released), so that we can still do this stuff as Wayland replaces X11?
Creating custom modelines is far from fun activity, bloat or no bloat.
The last time I had to look into that was to work around amdgpu bug that affected screen blinking in KDE Wayland session.
> Creating custom modelines is far from fun activity, bloat or no bloat.
Last time I did that was in the nineties, when I was doing stuff like running CRT monitors at weird resolutions, like 848x612 instead of 800x600 so I know more about modelines and modelines computation than most.
And yet I don't even remember last time I had to manually edit modelines: 38" monitor @ 3840x1600 pixels and 34" monitor @ 3440x1440 are all working with stock Xorg config.
Monitors have been detected fine at their native resolution since, what, two decades now!?
It's not just about resolutions, but about refresh rates more importantly.
For analog monitors it made sense that autodetection was bad. Digital ones should be reasonably well served by EDIDs that you'd never need to make your modelines, but there are edge cases like the one I described above. Bad EDIDs also happen.
The only HiDPI setting I toggle is Xft.dpi in ~/.Xresources This scales fonts in gtk3, and is used for the scale factor in firefox and Qt apps, and is recognized by most apps using something custom.
"in a simple way" proceeds to write a 300 page epic
I would call a 300 page epic simple.
300 pages on explaining things X. I wouldn't say that's bad. Could always be longer.
At least I was able to keep it under 300 pages.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
Omg I literally stumbled upon the unix haters handbook off an old JWZ blog last night and was reading it till 2 in the morning. Thank you!
... somehow this is the first time I've realized that you contributed to the Unix Haters Handbook.
(And I've read it in its entirety at least twice!)
I also aspect a 1000 Word article and stopped reading after the TOC.
As Xorg is effectively abandoned, these days I run Xlibre[0].
0. https://x11libre.net/
> For lightweight WMs there are lightweigh compositors exists.
I think that if you're going to take a holier-than-thou, software purity and perfection stance. You probably should make sure to proofread.
If you're gonna be judgemental about other peoples stances and refuse to admit to the existence of such a thing as a "reasonable tradeoff". Talk down to your audience with section headers titled "Compositor (no, not that thing from Wayland)". Maybe make sure what you've written is actually correct.
Does FreeBSD even support Wayland? I heard that there is some work.
Yes, they have official docs on how to set it up and use it.
https://docs.freebsd.org/en/books/handbook/wayland/
Here's a 3 year old article going through their freebsd/wayland setup, so it seems like it's been supported for a while now.
https://forums.freebsd.org/threads/example-tutorial-pure-way...
cool if you want to stay with 30-year-old desktops like fluxbox, but I'm not about to give up my KDE when I have plenty of ram to spare - the plasmoids for system monitoring alone are simple to set up and useful. Yes, I know there are standalone alternatives. Some things (imo) aren't worth optimising.
But to each their own - I'm sure someone will be all into "debloating" like the author.
I do not give up on my openbox. I use it with LxQt. Now there is a Labwc, similar to openbox. It uses its XML spec for config and is similar. But I am still on X until all issues are resolved. Can I use openbox on KDE now? It used to be possible, I can choose WM in LxQt. Back then every WM had a --replace option.
IceWM got some nice updates in the last few years. I preferred it over Openbox and Fluxbox.
> cool if you want to stay with 30-year-old desktops like fluxbox, but I'm not about to give up my KDE when I have plenty of ram to spare
KDE is slow. Fvwm is much faster.
Hrrm. That may still be the case, but on modern systems it doesn't really matter anymore. By modern systems I mean anything since about 2010 with enough RAM. On such systems, even end-of-life/support Intel Kaby Lake Core-I5/7(t(35Watt)) with 4 or 8 cores, and 32GB RAM I couldn't care less about Plasma(KDE), even when they are downclocked to 800Mhz mostly.
On more modern systems even less so.
I'd like to see a demonstration of that fastness, which translates into tangible usability benefits. Not some synthetic microbenchmarking shit.
I tried it, because I still know FVWM2. Was refreshing for a while, felt good because I still could 'do it', but that's it.
The only things I can imagine profiting from it would be running stuff which is at the limit for your physical RAM, where every wasted Megabyte decides between swapping to death, or running through smoothly. But then there is IceWM, which is good enough for such cases. With the exception of FVWMs excellent handling of large virtual desktops.
What drug do you take ?
have you even tried it ? it can probably fit in the entire cpu-cache, and run circles around the likes of kde/gnome/…
Essentially, I do want to stay with PI-PIII-level hardware at most. Things were much simpler back then and the percepted lags were much lower. If I swap the HDD with an SSD in a typical PII desktop running NT4, everything happens just instantly. I'm not even talking about DOS and clean beautiful text mode/turbo vision interfaces. On my Threadripper I wait a couple of seconds for a text editor or a todo list to start.
My quality of life didn't improve much in the PIV+ era. I can play 4k videos now, but the software is much slower, UIs are ugly and, more importantly, inconvenient because there are no native toolkits anymore, just the browser and it dictates the idioms UI designers can use.
Also I want local-first software which does not pipe all my shite to some shady guys, not unreliable plaintext storages somewhere in over the continent.
I don't want to pay subscriptions for everything. I still can run what I purchased 15 years ago but I don't have the option to own anything in this modern world.