If you are already in a committed relationship with a different Debian-based Linux, the extra packages built for this release can be found here.
I would love to build similar setups for ARM SBCs and 32-bit NetBSD, but for the sake of my other hobbies, not now.
Scrollbar Linux is Devuan with extra packages. Devuan is a fork of Debian for traditionalists who don't like the systemd init system. I have no strong feelings about systemd myself and only chose this as a starting place because the Devuan maintainers are *also* UI traditionalists and shipped probably the only XFCE live ISO in the DistroWatch top 100 that does *not* use flat UI or gtk-primary-button-warps-slider. Curmudgeons of the world unite!
Upstream Debian provides us a very large collection of stable versions of packages and regular security updates. Under the hood, every child of Debian from Ubuntu to Mint to Raspberry Pi OS has a very similar set of packages and folder structures. This makes life a lot simpler when compiling a random cool project you found on GitHub or googling, "What is the command for XYZ." The one exception is that most other people will be on systemd, so you will need to look slightly deeper in the search results for the non-systemd ways of managing background services, etc.
Scrollbar Linux currently uses xlibre with xfwm4 or compiz. I have been testng XFCE's new Wayland compositor and intend to include that as well once it is stable and packaged upstream. I may also set up the current XFCE version with labwc if I get around to it.
I've been a fan of X Windows for a long time. When I first learned about Linux as a very naive teenager in the early 2000s, I was amazed that window stacking algorithms were simple enough to have been implemented by more than just two major corporations in the entire history of computers. Naturally, I jumped right into playing with every window manager I could get my hands on. If newer technology ever fully replaces it, I will mourn it the same way I would mourn the demise of vim's batshit key bindings. At the same time, I find the more recent Wayland ecosystem workable for all but a few use cases.
Go run Compiz for a few minutes. Do you really think we hit a brick wall trying to implement support for HDR monitors and the like in X when we didn't trying to implement GPU accelerated video and wobbly, exploding windows?
The reality is that Wayland never *needed* to exist, but people *wanted* to start with a clean sheet rather than hack on legacy code. Then, of course Wayland got stuck in Second System Syndrome (look it up) and design-by-committee for a decade to the point where it is only now getting some features that regular users want.
No, it did. In the '80s. Competing UNIX vendors wanted to have improvements to X as exclusives, so we got locked in a world where the core protocol couldn't change and features added on one system didn't work on others. (Man, doesn't this sound a lot like different Wayland compositors implementing different numbers of protocols today?) This basically got solved when the free version in Linux became the dominant one.
Also, X had a bit of a reputation for being resource-heavy and unstable. The fortune cookie files on old Linux distributions used to have some choice quotes about "Titanic, Hindenburg, X Windows" and such.
Well, it doesn't, but that's not the same as can't. In the Windows XP era, all major consumer operating systems allowed any program running under your account to read any key you typed. On the Windows side, Microsoft made a special exception for administrator password prompts in Vista and added more comprehensive limits in Windows 10. On the X11 side, there's been a Security extension since at least 1996 to limit access, but it crashed programs that tried to capture global hotkeys, didn't separate untrusted programs from other untrusted programs, and was rarely used. XLibre has added an extension to allow multiple separate untrusted application groups and feed applications dummy data instead of errors when they request things they can't have, but no desktop makes active use of this yet.
X11 has two fundamentally-different uses:
X.Org is focused on the latter and keeping the stand-alone server as a fallback for old hardware and software that can't migrate to Wayland. Therefore they take a don't-rock-the-boat approach to maintenance and would rather have bug-for-bug compatibility than code cleanup.
XLibre is focused on cleaning up the old, messy code that made others want to abandon X so that X can be modernized and continue to support the new needs of newer systems without introducing major breaking changes.
These are two valid and SEPARATE technical goals, now supported by separate teams.
The XLibre binaries do not contain a compiled version of Enrico Weigelt's consciousness. Personally, I'm not surprised Weigelt has a tendency to doubt official narratives given that he is East German and, growing up, the official narrative was whatever the now-discredited Communist leaders had to say, but I'm glad he's writing code as a public service rather than running for office.
Earlier versions of the XLibre README contained a section about how the project wanted to welcome and include a great diversity of people as contributors but also said the project was, 'free from "DEI"'. This confused and concerned people who know that DEI stands for "diversity, equity, and inclusion" but do not know that in the right-wing sociolect it has become a synonym for "affirmative action". In other words, XLibre favours nondiscrimination and strict meritocracy over putting your thumb on the scale as a counterweight to all the injustices of the wider world. Which approach is better has been debated for decades and will continue to be debated, but you don't need to be worried that the project is promoting discrimination. They're taking the same side that employment law in the US has for decades.
The packages do not conflict! You can install the native X servers from XLibre alongside the XWayland server from XOrg and use each project for what it is primarily focused on.
X11 has access to the same Linux drivers that allow everyone and their brother to write a separate Wayland compositor.
GNOME and KDE are dropping X11 because they see maintaining a second display system as extra work. By contrast, XFCE is the preferred desktop of a lot of people who prefer X11. There is no shortage of people interested in maintaining the X11 side, and the Wayland compositor is being developed separately from the X11 window manager, meaning they won't have to worry about Wayland development introducing new X11 bugs.
Yes it does! XFCE's own Wayland compositor is still in alpha, but if you're the sort of person who customizes all your dotfiles anyway, XFCE components are absolutely ready for inclusion in your Wayland rice. You can also run the entire desktop as is with labwc or similar. This is basically the equivalent of using a desktop-independent window manager like openbox on the X11 side and has the same disadvantage of not following XFCE's window-decoration preferences but results in a quite usable if unpolished experience.
You can even run the entire traditional desktop inside the scrolling/tiling window manager niri, and the result is something usable and halfway attractive, not an utter nonsense.
One challenge for creating classic PC UIs on modern XFCE (by which I mean the kind of keyboard-and-mouse focused UI that was popular from the release of Windows 95 to the release of the iPad) is that GTK3 has some non-traditional defaults that don't appear as toggles in your desktop's settings and that many people do not know how to turn off.
Another challange is that many of today's more traditional-looking UIs are built in Qt, and it can be pretty intimidating getting GTK and Qt apps to share the same theming.
This is, of course, a symptom of the GTK-world standing as a house divided: GNOME and its apps have embraced tablet-like UI and a framework that deliberately ignores system-wide UI themes. Many of its developers have even signed an open letter asking distros not to use non-default themes. (As a customization love, I endorse this parody.) The underlying GTK4 toolkit was still designed to be used by multiple desktops — but seemingly without considering the actual current use-cases of any desktop other than GNOME. So XFCE, MATE, and Cinnamon remain on GTK3.
For at least partial solutions to the challenges listed above see: