Thanks for the feedback, guys! I changed some parts of the article to address the issues pointed by you.
In the end, the overall conclusion remains: this whole dependency hell on Linux is just too messy and fragile, and we should think about a more reasonable solution, like what Android and iOS do.
I invite everyone to try this new Linux distro inspired by Slax and Porteus, with the main goal of being super fast, small, portable, modular and immutable (if the user wants so).
> Confusing the wider shadow radius on windows with the bounds of the screenshot utility
If you zoom in you'll see that the gap between the last shade of grey and the end of the screenshot is still big. Also, the inconsistency: depending on the window, the shadow/margin is different. Still, why the screenshot tool do not remove the shadows? It's useless for screenshots.
> Referring to Mobian as a for-profit company
My mistake. Thanks for pointing this out. It's fixed now.
> implying PINE64 is driving libadwaita
I didn't say that. I said these companies are pushing this PC/mobile coexistence crap, which is simply true.
> Suggesting a library written in cross-platform C "carries code for other platforms"
I'm not 'suggesting'. It's just a fact: GNOME has 'mobile ready' code all over the place, regardless if you compile it for PC or not.
> Claiming GNOME is replacing Terminal with Console, when it has been explicitly communicated that is not the case
I didn't say it replaced Terminal, but that it's the new recommended default and that Terminal misses important updates to be consistent with the rest of GNOME 42.
> Stating a feature has been removed from Tweaks, when it has actually been moved into GNOME Settings
You're right here. It's already fixed.
> It's difficult to find anything accurate in this article, other than the screenshots
Actually, I said A LOT and most of the things are very accurate and you decided to point out just a few (some right, some wrong ;), ignoring everything else that simply can't be refuted. This a classic falacy.
> But can I gently suggest separating the opinion out from the facts? As an exercise, you might try moving your opinion to a section at the end and limiting the rest of the article to neutrally reporting facts.
Thanks for your kind words. :) I see what you mean, but I don't think there's such a thing as an unbiased text. What we chose to talk and focus is already biased. And that's OK. What seems odd, in my opinion, is pretending we're impartial when in fact we simply can't -- the press, for instance. It doesn't imply, as you said, that by being biased we're adding false information.
> Yes, there are still some inconsistencies with GTK3 and GTK4+Libadwaita, but that is expected, if you update your toolkit from one major version to another.
My main point with this article is criticizing a final release with all these issues. Worse than that: pretending it's a good product when in fact it's worse than previous versions in many objective ways.
> Sure there are maybe some bugs and/or leftovers from the GTK3-GTK4 transition, but same as above, it will be fixed sometime.
It's not standard. It's just the most popular because people are lazy and keep imitating each other. Although it seems fine to have systemd as an option, it's ridiculous to have it as a hard dependency.
> Webkitgtk is installed on every GNOME-Desktop for other things
Apart from distros that ship Epiphany browser, what else do distros use WebKit2Gtk for?
> But calling it "dubious" is not that appropriate, as they always have a sense.
It's dubious because it's a huge library that takes 1 hour to build and all this just for one silly feature. And again: there's no official way to simply not have it.
> GDM isn't coupled to systemd AFAIK
Just take a look at GDM meson build script and you'll see:
systemd_dep = dependency('systemd')
libsystemd_dep = dependency('libsystemd')
The fact that you're running it on a non-systemd distro is probably due to an unofficial patch (just like the one I applied in Slackware/Porteus).
>Just take a look at GDM meson build script and you'll see: systemd_dep = dependency('systemd') libsystemd_dep = dependency('libsystemd')
This is only required to build it, not run it. It should work fine with elogind as a drop-in replacement, since elogind is API compatible.
>Although it seems fine to have systemd as an option, it's ridiculous to have it as a hard dependency.
No this is wrong, it depends on logind for a very real reason. Managing the seats isn't secure without logind or similar functionality. If they supported operating without that it would compromise security. And if you're on a single seat system and really don't care about security, you might as well disable logind and gdm altogether, and launch your user session straight from the VT.
> It's dubious because it's a huge library that takes 1 hour to build [...]
How often do you build GNOME-Control-Center with all of its dependencies? Sure, if you are using Gentoo/LFS, that is absolutely expected, but then you can afford to do one (maybe minor) patch to do it yourself.
> The fact that you accept that is exactly what I talked about in this other article
Yes, maybe one or two things like the increased memory usage are legit regressions, but GNOME is doing far less breakage/inconsistencies in a major version update than some multi-billion dollar company like Samsung or Microsoft.
> Better believe they do all this on purpose, trying to discourage anyone from changing their masterpiece. (In the article)
This is really the wrong conclusions, if extensions depend on some internals then you can expect them to break. That is like depending on some undocumented kernel feature of Windows 7 and then complaining that it is not there anymore.
> What exactly are they comparing GNOME to?
To everything else that is not GNOME. I gave many examples along the article.
It's not a matter of being 'frozen in time'. Changing just for the sake of change doesn't add much. As I said, new UI paradigm is welcome but it has to be at least more efficient, which is not the case.
> Name one complete desktop application platform from the last ten years that doesn't come with an equivalent to WebKitWebView.
This 'last ten years' may be misleading. GNOME was created more than 20 years ago. Does it count? If you mean, desktop environments that are still being developed, which includes GNOME, then I have some examples that don't depend on any browser engine: LXDE, LXQt and Xfce.
> you can always right click on a blank space, or click the current folder in the breadcrumbs bar, and choose "Open in Terminal".
It works, sure. But it is less efficient for no good reason, and that's my point.
> And I'm sure XFCE can be built in five minutes if you just grab a prebuilt libgtk, but you should probably be asking, where did that library come from?
GNOME also depends on GTK. Actually, it's worse than that: it depends on both GTK3 and GTK4. But anyway, GTK3 compiles in less than 15 minutes on my machine. :)
> You're welcome?
Thanks, but you didn't get my point.
> Anyway, choose a less inflammatory title next time.
I assume you didn't read whole the article. By the end it says the author (who happens to be me) is a Linux developer who work in Porteus distro. It doesn't matter anyway. What matters is that basically all desktop environments and also Windows, Android, MacOS and iOS have native support to desktop icons. And it's not a surprise that many major distros ship GNOME with desktop icons extension installed/enabled by default.
I tried to be clear about this 'paradigm' thing but it seems I failed. There's nothing wrong with changing the paradigm. The problem is that GNOME did that in a less efficient way, although claiming the contrary.
In the end, the overall conclusion remains: this whole dependency hell on Linux is just too messy and fragile, and we should think about a more reasonable solution, like what Android and iOS do.