I may be remembering wrong but I am sure I got CD images off FTP for earlier versions as well.
I have been downloading Linux since grabbing floppy images of SLS, used Red Hat for years, and do not remember having more than one version on actual CD that I did not burn myself ( for sure never DVD ).
I do worry about it. It is not just disk space but RAM as well to have these duplicated libraries. Often that is at a premium for me.
It is also a security problem.
It is also a pain to update. Most of my systems update with a single command.
Anyway, use Flatpaks if you like. If I used a distro with a limited package library or out of date apps, I would use it too.
In Wayland, the compositor is the window server ( the equivalent of Xserver ). What you are looking for has to be a feature of the compositor and it is.
As others have said below, wlroots based compositors offer wlr-randr. There is also gnome-randr. For KDE, there is Kscreen-doctor. For X ( the window server being used by SDDM here ), there is xramdr.
Now, some people may see it as a problem that we have multiple Wayland implementations. I am mostly not fighting that battle. I will say that I hope these are not the same people that winge about systemd though and push for alternate init systems. I hope nobody that thinks MUSL is cool Is clinging to X11.
I would prefer that there was a common configuration standard for this stuff on Wayland. It will probably come eventually. Maybe as part of the freedesktop.org stuff.
Generally, I believe the Linux ecosystem has been stronger in areas where there has been competition between implementations ( even compilers ). I hope that Wayland will be one of those areas. As the core problems get fixed, the pace of innovation will increase. I believe we are already seeing that. There are more examples every day of things Wayland can do that X11 cannot. Let’s hope for more of that.
To answer the question of “why not” we only have to ask “what problem are Flatpaks meant to solve”:
The way that Flatpaks achieve these goals is precisely by mandating the environment that the application will execute within.
Allowing the application to run in different environments goes directly against two core value propositions of the project.
Being resource efficient is not one of the primary goals of Flatpak. Providing a consistent and deterministic execution context is.
There is your answer.
I am sympathetic to the question and the desire though. This is one of the reasons I do not like Flatpaks. Dragging in these big environments, and the duplication of resources, feels very wasteful to me. I would like them even less though if they did not even deliver on their core promises.
Personally, I prefer Distrobox to Flatpak. At least I have more control. Arch / AUR in a distrobox will let you install pretty much any app on any distro. If the app you need only runs in one distro ( like Ubuntu ), you can create a Distrobox of that too.
Say you have 8 apps that require 45 and you download one that requires 46. Now you have two environments. If the new one worked on 45, you could continue with one.
I am not advocating their position but that is what they are asking for.
It could be interesting if it stuck with the most recent that all apps support. So, if all the apps supported 45 or 46 then the system would use 46 but if one of the apps only supported 45 then it would hold the rest back to 45.
The idea with Flatpaks though is that they behave the same on all distros. So think it is better to force the right environment. It does make Flatpaks wasteful though which is one of the reasons I try to avoid them personally.
I use a distribution with lots of packages that are generally up-to-date so Flatpaks are not solving a problem for me. For most other distributions, they fill a real need. There are downsides though and this duplicated environments issue is one of them.
Here we have a straight-shooter with upper management written all over him
Congratulations on 2.0! It is looking really good.
What do you mean 6.2 was the first version to put up ISO images for install? I installed 5.2 from ISO not long ago. I have installed 4.2 in the past.
I think it was 4.2 that came with the “awesome” window manager.
Uninstalled this recently as well. It is surprisingly slick for the time and way more modern feeling than you would expect.
Linux was just not corporate enough for it at the time.
In a different timeline….
I still fondly remember sitting in the Sun Lab at University downloading SLS disk by disk.
SLS 1.0.x still had Linux kernel 0.9x on it.
Just getting X at all on your own PC was like a magic trick.
I install Red Hat 5.2 recently. Amazing blast from the past. The only web browser installed was Netscape!
By Fedora Core 1, it was all starting to seem surprisingly modern.
You left a very gracious reply so let’s not fight.
I see a certain amount of irony in the overlap between the group of people ranting that Wayland has too many implementations and the group demanding more implementations of everything else. So that was my point.
Certainly we can agree though that there is nothing wrong with demanding more of both.
One my favourite new distros, Chimera, uses both Wayland and dinit (and Turnstile ).
I am interested to see where the diversity that Wayland provides goes actually. Have you seen this?
https://github.com/CuarzoSoftware/Louvre