[vladev]

You'll be surprised, but it's RedHat that made most of that happen. A lot of the important Linux projects are developed mostly by them - Gnome, Wayland, NetworkManager, Pipewire, flatpak, etc.

Ubuntu, on the other hand, seem to like to do many things their way. Like aggressive patching. I recall fontconfig being heavily patched from upstream. Then we have Mir (now almost abandoned), Unity (abandoned), snap (flatpak, done differently, not yet abandoned :).

[eecc]

Well:

* NetworkManager is a dumpster fire.

* Wayland is 10 years in the making and it's still barely out of alpha and still missing crucial features such as fractional and consistent scaling.

* Pipewire is a welcome attempt to mitigate another source of grief, Pulse Audio.

* Gnome? Lets not get started...

Please. RedHat has been a boon to the Linux community but it's lack of - how can I put it tactfully - design taste? has stranded the platform into a decades-long quicksand of endless circular reinvention.

[in_mice]

You're not wrong on wayland. I remember hearing people talking about how great wayland was gonna be a decade ago.

Gnome and Network Manager are fine though. My XPS 15 wifi has been supported for the last three years without any issues.

[md8z]

Wayland is a lot better than X. The problem with any of these low level enhancements is that they take a long time to plumb through the entire system. I wish it wasn't so, but it is.

[md8z]

"still missing crucial features such as fractional and consistent scaling"

This has very little to do with Wayland and mostly has to do with the apps and the toolkits. I haven't really seen many Linux native apps that are able to function correctly at a non-integer scale. The rendering of these apps may have to be entirely changed and refactored to use floating point instead of integers. That a big thing to ask every app to do. The hard part is doing that, and then it's trivial to put a flag in Wayland (or XWayland) for an app to say that it supports it.

[nextaccountic]

Clipboard is consistently broken on Wayland. I don't use any XWayland application, it's all native Wayland. Sometimes when I copy things they don't paste, and I need to switch back to the original window for the copy to register. Or even copy again to be sure. This was never, ever a problem in more than 10 years using X11.

But, fractional scaling is working like a charm on Gnome + Wayland (after a gsettings command). Very crisp, despite people saying it doesn't work. On X11, even on KDE, I can't get fractional scaling this crisp. This is the only reason I'm using Wayland; all the rest sucks.

But, the problem is, GTK doesn't support fractional caling natively. Even GTK 4 supports only integer scaling. So for fractional scaling the compositor has to scale up, then down. This approach generally causes blurring (though I don't know why Gnome on Wayland here isn't blurred).

When I see screenshots of people with fractional scaling on Gnome, it appears very blurry. Comparing side by side, here it isn't. I don't know why and at this point I'm afraid of messing it with and ruining everything.

[md8z]

"Sometimes when I copy things they don't paste, and I need to switch back to the original window for the copy to register."

I have honestly never had that problem in years of using GNOME Wayland, but I experienced it many times with misbehaved X11 apps. Maybe you want to come up with a reproducible test case and then report it?

"Even GTK 4 supports only integer scaling. So for fractional scaling the compositor has to scale up, then down. This approach generally causes blurring (though I don't know why Gnome on Wayland here isn't blurred)."

That's what I mean, it has to be done in the toolkits first. The first step would be to add support for that to GTK which is unlikely to happen until at least GTK5. Then after the apps can start to support it, I think you're looking at at least a few years before there is a realistic chance of having that. Sorry to disappoint, it's just not an easy thing to have. And I don't think there is much incentive to support this from a hardware perspective either since most people that I see asking for this are using it as a workaround for oddly sized 4K monitors.

"This is the only reason I'm using Wayland; all the rest sucks."

I feel your frustration but I actually would not suggest using Xorg in 2021 unless you really know what you're doing. It's not secure unless you take great pains to make it so. GNOME's Wayland session is the most secure Linux desktop there is outside of security-focused distros.

[nextaccountic]

I think the main (or only? not sure) culprit is Firefox (running natively on Wayland) https://bugzilla.mozilla.org/show_bug.cgi?id=1726360 - it reports to be fixed in Firefox 93 but I'm on Firefox 92 still, I guess I should just update.

> And I don't think there is much incentive to support this from a hardware perspective either since most people that I see asking for this are using it as a workaround for oddly sized 4K monitors.

All 14" hidpi laptops (meaning, more than 1366x768) suffer from this problem. 1x is too small, 2x is too large.

[md8z]

