• 0 Posts
  • 308 Comments
Joined 2 years ago
cake
Cake day: July 16th, 2023

help-circle

  • I will bet the full dollar that Trinity never gets ported to Wayland.

    They would have to port it to a version of Qt that supports Wayland. If they were ever going to do that, they would have done it by now.

    MATE (GNOME2) ported from GTK2 to GTK3 so most of MATE works on Wayland today. You can use all the bits with a different Wayland compositor. And I think they are making their own.

    But Trinity maintains their own fork of Qt3. Bringing that up to Qt6 or adding Wayland to Qt3 would be a big project. I do not see either happening.


  • There are few Wayland only apps today. But as the percentage of Linux desktop users on Wayland goes over 80 percent, that will change.

    And today, GUI toolkits and desktop environments have to limit features to those that will work in both environments. But not for long.

    My guess is that it will be totally impractical to use an X11 only desktop 3 years from now. 5 for sure. In fact, I bet few people will even have Xwayland installed 5 years from now. To run what? Xfig? Netscape?

    But certainly it will still be possible to run an X server. Xorg itself will still probably run fine. It already uses KMS and DRI from the kernel and those may not change much. And I am sure at least a few zealots will still be pushing XLibre a decade from now. And Wayback will almost certainly let you run an X11 desktop for many, many years to come for those “legacy use cases” you talk about. Like running CDE for a couple of hours.

    Probably the most interesting development has been Phoenix. They have floated the idea of having an X11 first environment (eg. using an X11 window manager) that can run Wayland apps too. If that actually happens, I am sure it will find some fans. If you have spent 15 years fine-tuning your FVWM or Xmonad config, you won’t want to give it up.

    It will be interesting to see where the BSD world goes with all of this. I think FreeBSD will go Wayland. But NetBSD and OpenBSD could be x11 holdouts. But the Wayland-only app problem will impact everyone. Time will tell.


  • Wayland has improved a lot in the last few years. And yes, there are and have been differences in hardware.

    I think the biggest difference is likely to be software though. Primarily in two ways.

    First, a lot of people are using older software. Not to pick on Debian but it is a good example. A Debian Stable user may be using NVIDIA drivers that are literally years older than what an Arch user is using. Paired with Wayland compositors and XDG portals that are older as well. So when they talk about Wayland (even today), they are really describing the experience from years ago. Alma Linux probably falls on this camp.

    Second, what use cases are well supported on Wayland still varies from compositor to compositor. Somebody using Plasma 6 may experience that pretty much everything just works. Somebody using Sway may find that some uses cases are still immature.

    Put these together and you have a lot of NVIDIA on Debian people telling you things don’t work and a lot of AMD on Fedora people wondering what they are talking about.

    Today, Wayland and Xorg are more “different” than better or worse. If you are happy with Wayland, migrating to Xorg would probably feel like a real step back and there would be all kinds of issues and deficiencies. But, for some, the reverse can still be true. Wayland still has a few gaps.

    Finally, they ARE different. Which means that if you insist on trying to make Wayland work exactly like X11, it is easy to make it seem like it is not working, even if Wayland can do exactly what you need in some slightly different way.

    The important thing to acknowledge though is that more than half of Linux desktop users run Wayland now. And the majority of new users start in Wayland and will never switch. So X11 is the weird one now. And while Xorg is about as good as it is ever going to be, Wayland gets better every day.




  • Almost everything you care about should be in /home so back that up. Many people keep it on a separate partition or drive to make changing distros (or reinstalling the existing one) easier.

    Most of your system config is in /etc so you may want to make a copy of that too.

    But the proper process on Linux is not to re-install. It should not be necessary.

    On top of this, part of the reasons to use containers is that you can create and destroy them at will while leaving your host tidy and stable. I use Distrobox quite a bit for this reason.





  • This is not meant to fight but to reveal an alternate perspective.

    I never understand why people leave these comments. That is, I do not truly understand the objection. I assume these comments are anti-Apple or anti-corporate in some way but I am really just guessing.

    Here is what I think could motivate people to work on Linux support for this hardware.

    1 - people have this hardware or like it and want to run Linux on it. In other words, people with the skills are serving their own interests and not driving towards some great social outcome like the question “why not riscv” would suppose. This is the “scratching your own itch” aspect of Open Source.

    2 - people with the skills find this hardware interesting or are attracted to the challenge that it has been made difficult. Similar to #1 with a different motivations but still a personal one.

    3 - some people are drawn to “freeing” things that are closed. The more proprietary, the more attractive it is as a target.

    4 - people with the skills are thinking of their impact on the world and realize that these are extremely popular devices that are destined for the landfill after really short lives if allowed to remain fully proprietary.

    If I had the skills, honestly I would find all of these compelling. The last one would provide the greatest fulfillment. There are A LOT of these devices being sold. I think Apple may be the single most popular laptop brand. The social good that comes from providing Linux support for Apple Silicon may be greater than time spent on any other hardware.

    I am somebody that will ultimately benefit from all these efforts. It has been years since I have given Apple any money but quite like their hardware. I have 4 old Apple laptops, 2 iMacs, and one Mac Pro. These were all bought used or acquired for free. They are amazing Linux machines. I do not have any Apple silicon but I almost certainly will at some point. And it looks like the M1 and M2 hardware is already a great experience. In my view, old high-end gear is far better than new low-end gear. An Apple M1 laptop today is still nicer than the lower half of the Windows market. Buying a used Mac keeps two machines out of the landfill.

    But, if I had the skills, the joy of just getting it to work would also be a motivator. It would be a fascinating project. And it is one that brings a lot of positive attention and even employment opportunity as we can see from where Asahi Linux contributors have ended up. Making Apple Silicon work provides a lot of what draws people to write free software.

    Developing the RISC-V ecosystem would also be fulfilling. But this even helps with that. Creating a large and vibrant ARM Linux desktop community helps diversify and mature Linux in all kinds of ways that will also benefit RISC-V. One of these is just normalizing for us users the idea of running on something that is not x86. Another is increasing the size of the software ecosystem that builds and runs on RISC (either ARM or RISC-V.

    And if the objection is that Apple will see greater demand for their proprietary products as a result of these efforts, I think we are greatly overestimating the current size of the community as a percentage or the overlap between “mainstream”’ Apple buyers and those of us with the patience to wait or suffer the limitations.



  • CachyOS will work on older hardware as well. There are four repositories for x86-64 v1, v2, v3, and v4. If you have newer hardware, the v3 or v4 packages will theoretically give you better performance. That is probably what you are talking about.

    That said, the v1 repos will work on x86-64 machines going back to 2003. Not exactly bleeding edge.

    The only thing that I have noticed is that packages are not all in sync between repos with v1 lagging behind v3. For example, I think Cachy is already on the 6.18 kernel but the v1 repos still only have 6.17. I have seen svt-av1 lag as well.

    I am not a CachyOS user so apologies if any of my info is dated.

    I will never say anything bad about EndeavourOS.




  • I use EndeavourOS on Mac hardware for very similar years.

    Wifi (Broadcom-wl on the older stuff and brcmfmac_wcc on the newest) works well on all of them.

    Webcams work well on all of them as well. Most are just USB cams but some use the FaceTimeHD module that builds with DKMS but works very well for me.

    I cannot remember if I had to install the FaceTimeHD driver or if it was auto-installed by EOS. Even if not, it is in the repos and one line to install the package.


  • I highly recommend EndeavourOS for old MacBooks.

    I have a 2008 iMac, 2015 iMac, 2012 MacBook Pro, 2016 MacBook Pro, 2013 MacBook Air, 2017 MacBook Air, and 2020 MacBook Air all running EOS (last one uses a special kernel because of the T2 chip).

    They all run flawlessly including the Broadcom WiFi. The Arch kernel is the only one I have found where these drivers work well and EOS sets them up automatically during install.

    CachyOS is also an option but the video is wonky on my older MacBooks. EOS is flawless.


  • “For most users, this will have no immediate impact. The vast majority of our users are already using the Wayland session”

    So happy to read this as there is always somebody still claiming that “Wayland does not work” and “nobody wants to switch to Wayland” just because they have not.

    Also great to see that the plan is for Wayland on FreeBSD as well so the Open Source desktops can stay aligned. GNOME on FreeBSD is more problematic, not because of Wayland but because of Systemd.