Not a success? It's now the default on most biggest Linux distros like Ubuntu and Fedora.
The tiling WM ecosystem in particular is thriving on Wayland with sway and hyprland, and I personally haven't had any issues with screen recording with OBS (I use hyprland).
Most of the stuff said in the list you linked is "said-X11-only software is not compatible with Wayland" but nothing is said about alternatives : for example instead of redshift I use gammastep.
As "just a user" in terms of using Linux as a DE, I personally had no gains, just losses.
For example, I wanted to create a tool to use my old smartphone as a trackpad. After a short time I realized my approach won't work on wayland. I started delving in the available options, /dev/uinput, libevdev etc., and realized it will be to much pain. No (generic) accessibility¹ support means no generic way to do that, and just for my setup it is too much work.
So I dropped that. Then I have a set of tools I use for quite some time, amongst which are AnyDesk, TeamViewer, Blue Recorder, Steam. These either don't work, work only with wlroots, or work via the X11 shim.
¹ for me just a nuisance, for all the people who really need accessibility support, well ...
Screen tearing gets worse at higher refresh rates and resolutions under Xorg.
Additionally fractional scaling and mixed DPI's are something Xorg was having great difficulty supporting.
It also gets quite slow (high CPU and especially memory transfers) at high refresh rates and resolutions; I mean, you benefit from this without noticing.
You'll notice a loss in functionality (like screen recording) much more than you'll see a benefit like "this will actually work at 8k 120Hz"; but it's not true that there's no gains.
Wayland is fine, it fixes a lot of legacy that holds the ecosystem back, people don't like it overwhelmingly because changing esoteric and hacky software that is core to basically everything will be difficult and take time.
It might shock you to know though that GNOME and Fedora users are already using Wayland on the popular distros, the transition was completely seamless for those users.
You're right and I don't debate any of your points. And no it doesn't shock me that big distros use Wayland already.
On the other hand, my points still stand I think. And regarding esoteric and hacky software: I don't think accessibility as a base functionality should require hacky and esoteric stuff, it should be a first class citizen in a 2023 window manager (?).
And I also want to remind how Linux (and, ironically, Microsoft) grew so strong: they are really, really careful with deprecating old stuff. As hacky that stuff may be. Up for debate if this is net good, sure.
> it should be a first class citizen in a 2023 window manager
It should be, but linux is built by hobbyists in their free time — it is hard enough to get to a working state, let alone adding accessibility, even if it is the first on the list.
> Screen tearing gets worse at higher refresh rates and resolutions under Xorg.
No, it gets better, the same as aliasing does with higher resolution. That, and VRR hardware in the monitor, are the correct way to fix tearing in this day and age. V-sync is kludgey false dharma.
> It might shock you to know though that GNOME and Fedora users are already using Wayland on the popular distros, the transition was completely seamless for those users.
Sure, but it might shock you how much smoother your desktop can be if you disable compositing (on X, anyway). Many never have, and you can't in GNOME (of course). ;D I'm not sure if Wayland supports that in itself, however.
Just as difficult? AMD GPUs are plug-and-play on linux (if you have latest gen you should run a recent enough kernel but that's basically it), whereas Nvidia GPUs need their proprietary drivers which adds much more complexity for beginner users.
It's just impossible to have the same level of configuration with your own custom script, NixOS goes way beyond: its configuration capabilities goes from your bootloader to user-level Firefox add-ons, and you have niceties like reproductability and rollbacks.
what? none of that is impossible for me to configure with a shell script? i install my userChrome.css to firefox with it, and i havent tried the addons aspect because my firefox account syncs them for me. since i run zfs i should get rollbacks too without learning a new language and packaging theory for guix
It’s possible as in you have a Turing-complete set of tools. You would basically have to recreate something like Nix for it to properly work, and would only end up with a much worse version of it, without the huge amount of work that goes into it (both the core, but especially the “wide ranging software support” part).
a set of tools that wont fade away, its much harder to believe that
about nixlang than its for bash/dash/sh
i dont have to recreate nix to get easy customized installs, my
installer script doesnt need to know or do anything about derivations,
monads, flakes, etc. it just uses packages from my distro and pulls in
my .config directory. what else does nix do that my script should do?
the software my script installs is probably more supported than it
would be on nix because its on ubuntu, one of the more commonly
supported distros.
How do you install the userChrome.CSS automatically? As far as I know it needs to be placed in a folder containing a hash that's only generated at firefox first launch.
At some point if you want to configure everything with your own shell script it will be a nightmare to maintain, NixOS is easy to learn in comparison.
i just glob over *.default and *.default-release `mkdir -p chrome` and
move it there then check if my user.js has the setting that enables
legacy userchrome (via grep, (useless) cat, and pipe), and if not add
it. wouldnt guix do something similar if it managed my userChrome.css?
i am not sold on the maintainability delta between my script and a
guix one, but i only use a text editor, a terminal emulator and two
web browsers for 90% of my use, so maybe im just too small scale to
run into the maintainability issue it's trying to solve. the main
struggle i have is in making the config files, and guix would only add
another layer to that.
easy to learn might be a valid consideration for me if i didn't
already feel comfortable with scripts of the normal non guix variety,
but the devil i know does fine.
NixOS is overriding the profile name by using your username so the name is not auto-generated anymore (NixOS hates that) so it knows the user profile will always be at ~/.mozilla/firefox/USERNAME. It automatically creates a ~ /.mozilla/firefox/profiles.ini with a custom profile.
That's a nice small benefit that seems dwarfed by the increase of complexity, but maybe I am blind to my death of a million paper cuts that I've grown used to.
Maybe I'll update my script to use named instead of randomly generated profiles, though.
You can specify as many profiles as you want, you have a property called firefox.profiles that can be an array and you would declare as many settings you would want in it. They still need to be names though (either through a variable like an username or a name you would set yourself).
It’s increasine in complexity when you are writing shell scripts, it is not when you have a proper system in place that provides a sane abstraction/interface for defining such configurations.
You can generate the metadata in ~/.mozilla/firefox (installs.ini, profiles.ini) to have whatever profile dirs you want. Only if you let FF generate them itself will they have the unknown random names.
It is weird how little information there is about the acquisition. An HN comment from a month ago has links to evidence the acquisition took place: https://news.ycombinator.com/item?id=36015157. The title of the official LinkedIn page (https://archive.is/uqBnf) says "Gfycat (acquired by Snap Inc)". It looks like it really happened, just quietly.
There is something funny about Snap buying a company and then setting a timer to delete all the videos. Shame about the data loss.
I disagree. Gyfcats don't really contain anything of value in my opinion. It's much different compared to other image hosts which can contain the only copy of something. Most gyfcats are illegal reproductions of other material.
You're wrong. There's wealths of information on gfycat. Maybe just not for things you know about.
For instance, smash melee used gfycat heavily. There is in depth analysis of the game using gfycat as visuals. There will be knowledge loss in that community in Sept 1.
Some of the most skilled tech people I know have had some of the most low-tech tech solutions in their non-professional lives (and sometimes similar on the professional side too), imo because they had the experience to spot ideas that were perfect for a simple use case despite seeming like a silly idea.
If gfycat provided them with an ideal - for what they and their users wanted - and free (I assume) way to host their clips that the community liked then apart from the eggs in one basket issue can you really say they made a bad decision? If (and sure it's a big 'if') they made sure everything was backed up and ready to easily move should something like this happen, then it could well have been an idea decision that worked well for years?
Those .gif animations were built by hacking a Gamecube emulator to display the hitboxes and hurtboxes of animations. Then playing those animations in the hacked emulator with the circles (red for hitbox, blue for hurtbox) overlaid with the characters and their animations.
At a minimum, the smash community members who built that data have an expert-level understanding of Gamecube graphics programming, Gamecube assembly language, and Super Smash Bros's internal scripting language to create those posts.
---------
Yes. This is a very technically adept community. I'm not very much a part of them, but I can see the expert-level reverse engineering work needed to get this working.
And the knowledge won't be forever lost if it is lost. The importance of hitbox / hurtbox reverse-engineering is common in all fighting games (Blazblue, Guilty Gear, Street Fighter, Marvel vs Capcom, Super Smash Bros). The various communities always work on reverse-engineering all the frame-data and hitbox/hurtbox information ASAP whenever new fighting games come out, so that expert-level fighting game players know what their training routines should be.
> At a minimum, the smash community members who built that data have an expert-level understanding of Gamecube graphics programming, Gamecube assembly language, and Super Smash Bros's internal scripting language to create those posts.
Actually this was possible before Dolphin existed. They did it on raw hardware. The devs left an extensive debug mode in with various displays like hitboxes. So a little Action Replay cheat was enough.
A lot of this niche stuff isn't hosted anywhere else. Smashboards doesn't have extensive content hosting and has always relied on other services. No way it's all archived by this deletion deadline.
The community relied on part on gfycat to host content about the game. There's a wealth of knowledge about the game outside of the game. As is standard for any competitive video game.
The dismissal of Internet culture as frivolous and of no value is both disturbing and just factually wrong, especially when internet culture is increasingly just all culture. If somebody decided to just abruptly obliterate a large chunk of all the books and music and television produced from 2010 onwards I assume you wouldn’t be so dismissive of it, and I think the fact that you apply different standards to the Internet is indicative of a mindset that may have been valid in the 90s and early 2000s, but does not represent how the world works today.
>to just abruptly obliterate a large chunk of all the books and music and television produced from 2010 onwards I assume you wouldn’t be so dismissive of it
If only a single copy was obliterated I would be just as dismissive because any of the destroyed material can still be accessed and archived by using another copy.
Okay, but I don't see it as bad as the source material being lost. You can always remake those clips. The reverse can't be done to go from clips to the original.
And the people that put significant effort into their work will reupload it to other services, if they haven't already. Similarly, exceptional work is probably saved by random folks elsewhere.
> The reverse can't be done to go from clips to the original.
EverythingGPT, generate a 140-minute movie containing this clip, Oscar for best supporting actor, clever twist in the end, stilted dialogue in parts, 4k.
"It removes fragmentation, could be deadly for the ecosystem"
> wayland
"It adds fragmentation, could be deadly for the ecosystem"
Both are now the standard on the most of the biggest linux distributions, so maybe it's not that big of a deal?