Those laptops I think would fall in that same category of displays, where the PPI is around 120-180. It's not enough of an enhancement to make the text crisp and not pixelated, and it makes everything look bad unless the apps native to 96 PPI start to implement a certain type of floating point scaling. The higher end laptops of the same size just give you a the same screen but with a higher PPI. Scaling up then scaling down doesn't cause noticeable blurring once you get past 250 PPI, so it's only that class of low end displays/laptops that would benefit from this. I wonder if those displays will even still be around in a few years time, I certainly would like to get a cheaper laptop around that size but with a higher PPI.

[cycomanic]

> think the main (or only? not sure) culprit is Firefox (running natively on Wayland) https://bugzilla.mozilla.org/show_bug.cgi?id=1726360 - it reports to be fixed in Firefox 93 but I'm on Firefox 92 still, I guess I should just update.

I was just about to write the same, the only clipboard issues I've had in wayland were with firefox. I don't know what they do, but even in windows I get weird behavior at times (e.g. when copying out of Jupyter cells for example), much less than wayland though.

[Aa9C4xPz43Gg7k6]

Lack of functional fractional scaling is what makes me want to switch to Windows or Windows+VM or Windows + ssh to compile.

[eecc]

Ah sorry... so the major issue is not with Wayland itself, but with the major toolkits that in 10+ years haven´t bothered or figured out how to transition away from a rasterized buffer model.

Right. It doesn't matter if the fault is with GTK, Qt or the Wayland APIs not providing enough support for this to happen, sometime in the last 10 years. The problem is that it didn't.

In the meantime I've been using MacOS that has been doing vector graphics since what? 15 years?

SMH...

[md8z]

This isn't about vector graphics. There is always going to be a rasterized buffer, that's unavoidable. Even more so as apps are moving to newer rendering APIs like Vulkan and Metal. Apps doing custom rasterization is probably going to get even more common. The real issue there is what scale you do the rasterization at, because some things just cannot be expressed in terms of vectors. I believe Qt does support doing floating point scaling in some cases [1] but I've heard it's really broken because the apps still need to make changes to support it. You can't just take any old Qt app and recompile it with the moral equivalent of "#define int float".

This is also not a matter of "fault", by necessity the majority of the work that needs to be done here in the toolkits and apps. That's just the way it is. It's not that hard to implement this on the server side, you just don't scale that buffer when rendering. MacOS is an not a good example because that also uses an integer scale.

[1] https://doc.qt.io/qt-6/highdpi.html

[eecc]

Ok, let me rephrase. What I mean is - how I see it - that Apple just made the choice for every developer and gave them a conceptual model and tooling that does not depend on individual pixels or require them to make an extra effort in adoption (because you know how that goes.)

It baffles me that Linux is still stuck on this pixel grid that just hangs together at a specific density of 96dpi; something that harks back to the VGA days

https://docs.microsoft.com/en-gb/archive/blogs/fontblog/wher...

[kzrdude]

Well, Xorg is also missing fractional and consistent scaling - because there are many bugs with it

[benttoothpaste]

I use fractional scaling with Xorg so it is not missing. Not sure about consistency. It is acceptable for me though.

[nullspace]

I get annoyed when I see posts like this with revisionist history.

I can't comment on everything but:

> Unity (abandoned)

You probably don't recall how bad Gnome 3 was initially, and how much better Unity was over Gnome 2. Sure it also had its issues in the beginning, but it took a really long time for Gnome 3 to catch up.

> snap (flatpak, done differently, not yet abandoned :).

I am pretty sure flatpak didn't exist when snap was announced. Or it was around the same time.

Given the above two, I'd place very little credence on the rest of your points. I agree with the Mir situation to some extent, but look at how long wayland has taken to ship.

[mdp2021]

> You probably don't recall how bad Gnome 3 was initially

I do, and I have never seen its face again since then and the huge upsetting of ruining what worked well, and to create something perverse. And unless it was fixed very recently, it still is, because I just tried `gnome-font-viewer` and there are fades in the interface that cannot seem to be disabled. Unjustifiable. Not just the desktop manager: the paradigm. Dis-functional effects imposed to the user for no reason. And in a context which replaced functions with minimalism.

I am still wondering what caused that stroke of lunacy - at the time, I thought it must had been literally a stroke.

[speedybird]

> I am still wondering what caused that stroke of lunacy - at the time

Power users have privilege and need to be hobbled; their complaints ignored. The needs of users with the least privilege, the computer illiterate, should be prioritized.

Or something like that.

[md8z]

The general sentiment I see is that if a feature is only used effectively by a small handful of users then it's probably going to risk getting removed. That's just numbers, it doesn't make a difference whether it's "power users" or any other users. Either way maintainer time is limited and sometimes they have to make a decision to drop a feature that isn't pulling its weight.

