X is old and works for the most part but fixing stuff or adding features is hard.
Wayland is new and is supposed to be a successor to X, do what it couldn’t do and don’t repeat the mistakes from it. It should be a drop-in replacement like pipewire but isn’t. Features take long time to develop as devs are engrossed thinking of the best solution to make it happen. A lot of proposed solutions are dismissed as well.
I think the drama around Wayland can be explained by the sentence “it should be a drop-in replacement like pipewire but isn’t”.
Without taking a side on that issue, I will point out that this was not a goal for the Wayland designers ( in their own words - I do not have time to go find a quote but have read this sentiment many times ). Wayland detractors agree with your sentence and, given that expectation, are legitimately upset and even confused that Wayland continues to gain mind and market share against X11.
If you feel that Wayland needs to be a drop-in replacement for X11, it is not ready and may never be. By that metric, some people see Wayland as a failed technology and perceive Wayland users as shills and zealots.
If you are interested in a display server that addresses some of the core design problems in X11 and do not mind moving to something new, Wayland is starting to look ready for prime-time.
If you are non-technical and / or unopinionated the debate is probably irrelevant. Wayland will most likely become the default on whatever Linux distribution you use sometime in 2024 or 2025. You will be a Wayland user. Maybe you already are.
If you are willing to step outside the mainstream, using X11 without Wayland is going to be possible for at least another decade. That said, I am saying “outside the mainstream” because not only will popular Linux distributions and desktop environments start to become Wayland only but the innovation is all going to move to Wayland. There will be many Wayland-only compositors, apps, and features. 5 years from now, not using Wayland is going to really limit the desktop experience. I expect some toolkits ( GTK, Qt, and maybe even WINE ) to drop X11 support at some point ( maybe not soon but sooner than 10 years maybe ). 5 - 10 years may seem like a long time but it will likely come faster than X11 stalwarts expect.
Large parts of the rewrite came from contributors who had never worked on fish before.
That’s pretty useful alone.
And there’s this:
Thread Safety
Allowing background functions and concurrent functions has been a goal for many years. I have been nursing a long-lived branch which allows full threaded execution. But though the changes are small, I have been reluctant to propose them, because they will make reasoning about the shell internals too complex: it is difficult in C++ to check and enforce what crosses thread boundaries.
This is Rust’s bread and butter: we will encode thread requirements into our types, making it explicit and compiler-checked, via Send and Sync. Rust will allow turning on concurrent mode in a safe way, with a manageable increase in complexity, finally enabling this feature.
Vibes are just as important to free/open source software as proprietary software and although there were solid technical reasons for the port, the PR outcomes are added benefits.
Not an answer to you actual question, but: I stopped using dead keys long ago because I found it irritating to have to hit space whenever I needed to break out. Instead I mapped my CapsLock to be a Compose-key which lets me make almost any symbol I ever need in a very intuitive wsy. It works everywhere (incl. Wayland).
I would say that is a false dichotomy. Almost everyone agrees that X11 isn’t the future but the support for Wayland and the specific ways it does things, is not nearly as universal as that. It is just that the problem is huge and has already taken 15 years or so and so it looks like if we want some alternative to X11 that will be done any time soon Wayland is unfortunately the only game in town, no matter how flawed it is.
I’m not a Wayland fan by any stretch, but I’ve come to the same confusion you did. And so has almost everyone else. Which is the real point of my comment I guess.
I think the main problem is that Wayland is not a drop in replacement.
Every software needs to support Wayland, new environment flags need to be created, flags must be used with electron apps…
Nvidia support has been spotty and some functionality has not yet been implemented. I use a custom .xcompose file, which doesn’t work on electron apps. Let me know if there’s a better way to mimic window’s dead keys.
Overall, it’s hard for an end user to change from a solution that is working perfectly to a solution that requires a ton of work and doesn’t yet have the same functionality.
Everyone can understand that Wayland is the future but depending on your needs and hardware the current experience can be great or terrible.
Sure but as someone starting with a new system Wayland just works. Example multitouch works right away on Wayland and if I remember correctly needs configuration on x11.
I had to set a ton more. Without the ozone flags my electron apps flicker and have this sync problem that appears to eat letters while I type them. Different electron apps use different configuration files, it’s a mess.
I wouldn’t consider my setup to be complex enough for the amount of trouble I had to make the system work under Wayland.
I’m using an Nvidia GPU, I’m sure things would be more streamlined if I had something else.
A switch from X11 to Wayland is not just a minor change to your workflow though unless you used all defaults before.
It requires you to replace your window manager, all the little tools related to things like clipboard, automation, screen locking,…
And you would have to do pretty much all of that up front to be able to use Wayland long enough to know if it even works on a permanent basis for you. That is a lot of work to put into a project that has a sketchy history of people claiming for nearly a decade now that it works just fine for everything while clearly not working fine for all use cases.
The point wasn’t so much that there are no replacements, more that every script and every shortcut and everything else using them will have to be changed to work with the Wayland alternative.
Back in the day X was a great protocol that reflected the needs of the time.
Applications asked it to draw some lines and text.
It sent input events to applications.
People also wanted to customize how their windows were laid out more flexibly. So the window manager appeared. This would move all of your windows around for you and provide some global shortcuts for things.
Then graphics got more complicated. All of a sudden the simple drawing primitives of X weren’t sufficient. Other than lines, text and rectangles applications wanted gradients, rounded corners and to display rich graphics. So now instead of using all of these fancy drawing APIs they were just uploading big bitmaps to the X server. At this point 1/3 of what the X server was previously doing became obsolete.
Next people wanted fancy effects and transparency (like drop shadows). So window managers started compositing the display. This is great but now they need more control than just moving windows around on the display in case they are warped, rendered somewhere slightly differently or on a different workspace. So now all input events go first from X to the window manager, then back to X, then to the application. Also output needs to be processed by the window manager, so it is sent from the client to X, then to the window manager, then the composited output is sent to X. So another 1/3 of what X was doing became obsolete.
So now what is the X server doing:
Outputting the composited image to the display.
Receiving input from input devices.
Shuffling messages and graphics between the window manager and applications.
It turns out that 1 and 2 have got vastly simpler over the years, and can now basically be solved by a few libraries. 3 is just overhead (especially if you are trying to use X over a network because input and output need to make multiple round-trips each).
So 1 and 2 turned into libraries and 3 was just removed. Basically this made the X server disappear. Now the window manager just directly read input and displayed output usually using some common libraries.
Now removing the X server is a breaking change, so it was a great time to rethink a lot of decisions. Some of the highlights are:
Accessing other applications information (output and input capture) requires explicit permission. This is a key piece to sandboxing applications.
Organize the system around frames to avoid tearing except for when desired (X doesn’t really have the concept of a frame).
Remove lots of basically unused APIs like fonts, drawing and many others.
So the future is great. Simpler, faster, more secure and more extensible. However getting there takes time.
This was also slowed down by some people trying to resist some features that X had (such as applications being able to position themselves). And with a few examples like that it can be impossible to make a nice port of an application to Wayland. However over time these features are being added and these days most applications have good Wayland support.
I don’t have any sources files in my /etc directory. My Debian install in general is really weird, since the default apt sources came only with some CD ROM source, which did not work with the Internet. So I had to manually add all sources myself (probably caused some of my troubles…) These are my sources right now
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free non-free-firmware deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
I’m assuming these are correct, as they all got that bookworm in them.
I’m back from trying that reinstall with aptitude, and it keeps getting file sizes wrong. It says, that reinstalling all software will take 0 Bytes. After not finding some sources, it tells me that the unpacked packages will combine to 0 Bytes again:
E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python2-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python2:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »libpython2.7-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »python2.7-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »7.0-5« von »libreadline7:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.2.0-travis995~0f91801+bionic« von »appimagelauncher:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »4.9.2-427« von »blockbench:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »0.0.39« von »discord:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »3.2.1-9« von »libffi6:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »libpython2-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »libpython-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »libpython2.7-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »1.1.1n-0+deb10u6« von »libssl1.1:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »python2.7:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2023.1« von »trenchbroom:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »0.11.4« von »weylus:amd64« herunterzuladen. Nach dem Entpacken werden 0 B zusätzlich belegt sein. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python2-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python2:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »python:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »libpython2.7-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »python2.7-minimal:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »7.0-5« von »libreadline7:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.2.0-travis995~0f91801+bionic« von »appimagelauncher:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »4.9.2-427« von »blockbench:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »0.0.39« von »discord:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »3.2.1-9« von »libffi6:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »libpython2-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-1« von »libpython-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »libpython2.7-stdlib:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »1.1.1n-0+deb10u6« von »libssl1.1:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2.7.16-2+deb10u3« von »python2.7:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »2023.1« von »trenchbroom:amd64« herunterzuladen. E: Es konnte keine Quelle gefunden werden, um Version »0.11.4« von »weylus:amd64« herunterzuladen. E: Interner Fehler: Liste der herunterzuladenden Pakete konnte nicht erzeugt werden. E: Perhaps the package lists are out of date, please try ‘aptitude update’ (or equivalent); otherwise some packages or versions are not available from the current repository sources
“Es konnten keine Quellen gefunden werden” meaning, that it couldn’t find the sources for a specific program. I already ran sudo aptitude update so that is not the issue. Soo maybe I really do need to reinstall the entire system?
Are you talking about 2FA login for your own user account or U2F/PIV/WebAuthn in your browser? The latter seems to work out of the box on any non-snap or flatpak browser, but the former needs a bit more setup as that is not a standard feature in Ubuntu yet. I recommend using ykman and yubico-piv-tool for configuring yubikeys in linux, but Yubico also provides a GUI application on their website
Definitely the latter. I have only tried using the Flatpak version of Firefox, but the system won’t even detect the key so it’s no shock Firefox can’t either…
So many content? You mean so many levels? While searching for the current download link for Debian 12, I really just couldn’t find the right one I think, so I just went for one which had amd64 and gnome in the title. It was for a CDROM, but I flashed that onto some USB.
I’ve recently switched to Nobara, and has been unsure whether to go with Wayland or X11. Mostly because I’ve read that Wayland has issues on NVIDIA GPUs and will perform slower, so I went with X11 (On KDE). Is that still the case nowadays, or can I just use Wayland?
Afaik the Nvidia issues are pretty much resolved now, though it may depend on exactly which GPU you use.
It’s definitely worth using Wayland if it’s not having issues, and switching back is absurdly easy, so I’d recommend using Wayland and going back to X if you’re encountering issues.
Tldr: it’ll probably be fine, give it a go and see
SSD’s dont work like old HD’s depending on the generation of tech it might be storing multiple values per cell which means when you “filled” the SSD you put a charge into every single storage cell on the drive.
Garbage collection and TRIM will slowly over time clear out all the cells flagged as deleted but if one bit is still valid in a cell that was holding 3-4 other bits it cant overwrite that, or relocate it.
That means that your files/videos and such stay fragmented and may never get put back together sequentially or in a way that the controller can optimize again for speed.
The only fix, may be running a factory wipe from the Drive MFG’s tool set, that should fully blank each cell and let you re-install and make it feel fresh again.
Be warned though, you have already done a full drive write once at least, this would be another. You can expect some dead cells and while there is over provisioning that should provide replacements you could see a loss in usable space sooner than later.
Applications needs some coordination between each other in order to act like you would expect - things like one window at a time having focus and thus getting all keyboard and mouse inputs. As well as things like positioning on the screen and which screen to render to, the clipboard, and various others things.
X is a server and set of protocols that applications can implement to allow all this behaviour. X11 is the 11th version of the server and protocols. But X was also first created in 1984, and X11 since around 1987. Small changes have been made to X11 over the years but the last was in 2012.
Which makes it a very old protocol - and one which is showing its age. Advances in hardware since then and the way we use devices have left a lot to be desired in the protocol and while it has adapted a bit to keep up with modern tech it has not done so in the best of ways. I also believe its codebase is quite complex and hard to work with so changes are hard to do.
Thus is has quite a lot of limitations that modern systems are rubbing up against - for instance it does not really support multi cursors or input that is not a mouse and keyboard. So things like touch screens or pen/tablets tend to emulate a mouse and thus affect the only pointer X has. It is also not great at touchpads and things like touch pad gestures - while they do work, they are often clunky or not as flexible as some applications need.
It is also very insecure and has no real security measures in place - any GUI application has far more access to the system and input then it really requires. For instance; any application can screen grab the screen at any point in time - not something you really want when you have a banking web page open.
Wayland is basically a new set of protocols that takes more modern hardware and security practices in mind. It does the same fundamental job as X11, but without the same limitations X11 has and to fix a lot of the security issues with X.
One big difference with X though is that Wayland is just a protocol, and not a protocol and server like X. Instead it shifts the responsibilities of the X server into the window manager/compositor (which used to manage window placement and window borders as well as global effects such as any animations or transparency). It also has better controls over things like screen grabs so not every application can just grab a screen shot at once or register global shortcut keys or various things like that. Which for a while was a problem as screen sharing applications or even screenshot tools did not work - but over time these limitations have been added back in more secure ways than how X11 did them.
Additionally any application using a GUI toolkit (like kde, qt or gtk etc) only needs to to update to a version that has native Wayland support. Which means most applications already support it. At least if they don’t use any X11 APIs directly (which is not that common).
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.