Part of the problem extended beyond software. Back when I got into recording, FireWire was necessary for the data bandwidth and it was standard on Macs. I had to install a card to work with my recording interface on Windows.
On a side note, been using Reaper for years and it has been great as a hobbyist option. I understand why any professional would use something like ProTools instead, though.
In what kind of world is a missing feature or a broken feautre due to incomplete migration to a new ecosystem, a reason to boycott that new ecosystem?? Those are simply not valid arguments to me.
They are obviously valid arguments to say, hey, this work is not completed, is not mature enough etc. So, therefore, you stay with previous ecosystem. But to boycott it because of that? That does not make sense to me at all.
Base os install ad a template in your hypervisor. Ansible playbook with a task to spin up the VM, another task to setup network and required packages. Then other playbooks for the software/services setup.
The main differences between distros boil down to:
init system
default configurations and applications
release cycle
package manager
Most end users don’t mess around too much with their init system and software configuration. With the rise of mainstream distros and application developers opting to ship desktop applications as snaps/flatpak/appimages, the last two points have less importance than ever.
IMHO, considering this, most of the discussions surrounding distros is relatively silly. After using Linux for almost 20 years at this point, I think I can safely say I could be productive on most popular distributions, with minor adjustments to my workflow.
For a new user? Just pick one of the main distros, that supports the software you need, and roll with it for a while. It won’t make much of a difference. Distro hopping doesn’t make one learn much outside using a different package manager.
People use computers to accplish tasks. That requires running software on an OS, but nobody runs software or an OS just to sit & watch it exist. They run it to accomplish tasks.
Different distros mostly vary in how easy it is to accomplish various tasks. No one distro is the easiest for everything, so people make different choices depending on their needs.
As someone who has written client code targetting X11, it’s indeed quite unfortunate that, to properly target Wayland, it’d need to all be replaced, but… good riddance. Working with X11 was fucking hell. X11 has so much broken/unreasonable garbage in, like, most places. Working with X11 has been, by far, my programming worst experience.
This is not to say that Wayland is automatically better at everything (I haven’t looked into it much, and the server-side decoration problem is indeed a problem) but it’d be damn hard to be worse than X11 or be anywhere close to it.
Yeah, I’ve seen libdecor as a solution, but it still feels quite off to have pretty much every wayland client have a whole dependency for such a trivial thing.
Yes, the client is supposed to manage the client content, but the obvious question then is whether the window decorations are part of its content. In some cases (stuff merged into the decorations) it can definitely be the case, but, for most things I’d say the decorations are as much a part of the client content as the apps entry in the taskbar (both contain the title of the app, potentially the icon, options to close/maximize/minimize). The only difference is that decorations always appear immediately above a window, but even that isn’t really a fundamental part.
I have noticed that one of the groups that does not seem to be complaining about Wayland are the toolkit folks. GTK added support back in GTK3. Qt added it. Enlightenment added it. They must have jumped on it for a reason.
When you look at the Wayland readiness docs for things like XFCE, it stands out that all the apps are already ready ( because they are GTK based in this case ).
Looked into some more things, and… base wayland does seem to continue the trend of “lol no not allowing you to do a basic thing, because surely noone has a good reason to” more - no custom positioning of windows (remembering custom window positions on reopen, window moving segments of Rhythm doctor), cursor wrapping (amazing to use in blender, wish more things did it, it feels so much better to use than the cursor being temporarily frozen in place or moving freely through everything).
At least there’s still the chance for extensions (wayland.app/…/pointer-constraints-unstable-v1 plus wayland.app/…/relative-pointer-unstable-v1 I think provide the ability to set the cursor position on wrapping and have that not interrupt the stream of relative position changes) but with things not being in base wayland it means that apps can’t just assume basic features on linux wayland which they can everywhere else (windows, mac, X11) unless they just choose to ignore hypothetical WMs which refuse to implement them.
I believe I also have a situation where ydotool wouldn’t be sufficient too - namely, having scrcpy open in the background and sending it keypresses to play/pause/change volume of the content on my phone from global keypresses (which trigger a shell script that chooses to either forward the presses to scrcpy, or if it’s not open, do some hacks to do what they would have done if not intercepted).
@theshatterstone54@buzz The rumors are real. I've tested Wayland on several distros on several machines and it has always been a disaster. On Debian Bookworm KDE on a FRESH install, the first thing I did was open the Discover app and it crashed. Every time I opened it the compositor took a dump.
Wayland is garbage and its apologists have an agenda. Their agenda does not include working software.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.