I was about to say "no it doesn't" (having installed bookworm a few weeks ago, and most definitely not having wayland), but actually it seems you're right, and "by default" just means "if you choose one of the compatible desktop environments", one of which appears to be the default selection.
If that's all they plan on doing: awesome, actually, this way anyone can pick what they prefer. I was afraid they were going to pull something like systemd (though ultimately it makes sense, as maintaining sysvinit stuff for all services would have been unfeasible; not so, at least for now, with X11/Wayland).
When was the last time you tried it? Up until recently I have had issues but I've been using it for the last few days and it feels good now. All of the problems I had with it the last few times I've tried it (drag and drop not working, copy-paste being weird, fractional scaling) have seemingly been fixed.
I cannot try it, as my window manager (and in fact almost the entirety of small lightweight window managers) is not compatible with it, and never will be given the insanely higher requirements to implement a compositor compared to a WM. Wayland supporters say that'll change; I don't see how.
There are at least 20 different options to choose from, surely one of them has what you want. And that number is only going to rise. Saying it never will is extremely short-sighted.
I want an openbox/fluxbox look and UI. About the only one I know of is labwc, and it's shit (despite being proudly on your list). I'm fairly sure that a lot of these, in fact, aren't close to usable.
Again, it's not that relevant, for now I can still use Xorg. For now.
It's changing by having a library like wlroots do most of the work.
When you consider the overall picture, "wlroots + compositor" is actually less complex than "X11 + window manager" because you no longer need to consider the insanely high requirements of having to have a team maintaining the spaghetti mess of X11 code.
Wayland-based dwl has roughly the same line count as X11-based dwm (about 2.2k), without having to depend on a whole separate service as big as X11.
But of course, it being a completely different approach, it's likely that for most smaller projects (ie. not Gnome or KDE) it's easier to start a new project than creating a layer to maintain two different parallel implementations.
If you want something that's more or less compatible with openbox, there seems to be this project, labwc, which claims to be inspired by openbox and compatible with its config/themes.. though I haven't personally tried it.
Also keep in mind that openbox (and I expect labwc too) doesn't include any "panels" / "taskbars" or anything like that... and it's likely your X11 panels might not work well if they do not explicitly support Wayland (but I believe that, for example, xfce-panel now supports both).
Previously, on Linux, your desktop environment is made out of:
The display server (xorg), in charge of dealing with the video card (by talking with drivers in the kernel through a unified interface, DRI), and handling how to display stuff properly on your particular combination of hardware, including your physical screen and its peculiarities.
A window manager, in charge of asking software for what they want to draw, then drawing windows, decorating them, etc. and more generally organizing what will be displayed on the screen and how it will be displayed.
A protocol allowing both to communicate between each other.
That protocol is old, shitty, and insecure. Those are rightful criticisms of it, and it could be argued there is a need for an alternative. This is the often touted justification for wayland.
Note that the way windows and the general desktop environment is handled in the model above is completely distinct from the actual display server; this has a nice advantage: one can write a WM relatively easily, and as such there are hundreds available for linux users to choose from - including some that traditional Windows and Mac users would consider visually exotic and different, such as tiling WMs. This has long been considered a distinct superiority of Linux over, for example, Windows, where all of this is a monolithic block.
Now the dudes that introduced wayland didn't just decide to secure the protocol; they decided to do away with that separation. Now a "compositor" handles all the stuff both xorg and the WM used to do. This means that almost none of the existing window managers work on this thing (actually the truth is none of them do, but Gnome and a few others for example created whole new compositors - today, you can run "gnome" either with that shit or with Xorg, for example), and that there will be far less of them to pick from in the future. The people implementing wayland didn't even consider this an issue at first (everyone uses gnome or KDE, right ? imbeciles), so IIRC third party devs eventually tried to implement a library to restore some degree of separation (wlroots). This still requires reimplementing a WM though, and ultimately is extremely limited anyway due to the very "security" concepts the wayland protocol introduces. Some stuff that was trivial on Xorg will not be possible at all.
You might be considering why we're talking about security in the context of a display server.
Well, the Wayland people noticed that more and more, people were installing software on Linux not through the official repositories of their distributions (which are high quality, somewhat audited, etc.) but from a galaxy of alternatives proposed by a variety of actors: flatpak, AppImage, snap, etc. The reason for this is the quality of software in general has taken a dive, and so has the quality of developers in the open source community; the usual process for someone wanting to be published on, say, debian, would normally have been to follow a few simple rules and to publish your package, accepting it'll be audited and you may have a few points to work on before it'll get up on the repos. Many devs these days are not interested, and deploy their software through the alternatives I mentioned above (which are basically all container or chroot based approaches to produce a "minisystem" with a set of defined libraries, meaning only your kernel will differ from the person having published that package).
As a result, a lot of clueless people are now installing shady software like monkeys on their system, coming from anywhere, just like on Windows. As such, the Wayland creators consider stuff such as an application discreetly capable of capturing the screen, or copying the clipboard from another app, to be potential "security issues". You may be interested to now such "security measures" do not exist on, for example, Windows (but the "security issue" do).
I'm not even trying to argue whether or not they're wrong here. I think mostly they are - the amount of issues and use cases they didn't consider is incredibly large, and it's been biting them in the ass ever since - but it's irrelevant; in theory this would not be much of a problem because, you can just keep using Xorg and your WM, right ? the fear is that maintainers and support for these will dry up (I doubt that, personally), but also and more cruciallly that as Wayland becomes more and more omnipresent for many users, various features from various critical software - such as the browser - will eventually become problematic for Xorg users.
I pray Debian will never include that wayland shit as the default but sadly, I suspect they will.
Debian 12 uses Wayland by default.
I was about to say "no it doesn't" (having installed bookworm a few weeks ago, and most definitely not having wayland), but actually it seems you're right, and "by default" just means "if you choose one of the compatible desktop environments", one of which appears to be the default selection.
If that's all they plan on doing: awesome, actually, this way anyone can pick what they prefer. I was afraid they were going to pull something like systemd (though ultimately it makes sense, as maintaining sysvinit stuff for all services would have been unfeasible; not so, at least for now, with X11/Wayland).
Thanks !
When was the last time you tried it? Up until recently I have had issues but I've been using it for the last few days and it feels good now. All of the problems I had with it the last few times I've tried it (drag and drop not working, copy-paste being weird, fractional scaling) have seemingly been fixed.
I cannot try it, as my window manager (and in fact almost the entirety of small lightweight window managers) is not compatible with it, and never will be given the insanely higher requirements to implement a compositor compared to a WM. Wayland supporters say that'll change; I don't see how.
There are at least 20 different options to choose from, surely one of them has what you want. And that number is only going to rise. Saying it never will is extremely short-sighted.
I want an openbox/fluxbox look and UI. About the only one I know of is labwc, and it's shit (despite being proudly on your list). I'm fairly sure that a lot of these, in fact, aren't close to usable.
Again, it's not that relevant, for now I can still use Xorg. For now.
It's changing by having a library like wlroots do most of the work.
When you consider the overall picture, "wlroots + compositor" is actually less complex than "X11 + window manager" because you no longer need to consider the insanely high requirements of having to have a team maintaining the spaghetti mess of X11 code.
Wayland-based dwl has roughly the same line count as X11-based dwm (about 2.2k), without having to depend on a whole separate service as big as X11.
But of course, it being a completely different approach, it's likely that for most smaller projects (ie. not Gnome or KDE) it's easier to start a new project than creating a layer to maintain two different parallel implementations.
If you want something that's more or less compatible with openbox, there seems to be this project, labwc, which claims to be inspired by openbox and compatible with its config/themes.. though I haven't personally tried it.
Also keep in mind that openbox (and I expect labwc too) doesn't include any "panels" / "taskbars" or anything like that... and it's likely your X11 panels might not work well if they do not explicitly support Wayland (but I believe that, for example, xfce-panel now supports both).
deleted by creator
Previously, on Linux, your desktop environment is made out of:
That protocol is old, shitty, and insecure. Those are rightful criticisms of it, and it could be argued there is a need for an alternative. This is the often touted justification for wayland.
Note that the way windows and the general desktop environment is handled in the model above is completely distinct from the actual display server; this has a nice advantage: one can write a WM relatively easily, and as such there are hundreds available for linux users to choose from - including some that traditional Windows and Mac users would consider visually exotic and different, such as tiling WMs. This has long been considered a distinct superiority of Linux over, for example, Windows, where all of this is a monolithic block.
Now the dudes that introduced wayland didn't just decide to secure the protocol; they decided to do away with that separation. Now a "compositor" handles all the stuff both xorg and the WM used to do. This means that almost none of the existing window managers work on this thing (actually the truth is none of them do, but Gnome and a few others for example created whole new compositors - today, you can run "gnome" either with that shit or with Xorg, for example), and that there will be far less of them to pick from in the future. The people implementing wayland didn't even consider this an issue at first (everyone uses gnome or KDE, right ? imbeciles), so IIRC third party devs eventually tried to implement a library to restore some degree of separation (wlroots). This still requires reimplementing a WM though, and ultimately is extremely limited anyway due to the very "security" concepts the wayland protocol introduces. Some stuff that was trivial on Xorg will not be possible at all.
You might be considering why we're talking about security in the context of a display server.
Well, the Wayland people noticed that more and more, people were installing software on Linux not through the official repositories of their distributions (which are high quality, somewhat audited, etc.) but from a galaxy of alternatives proposed by a variety of actors: flatpak, AppImage, snap, etc. The reason for this is the quality of software in general has taken a dive, and so has the quality of developers in the open source community; the usual process for someone wanting to be published on, say, debian, would normally have been to follow a few simple rules and to publish your package, accepting it'll be audited and you may have a few points to work on before it'll get up on the repos. Many devs these days are not interested, and deploy their software through the alternatives I mentioned above (which are basically all container or chroot based approaches to produce a "minisystem" with a set of defined libraries, meaning only your kernel will differ from the person having published that package).
As a result, a lot of clueless people are now installing shady software like monkeys on their system, coming from anywhere, just like on Windows. As such, the Wayland creators consider stuff such as an application discreetly capable of capturing the screen, or copying the clipboard from another app, to be potential "security issues". You may be interested to now such "security measures" do not exist on, for example, Windows (but the "security issue" do).
I'm not even trying to argue whether or not they're wrong here. I think mostly they are - the amount of issues and use cases they didn't consider is incredibly large, and it's been biting them in the ass ever since - but it's irrelevant; in theory this would not be much of a problem because, you can just keep using Xorg and your WM, right ? the fear is that maintainers and support for these will dry up (I doubt that, personally), but also and more cruciallly that as Wayland becomes more and more omnipresent for many users, various features from various critical software - such as the browser - will eventually become problematic for Xorg users.