161–170 of 518 posts
I can't say it any better than JWZ did over 15 years ago. This is the result of the Cascade of Attention-Deficit Teenagers model and is why Linux will not approach Windows or OSX in usability. Cannot link to his site: JWZ dot org /doc/cadt.html A complete teardown and rebuild of the whole ecosystem (because X succccckkks) is fun! Making something backwards-compatible, or standardized, or polished that "last 90%" so i…
Earlier quoted context omitted.
> sysvinit for example is only an alternative to systemd the same way a SUV is an alternative to F1 Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. And I would use the same car metaphor for comparisons with some of the other options, esp. runit, except with systemd in the SUV slot (e.g. my runit systems all behave themselves; my systemd…
> Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anythin…
I can't say it any better than JWZ did over 15 years ago. This is the result of the Cascade of Attention-Deficit Teenagers model and is why Linux will not approach Windows or OSX in usability. Cannot link to his site: JWZ dot org /doc/cadt.html A complete teardown and rebuild of the whole ecosystem (because X succccckkks) is fun! Making something backwards-compatible, or standardized, or polished that "last 90%" so i…
https://www.jwz.org/doc/cadt.html <- works for me
I can't say it any better than JWZ did over 15 years ago. This is the result of the Cascade of Attention-Deficit Teenagers model and is why Linux will not approach Windows or OSX in usability. Cannot link to his site: JWZ dot org /doc/cadt.html A complete teardown and rebuild of the whole ecosystem (because X succccckkks) is fun! Making something backwards-compatible, or standardized, or polished that "last 90%" so i…
https://www.jwz.org/doc/cadt.html <- works for me
Earlier quoted context omitted.
> Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anythin…
> Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else. I'm not that familiar with openRC or s6 (I've played with them, but don't use them on any 'real work' systems), though my…
Also, runit does i.e rely on logind, which everybody forgets systemd took upon themselves as consolekit was unmaintained. Why does runit rely on systemd's work here?
> runit shuts things down properly; with systemd I often have to literally 'yank the cord'
I've looked at how systemd handles shutting things down vs other inits and it's just a lot more paranoid, i.e. it waits for confirmation of every single service being shut down etc. In other init systems it tends to be a case of 'send shutdown signal, assume process shuts down'. You could fault systemd for this, but it's more of an application-level issue.
I can't say it any better than JWZ did over 15 years ago. This is the result of the Cascade of Attention-Deficit Teenagers model and is why Linux will not approach Windows or OSX in usability. Cannot link to his site: JWZ dot org /doc/cadt.html A complete teardown and rebuild of the whole ecosystem (because X succccckkks) is fun! Making something backwards-compatible, or standardized, or polished that "last 90%" so i…
His response was: "LOL! Yeah you can't even imagine how much worse it's gonna get. Pretty soon the Linux desktop will just be a little hammer that pops up and smashes your knuckles at random."
Earlier quoted context omitted.
Again -- XWayland is Xorg. The xorg-server codebase contains a number of components, one of which is a front end called DIX (Device Independent X) that handles protocol-level stuff, another of which are several backends collectively called DDX (Device Dependent X) that handle drawing to the actual video hardware or other graphics layer. One of these DDX backends is 'xwayland'. So the XWayland server incorporates the…
> So your best bet is to commit now to switching, entirely, to Wayland. The aim is to get everyone off of X altogether as quickly as possible, and then stop shipping X (including XWayland) altogether. Ah, it is the "32bit isn't needed anymore" all over again. Yeah, this will happen around the same time you wont need to ship 32bit support on Linux :-)
This is where we're at with Wayland and X.
I can't say it any better than JWZ did over 15 years ago. This is the result of the Cascade of Attention-Deficit Teenagers model and is why Linux will not approach Windows or OSX in usability. Cannot link to his site: JWZ dot org /doc/cadt.html A complete teardown and rebuild of the whole ecosystem (because X succccckkks) is fun! Making something backwards-compatible, or standardized, or polished that "last 90%" so i…
X11 has some fundamental problems. It's not fun using a modern desktop where it is impossible to sandbox individual applications. Firefox frequently processes untrusted data and is run with a dedicated uid, but it is also an interactive application and can suddenly listen in on all my passwords entered in other applications. Virtualized appliations are referred to using dumber protocols like VNC and SPICE which isn't always ideal.
Wayland has some interesting design issues on its own but that doesn't make the developers ignorant. XWayland will stick around for the foreseeable future.
Earlier quoted context omitted.
> Windows managers? Sway/wlroots. > Consistent window decorations? This is up to individual compositors and toolkits. > Thousands of applications Like what? Any that rely on X specific behaviour run via XWayland. > Consistent performance Wayland in theory should be faster than X, but again, this depends on compositor. > Redshift Gnome has night-light on Wayland already. KDE I think just added it. > Global keybindings…
I always wonder how people use their linux desktops when they claim that wayland works. Why aren't you using anything like wmctrl, xdotool, xprop, xbindkeys, xterm? Or non-Gnome DE? Don't you need custom keybindings for multiple keyboard layouts with caps/scroll led indication? Don't use wacom devices or anything like it? Wayland ecosystem is literally decades away from being usable and it's very unlikely to survive…
I have used Linux desktops for years and have quite literally never used any of those things (except for non-Gnome DE, which was slightly less "don't make me think" so I eventually went back to gnome). Yes, even xterm. Other tools might have been shelling out to those other utilities you mentioned for me, I guess?
Point is, there are at least some reasonable use cases that don't engage with that stuff. I truly don't know how much of the display stack of my current distro is X or Wayland-related code; I have never had reason to care. I don't have a dog in this particular fight, but there are lots of users who use Linux desktops not because they are customizable, modular, or whatever, but because a) it's a free OS, and b) it's similar to environments we target for development at our jobs. Despite the vocal-ness of customization advocates, I suspect that the vast majority of desktop Linux users are "dark matter" that fall into this category.