But I've also never heard any description of the phrase "power user" that was clearly defined. Wikipedia says:

"A power user is a user of computers ... who uses advanced features"

"In enterprise software systems, 'Power User' may be a formal role given to an individual who is not a programmer, but who is a specialist in business software"

So which advanced features and which business software are we talking about here? That could be anything really.

[mdp2021]

> if a feature is only used effectively by a small handful of users

We do automated computing to have tools in general, as we may need them; and we use special features when we need them.

Figure imagemagick discriminating options or functions the same way ("Lanczos stays in, but we could ditch Hamming").

[md8z]

Those special features all have a maintenance cost, and if no one is around to pay it then their usefulness will diminish until they reach the threshold where it's not worth it anymore. Not sure why any filtering algorithm would be considered out of the ordinary. Do you know how many scientific and mathematics packages I've seen that are are really old, outdated, and suffering bitrot? Quite a few. In fact that seems to be a field where the old algorithms are discarded fairly regularly in favor of new ones. The older algorithms that remain popular do tend to stick around.

[dylan-m]

> there are fades in the interface that cannot seem to be disabled. Unjustifiable.

That's an accessibility option. GNOME Settings -> Accessibility -> Enable Animations; or `gsettings set org.gnome.desktop.interface enable-animations false`. Should apply everywhere.

[mdp2021]

> org.gnome.desktop.interface enable-animations

Yes, but it does not disable the fades, nor all the gratuitous animations I see in the GUI of gnome-font-viewer (one of the very few pieces I can try not having uninstalled it). Those animations must have been hardcoded in the software, it must probably be recompiled - and I do not take it for granted they can be disabled through a configuration flag.

[md8z]

I just tried it and it disabled the fades. Maybe you made a typo in the setting? Most GNOME apps are not going to have animations hardcoded, they typically use standard widgets like GtkStack or GtkRevealer that handle the animations automatically and respect the system setting. You can verify this by opening the GTK inspector in Font Viewer.

[mdp2021]

> Maybe you made a typo in the setting

Before posting I tried `gsettings get org.gnome.desktop.interface enable-animations` and it returns 'false', consistently (as it should) with `dconf-editor` used to see the options. And I verified (as I just re-did) the behaviour of `gnome-font-viewer`: changing the window content (switching the font) fades (messily) from former to latter, using the menu animates a "pull-down", activating the search slides down the interface...

I will try the GTK inspector today.

[michaelmrose]

You are absolutely correct that Gnome 3.0 was bad. Even more importantly there isn't anything whatsoever inherently with going your own way. Doing so is ultimately how we end up with a useful marketplace of tools to pick from.

If you stop worrying about the victimless crime of fragmentation neither gnome sucking or the specific sequence of development matters.

For what its worth I think they date from around the same time.

https://launchpad.net/snapcraft/+milestones September 2015

https://en.wikipedia.org/wiki/Flatpak September 2015

The larger issue would seem to be that canonical has a habit of betting on losers it ultimately abandons. Snap looks like the next roadkill to me. Far from being universal it will probably never see substantial use outside Ubuntu.

It suggests perhaps that they should exercise better judgement.

[rbanffy]

> It suggests perhaps that they should exercise better judgement.

I have a feeling many of these decisions are driven by internal politics than proper analysis. The first question when you decide to go your own way is whether others will find this more useful than the competition. Build better tools is not sufficient if you don’t invest in evangelising and great branding.

[xiaomai]

The fontconfig patches are a big reason I stay with Ubuntu. Fonts look _so_ much better on Ubuntu than Arch/etc.

[Shadonototra]

You can install their patched version of fontconfig on Arch

- https://aur.archlinux.org/packages/fontconfig-ubuntu/

Then you can use their font config confs

Here is the list they are using: https://hastebin.com/fukibunuji.conf

Copy paste what you have in your ubuntu install, then believe me, fonts will look similar!

Make sure to also install the ubuntu font familly

https://archlinux.org/packages/community/any/ttf-ubuntu-font...

And set your font hinting to: slight

Screenshots:

https://i.imgur.com/lKgvBeG.png

Looks good even on YouTube with Dark Theme:

https://i.imgur.com/dohPxoL.png

[flas9sd]

agreed, Redhat developers are behind many foundational packages (longterm thinking?), but I credit Ubuntu with bringing many users into Linux. They continue this with the WSL stuff.. while I see how distribution non-cooperation is difficult, at least the users of Redhat and Ubuntu-derived distributions have vastly more in common than what they differ by.