> Sad to see these type quirks will go away when Linux moves completely to Wayland.
I started using Linux when I was 25 or so. I'm 51 now. I do believe there's a far from zero probability that X is going to outlast me... Even if I live until 80!
P.S: and the day X dies, in decades, I do also think it's possible that, at long last, Wayland shall be as customizable and allows to do all the amazing thing X allows to do.
The customizability is possible, but not the ease of it
Because with wayland you don't write "just" a window manager - you write also the gorilla and most of the jungle, because a "WM" also has to be full Window Server with handling of input, rendering, display configuration, possibly linking extra virtual displays (still haven't figured exactly what part of the protocol handles it, but apparently pipewire can create virtual display that can be used for example by OBS)
Unfortunately, I don't share your optimism. Judging by the fiasco that systemd is and how it managed to completely win over init scripts, even the opensource world is not immune to fashion / politics / ...
Even if you were building a system for which init stages would be immutable, forever sealed and unchanging, determining the correct ordering means understanding every daemon and all their associated quirks and their dependencies and the quirks associated with their dependencies and so on...
I will never get the hours spent being a human SAT solver trying to safely order hundreds of lexicographically ordered start and stop scripts that may or may not be present in an unbelievable number of permutations.
The reason sysvinit is extinct is neither fashion or politics, but evolution.
Given my experience writing systemd units and then trying to figure out why they don't behave as the documentation says that they should, this suggests that being miserable to work with must be an adaptively neutral trait in init systems, thus selected neither for nor against.
Where did I mention anything about servers? The scenario I was referring to involved maintaining a large set of packages for a distribution, each of which may or may not be installed.
except writing systemd unit file hacks are just as bad. but with the added offense that things don't work as promised.
eg. if your sshd is set after initRandom, but unit random is set after timesync, and timesync depends on network because ntp... if you only have lan and your ntp servers aren't reachable (or offline) you don't get any log out user visible hint at all of why start sshd just hangs there forever.
no matter how bad init hacks were, nothing was this shitty. zero logs. zero hints. just wait there forever.
if you like systemd, it just means you're sheltered and too green.
No, they are not just as bad. The scenario you describe is obviously broken, but the entire system can be inspected and easily debugged. With a flick of the wrist you can at your leisure summon a graph of the entire known universe. If you only have LAN then, typically, your host is physically accessible so this should be easy to debug.
Nothing about the scenario you describe is inherently worse because of systemd. The same scenario with sysvinit is literally a nightmare. This is literally and practically infinitely less of a head scratcher with systemd than anything else in existence.
I'm not sure how anyone can defend sysvinit -- you're certainly not even trying -- but shitting on systemd because you had a bad time is about the least productive way to participate here. It's no one's fault but your own if you don't understand your tools or the ramifications of letting yourself use them in ignorance.
Besides, at least at the time of this comment, your username is the one that is literally green.
Systemd has taken over most popular Linux distributions, but Linux isn't the whole of the opensource world.
I suspect X servers will die out at some point, but you could probably just run XWayland right? I've not messed with Wayland yet, because it doesn't address my use cases (mythtv frontends which is one X program with no window manager, and running programs on freebsd/linux for display on Windows).
On Windows, there is "Move" menu item in shift+right click context menu on taskbar icons. Selecting this item, then pressing left/right/up/down key brings window immediately into closer edge of valid desktop area, with mouse pointer sent to that window titlebar. This item existed since at least OS/2, and although it was not found in early version of Windows 11 new taskbar, it has since been re-implemented.
I know because I needed it while it had been missing :p
I believe that is only available for native Windows apps. Alt-Space was the keyboatd shortcut for it, very useful if the window had moved so far offscreen that you could not reach it with the mouse.
However, this doesn't seem to work with the newer Electron style apps, like Teams. They do not appear to follow the classic Windows patterns.
Yeah, there's some delineation in those apps. I notice the same behavior when I hover over the "maximize window" icon in Windows 11 and some apps show an outline of the options of I have but electron apps including chrome
At lease for the function that trigger by hoving maximun button. I believe windows do expose this api, firefox has this enabled for years even they draw the whole screen include icons using xul. And electron apps in native resize button mode also use actual windows resize button (Or fake one created by electron itself?) that has this function enabled. It's just some million-dollor company that are too dumb to support it properly (Or probably PM pushed it back because no user requires it?)
I did this to myself 15 or 20 years ago, and ever since have put a collection area for iconified windows on a panel.
In XFCE, it's easy to create a completely transparent panel running Window Buttons with "show minimized windows only" ticked, which emulates putting the icons on the desktop but corrals them to always show up in one location. Typically, if I have more than one minimized window, I've made a mistake -- but that's what the corral is for, saving me from mistakes.
I also used those windows managers around 1990, iconify to desktop and no task bar. I use a heavily customized GNOME 3 desktop now, with an autohiding task bar that appears when I move the pointer to the bottom edge. My desktop is an empty solid color image that sometimes appears between windows. I don't keep anything there, even when it was still possible by default. Too much clicking but I don't like that defaults get more and more opinionated. Let people do whatever they want.
Never understood the point of "a desktop" because of this. Why bother to have programs you only use on-demand just sitting there? The same thing, that I find more useful, can be achieved by actually running the programs you need (through a run menu) and just having them exist. Windows are my desktop icons, I don't need what I don't use.
That's a dedication ... eating glass for 35 years or so ... I'm not better though, over decades I've stuck with GNOME 2 (MATE desktop atm) ... This made me think right now, what exactly do I want from a desktop environment, and why am I satisfied with GNOME 2? I need to make a list of it and really think about it.
Sad to see these type quirks will go away when Linux moves completely to Wayland.