The X.Org Server Is Abandonware?
phoronix.com
phoronix.com
1) the old, mostly working thing is being abandoned in favor of
2) that new thing which doesn't work in so many cases it's laughable, even after 11 years. How many years was it between the concept of X and a working release at Palo Alto?
Note that the new situation is so perfect for passing the buck from the windowing system to the compositors, and compositor folks are busy fighting feuds over which one another's private protocols or even public ones they are not going to support.
Oh, and the browsers. Chromium is making its first shy bumbling steps towards actually working on Wayland! A mere decade after!
I've heard it was so much easier to write Wayland clients, what could have happened?
Upd: This toxic development culture in a nutshell is exactly what this https://news.ycombinator.com/item?id=24165445 is about. Well, we know it's not limited to Google.
I don't get why Wayland is slow, when Enlightenment was fast on machines with 32MB of RAM, a 3dfx Voodoo, a spinning HDD, and a 66MHz CPU...
Also I think 3dfx Voodoo was the magic pixie dust, once you ever go OpenGL, you're not going back.
EFL is written in C so it does have to work within the limitations of C but -non-toy- GUIs are inherently object oriented so things will be a bit more complicated than Qt that can lean on C++'s support for object oriented programming. Especially since apparently EFL also supports bindings to other languages which may also make things a bit more complicated.
Luckily I got an opportunity to a new project. And the company in question (Samsung) ultimately dropped it IIRC.
I gave it as an example of something which ran rather sophisticated theming/compositing/effects on hardware at least 2 orders of magnitude slower than today, and something which modern Ubuntu/Fedora struggle with.
I'd encourage you to compare the specs of the 3dfx Voodoo (the "magic dust") to even bottom-barrel integrated graphics of 2020.
The laptop in question is from the late 2016.
So much for "the world that is". My machine must be very, very otherworldly.
No. This is the thinking of people who can't see the utility of a use case they never personally use. It's the thinking of people who believe that "ssh -X" is "obsolete" because RDP exists, or that window managers can become obsolete because the fashion has moved on. X works, it's worked for decades, and saying that it's never worked doesn't negate that.
I have. It was written by someone who doesn't know the difference between a "client" and a "server".
+----------------+ +----------------+
| Client +---->+ Server |
| | | |
| +-----------+ | | +-----------+ |
| |X Server +<---------+Application| |
| +-----------+ | | +-----------+ |
| | | |
+----------------+ +----------------+
Sure, all the software can stay where they are if all the developers had to serve is you. But that is just not the reality.
Meanwhile I want my Linux system to run VR, multiple 4K displays, very demanding games and bluetooth headphones. And Linux is the worst for it, because everything feels laggy and half polished there and on the proprietary OS my setup feels MUCH faster.
Sure, it's not Linux's fault, but let's stop saying everything is fine and dandy because Emacs is still running.
What we're arguing is why everything is not fine.
SGIs ran VR, multiple displays, and very demanding apps in the nineties too. They did all sorts of wonky, complex, 3d input devices too. So did DEC Alphas. This is the stuff Unix was built for.
My claim is that nineties Linux was much closer to having the right architecture for it than 2020 Linux for this sort of stuff. The reinventions and onion layers didn't help; they hurt.
I think the only piece nineties Linux didn't anticipate was the level of hot-swapping hardware (USB, Bluetooth, displays, etc.), and the level of power management. Modern Linux never got that architected or integrated quite right, because it was built with hack upon hack upon kludge. It's split up in bizarre ways between kernel and user space which would be really tough to clean up right now.
They did, modular kernels date back as 2.2 at least. And USB was born in that era.
* My USB webcams wouldn't show up in a different order each time I reboot. This works fine under Windows and Mac.
* My monitor configuration wouldn't be hardcoded in my xorg config file, or swapped around manually with xrandr. I'd have a way to code up config options for whatever is plugged in, and if something unanticipated happens, it'd do something reasonable until I coded that config in too.
* I wouldn't need to reconfigure my drawing tablet to connect to the right monitor each time I plug it in.
* The system wouldn't get into an unrecoverable, unstable state with e.g. an unreliable USB cable.
.. and so on. It's designed for a fixed set of hardware, with layers on top of that to support hotswapping. I don't have "USB 4k Logitech Webcam" on the native level. I have /dev/video3. I then have layers to map names back.
Same thing with HDDs too, actually. I refer to them as /dev/sdc4, rather than by a GUID or name or similar. Layers with onions.
$ ls /dev/disk/by-uuid/
266c945c-1c6d-40e7-b770-73864a5541fa
$ cat /etc/fstab
UUID=266c945c-1c6d-40e7-b770-73864a5541fa /1) https://www.raspberrypi.org/documentation/installation/insta...
2) man fdisk
3) man mkfs
And so on. The /dev/sd_ is primary, with UUIDs as kind of an afterthought
It ought to be the other way around, with UUIDs as the primary, proper, canonical name and interface, and a legacy backwards-compatibility layer for /dev/sd_ devices. It's even reflected in the directory structure. Yes, I CAN list disk "by-uuid," label, id, partuuid, or path, but those are special cases with sd_ as canonical.
It's kinda retrokludged in there. I never said USB/etc. didn't work. Just that it wasn't architected for it.
Yes, we need a newer web browser, but that could run on old-school Linux/Unix just fine. Aside from that, there isn't anything wrong with nineties Linux which couldn't have been brought up to modern standards with a bit more discipline.
Someone decided ALSA (or OSS, it doesn't matter) was rough to deal with, so they build Pulse and JACK on top of it, rather than a modest expansion of ALSA. Someone didn't like the network layer, so they build a userspace wrapper, and someone didn't like that, so they wrapped it up in a GUI.
At the end of the day:
1) Everything is slow, requiring literally more than 100x the resources it once did.
2) Everything is complex, with layers upon layers, and text files with comments "This is managed by my hack. DO NOT EDIT THIS BY HAND. I keep the exact same data elsewhere, in my own config file, since I couldn't be bothered to read what's in the line below."
3) Everything is brittle and hard-to-understand. I knew how nineties Linux booted. Today, the logic is distributed among dozens of layers, mostly because people wanted to reinvent new things, rather than polishing/improving/fixing old ones. Different apps go for the wrong layer, and tutorials point to the wrong ones too.
Now Ubuntu is throwing its hands up at the mess, and building snap to hide all this under yet. another. layer.
As a footnote, ALSA was just about the last time this happened right, with it replacing OSS while maintaining compatibility.
I don't use pulseaudio, networkmanager, desktop environment, works perfectly in Arch Linux [1]. Arch has great wiki, it is correct. System is quite transparent.
I am fine with systemd but, for example, Void Linux [2] uses runit, Alpine Linux [3] uses OpenRC and is compiled statically.
Arch Linux pacman serves my needs perfectly, it is quick, it shows only relevant information. AUR provides ready made PKGBUILDs.
Lots of Linux distributions is its strength. It allows people with niche requirements find its home. We are far better members of societies when supporting our system than grunting.
Unless you want to ship something, troubleshoot something, or figure out how something works without hours of googling.
Ship and troubleshoot solved by distro maintaires. Niche products solved by Flatpak and its runtimes.
What I find strange is sitting on the place one does not like. There are so many choices around.
I have never had problems distributing binary builds for Linux. There are a number of system libraries that are backwards compatible: glibc, asound, libGL, etc. - test on the oldest you want to support and any other libs you just ship yourself. And that would not be different with only one distro either unless you only care about one release of that distro.
1) I'm not ready to jump installed systems to arch right now.
2) Next system I install will probably try arch.
Thank you!
Gentoo is feeling left out. It's the OG distro for those who have strong opinions on how their system sould work but not strong enough to do eveything by hand.
I've switched to Arch Linux, base install covers network configuration. It gave me stable platform, I can grow my knowledge, I can fix my system.
Void Linux and Alpine Linux are just examples of what could match voiced concerns. I lot of people recommend Manjaro, looks like a simple way to try Arch based distro. Some problems stem from upgrading release, Debian Testing could help. But I have not tried them.
I've tried Ubuntu, I don't like distribution upgrades, default theme, constant experiments on users. Gentoo is my first distro, as C++ dev at that time, compilation was fascinating. I still enjoy 3 commands joke [1], looks like it is possible to install binary packages these days. I've tried Alpine, I don't like apk, systemd and glibc are good enough for me. I've tried OpenBSD, hardware support was not as good as on Linux. I'm playing with NixOS but I am so used to Arch.
And I want to stress, each of these system has something I enjoy. It is just me who is driven by minimizing negative points.
Part of that is working Bluetooth, power management, webcams, video conferencing, OBS, and similar. Historically, OpenBSD was behind Linux on working reliably.
Debian used to do this before:
1) It fell behind on hardware support, as laptops took over desktops; and
2) Ubuntu/Fedora started putting out massive numbers of half-baked technologies, and everything building atop those.
I switched to Ubuntu, without Gnome, but increasingly, things don't work without Ubuntu's UX, and snap shows a future I don't want to head down anymore.
I'll look into arch linux, as someone suggested.
Webcams and power management work fine on OpenBSD (assuming there exist drivers for your hardware), but Bluetooth isn’t supported at all.
What I like about it is the simplicity of everything. If you want to change your mouse sensitivity, you add a line to a particular file in /etc. If you want to autojoin a particular WiFi network, you add the SSID and password to a particular file in /etc. If you want to start a daemon on boot... you get the idea. No massive complex configuration systems with giant blobs of XML that nobody understands.
Unfortunately the flip side is that things move more slowly — they won’t support Bluetooth until someone writes code that meets the system’s bar for correctness, simplicity, reliability, documentation, etc. — which might be never. But the stuff that does work is fantastic.
If hardware/software support requirements tie you to more mainstream OSs, I do agree with other posters that Arch is the closest thing to what you want, but it’s still far from perfect.
Do you know if:
1) Zoom works? Linux has a blob which does.
2) OBS works? This is critical.
3) How is video support with ATI/Nvidia? Will my multimonitor setup break?
The other thing which scares me is the manual upgrade process. On my systems, I've done apt-get update/dist-upgrade for a quarter century now, with never an issue.
2) I don’t know.
3) AFAIK it should work.
Using the BSDs as a workstation, rather than a server, is a bit niche. Like Linux, but even more so. So unfortunately it’s still a labor of love and a lot of modern stuff won’t be supported.
It had dmix.
Nah, even ALSA was a needless overcomplicated mess. They should have just built on top of the super simple /dev/dsp. Instead we got new incompatible APIs wile OSS apps were left with requiring exclusive access to your sound card.
Not really, it is just a pile of hacks on top of hacks, starting by everything is a file until one needs to use sockets.
I call systems like this CADT-compliant after Jamie Zawinski's Cascade of Attention-Deficit Teenagers idea.
Wayland is a system for which CADT-compliance (and maybe security) trumps nearly all other concerns. No surprise, the primary use case for Wayland is and was always GNOME -- the very system for which Zawinski coined CADT.
Sure if someone wrote it in Rust it would be also safe and secure /s
On Wayland I get excellent multi-monitor support (mixed scaling ratios, much better automatic detection and configuration, much better plug-and-play). I also have a touchpad on my XPS that feels just as good as a Mac.
To boot, I haven't had to touch a config file related to input devices or output devices a single time using Arch/GDE/Wayland.
Honestly, I'd probably still be running linux in a VM on my laptop if it weren't for Wayland.
If X is your opinion of "stable and working" then I don't want any part of your systems.
Dell Precision 7520 with an AMD GPU. The degree of flakiness is different depending on whether you're on Plasma or GNOME, but it's there nonetheless.
Moreover: when I pass through the dGPU to a virtualized macOS, all monitors I plug in just work!
I switch between a station that has a 4k display next to a standard 1920x1080 display as well as my laptop display (3200x1800) and my home setup with the laptop and 2 4k displays.
I had an issue on the 4k displays when I attempted to run two displays and a usb hub on a single thunderbolt line, but that wasn't Wayland, that was me being dumb: The thunderbolt protocol only support 40Gb/s and each monitor uses 20Gb/s and the hub eats another 10Gb/s. If the hub got detected last, it dropped to usb 2, if one of the monitors came online last, it would drop to 30hz refresh rate. Frankly - I was a little floored when I realized that I was the one being dumb and the system was mostly still just making things work. Just for shits and giggles I booted up an x-session after to see what it does. The answer is lots of black screen.
How does X work on that setup?
Mixed scaling? Is that that thing when you open chrome and it’s blurry on your hidpi monitor?
It's a painful first compile, but the only issues I've hit have been a few menus in the extension debugging screens that are too small.
1. The old, mostly working thing waits your commit
2. That new thing can have some help too
I recommend developers story about this "mostly working thing" (2014) [1]. It is quite fun and eye opening, he clearly knows his subject better than most of the comments.
Wayland demo worked almost from day one. I've run it in 2010 [2]. But we need applications, that is migrating toolkits and this took 10 years.
It is very toxic development culture, cancel culture, mob.
[1] https://www.youtube.com/watch?v=GWQh_DmDLKQ
[2] https://bbs.archlinux.org/viewtopic.php?pid=858020#p858020
I've been Python developer at that time, the writing was on the wall. They have not provided migration path. PEP 414 "Complaint: This PEP may harm adoption of Python 3.2" [3], this is insane. Community voted with feet — they've stayed with Python 2 until clean migration path arrived. I've switched to Ruby and been happy since.
Ruby 1.8.7 was supported for five years.
You had to write Python 2 code and run 2to3, you had to live in the past or abandon it.
[1] https://raku.org/archive/doc/apocalypse.html
[2] https://en.wikipedia.org/wiki/History_of_Python#Features
* print is function
* string is unicode by default
Should have been clean and easy migration path
# python 2
from __future__ import print_function
print(u"foo")
u"" # was u""
b"" # was ""
Python 3.0.0 Dec. 3, 2008
Python 3.3.0 Sept. 29, 2012
Ruby 1.8.7 2008-05-31
Ruby 1.9.1 2009-01-30 # first 1.9
Ruby 1.9.2 2010-08-18 # people already switched to 1.9
Ruby 2.0.0 2013-02-24 # first 2.0
Ruby 1.8.7-p352 2013-06-27 # last 1.8
How specifically Wayland harms you? I've opened GTK+ tutorial [5], compiled code, works both on X.Org and Wayland. How it is not clean migration path?
And no, it is not XWayland which is additional migration path, I've removed it for this test:
$ xterm
xterm: Xt error: Can't open display: :1
[2] https://www.python.org/downloads/
[3] https://medium.com/rubycademy/the-evolution-of-ruby-strings-...
[4] https://www.ruby-lang.org/en/downloads/releases/
[5] https://developer.gnome.org/gtk3/stable/gtk-getting-started....
Sorry, have you tried to maintain a C extension for both 2/3? Or a unicode heavy application?
This is a silly statement, there's a reason that major packages took a decade to migrate. There are thousands of little details that are incompatible.
Nothing required big 2/3 change. Ruby and Go done it right — a series of small changes. Python 2.* had it right. The attitude of language developers was clearly stated in PEP 414 and 2to3 approach — no backward compatibility. That is nonsense, every python program had backward compatibility several minor versions deep.
Select one issue and work on it. Unicode:
# python prev
u"" # or from __future__ import unicode_literals
b""
# python next
u""
b"" # or from __past__ import binary_literals
Wayland transition is nothing like Python 2/3. It is big but mostly invisible, XWayland runs X11 applications, toolkits hide implementation details, no X.Org deprecation.
The situation with wayland migration seem to be somewhat similar with the python 3 migration. Many gui apps that uses gui toolkit probably don't need major modification, or no modification at all. But some apps that requires platform-specific access are heavily affected and might require some major refactor, and they probably won't do it until the benefit of migrating to wayland outweigh staying on xorg.
Also, unlike python 3 migration where most of the community agree that the move is justifiable will have to happen eventually, in the case of wayland migration, the community opinion seem to be split which certainly harm wayland migration progress.
$ python3.2
Python 3.2.6 (default, Oct 26 2020, 15:29:09)
[GCC 10.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> u"foo"
File "<stdin>", line 1
u"foo"
^
SyntaxError: invalid syntax
$ python3
Python 3.8.6 (default, Sep 30 2020, 04:00:38)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> u"foo"
'foo'
> Django 1.5 introduces support for Python 3 - specifically, Python 3.2 and above.
Notice version gap — no support for 3.0, 3.1. It was quite common.
> python 3 migration where most of the community agree that the move is justifiable
If people believed breaking change was justified they would move to 3.0, it did not happen.
I've seen both Python and Ruby community, Ruby made two breaking changes (1.9 and 2.0) while Python got its PEP 414. There was a huge split among developers.
---
Essentially you are describing how switch happened while I'm describing which lessons should have been learned. It is sad if Python community learned nothing.
> the community opinion seem to be split which certainly harm wayland migration progress.
Developers done great job, you can't run 2.7 code in 3.*, you can run X11 applications in XWayland. Is there a split in developers community? All I see is FUD among users.
[1] https://docs.djangoproject.com/en/3.1/releases/1.5/#python-3...
$ sudo pacman -Rs xorg-server-xwayland
From what i understand there are commits, just not releases. What is the point of committing if the maintainers do not bother to make a proper release that your work can be distributed to the users?
[1] https://github.com/freedesktop/xorg-xserver/graphs/commit-ac...
So why aren't release being made?
> The primary development code repository can be found at:
> https://gitlab.freedesktop.org/xorg/xserver
Quite a lot of issues.
[0] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1092
> Xorg xserver above 1.20.8-3 crashes when using displaylink/evdi
> Applications do not repaint in a timely fashion, resulting in screen corruption
> xorg-x11-server quit unexpectedly on windows resize
> x11-base/xorg-server-1.20.8-r1 crashes
> Xorg crashes after unlocking with lightdm
> Input events can be sent for disabled device, crashing GTK and mutter
> when ubuntu runing Virtualbox, Ctal+Alt+F1 Ctal+Alt+F17 switch cause memleak
> Server crash at startup
> Delay and black screen when the screen is rotated.
> xorg-server-1.20.9 crash on startup
Strange point, it should have been burned 10 years ago than. I use X.Org, works perfectly in Arch Linux, some claim problems on in their distribution. It should be critique of that distribution.
> Chromium is making its first shy bumbling steps towards actually working on Wayland
And Firefox support is behind MOZ_ENABLE_WAYLAND=1 flag. Clearly Wayland is in "early adopters" stage. Early adopters should not whine.
> By the same logic, anyone can say that the direction they're taking is bad.
You've clearly not watched presentation. Some people know better than developer of that technology. It would be insult on my job. I've had enough people stating "technical debt is not real".
> Dear Google Cloud: Your Deprecation Policy Is Killing You
Open source is nothing like Google deprecating its services, anyone can run code, but it is naive to expect free indefinite support.
Truth is you are not going to maintain X.Org.
yes.
Surely that fulfills both contribution and prediction.
I therefore disagree with your characterization.
Now, he appears to have been wrong, but just like preachers may be wrong, critics may also be right even without contribution.
He knew Bible and he was right by his interpretation of Bible. In programming world word is reality, there is only one meaning. Those who know word forge reality. This requires knowledge.
Critics who do not posses knowledge appeal to emotions, spread FUD. They may be right by coincidence like standing clocks.
Because I think you used it wrong.
I've described context. You've confirmed it. Statement supported not by fact but by inner voice. My morale stems from Christianity, I believe Enlightenment got it right — discovery of nature is discovery of God. I've been to church, I've seen priest who shared joy. I've seen other priests, I would rather not see them.
X.Org developer described what's wrong with the project [1]. Not one of the Wayland critiques addressed his points. They have no facts, they just want it to fail. Those who work hard and share for free get anger in return. Sway / wlroots maintainer (ddevault) got off the edge from this misinformation and I do not agree with him but I am not maintainer either. Where is love and God in this story?
> That’s not even considering any personal goals, which I have vanishingly little time for. I get zero exercise, and though my diet is mostly reasonable the majority of it is delivery unless I get the odd 2 hours to visit the grocery store. That is, unless I want to spend those 2 hours with my friends, which means it’s back to delivery. My dating life is almost nonexistent. I want to spend more time studying Japanese, but it’s either that or keeping up with my leisure reading. Lofty goals of also studying Chinese or Arabic are but dust in the wind. I’m addicted to caffeine, again.
> Less healthy ways have included walking to the corner store to buy unhealthy comfort foods, consuming alcohol or weed too much or too often, getting in stupid internet arguments, being mean to my friends and colleagues, and googling myself to read negative comments. [3]
That's story behind Linux infrastructure. Because of such work I have Linux and I am grateful for it, but no mob wants to finish them.
[1] https://www.youtube.com/watch?v=GWQh_DmDLKQ
[2] https://news.ycombinator.com/item?id=24896917
[3] https://drewdevault.com/2020/01/21/Stress-and-happiness.html
Which is why I think it's the wrong term, and why utxaa was confused.
Your link to Google for a dictionary definition says:
1) deliver a sermon or religious address to an assembled group of people, typically in church.
This wasn't a sermon or religious address, and HN isn't church.
2) publicly proclaim or teach (a religious message or belief).
Okay, so posting a comment on HN is public, which means we're all preaching? This doesn't seem what you mean.
3) earnestly advocate (a belief or course of action).
This is the closest. However, "this is all going to end in X12" seem far from earnest advocacy.
Your own comments seem far more earnest - are you not also preaching?
It's far easier for me to believe you simply used the wrong term.
sure pal, you got it.
I do browser-based screensharing (of both individual windows and the whole screen), I have a mixed DPI monitor setup, I've played games on Steam, &c. I need no workarounds. GNOME just works.
About the only things I don't use are nvidia's crappy drivers.
Hope it works out for you.
GamingOnLinux stats — AMD GPU 40% and raising.
https://www.gamingonlinux.com/index.php?module=statistics&vi...
Anyone who wants stable, performant GPU today can buy AMD. Future is here. That's Wayland target.
I live in the past — Intel GPU, X.Org, xmonad. I've thought to wait a few more years but I've checked Sway, it works. I'll check waymonad, maybe it works, maybe I'll make it work.
Wayland GNOME and KDE works with NVIDIA.
1. Gaming. Just about nobody games on Linux with nVidia. Most people I know who game (from Linux) with nVidia GPUs use PCI passthrough to a guest VM running Windows. Very few use nVidia GPUs on their host system. My primary setup is a 2950x/128GB DDR4/Vega 56/2080 Super -- the latter goes to kvm exclusively.
2. "Research" such as machine learning. You don't need Wayland or X11 for this, and the proprietary drivers work the best. To be honest, this is a space where Ubuntu Server performs best. I keep one of these around in a VM (see above) for this purpose. (Mining also goes in this category)
Everything else can probably be done with an Intel or AMD GPU tbh.
I guess I'm the oddball here. 95% of my gaming is native Steam Linux apps on my Kubuntu box with a GTX1060 6GB.
I've been using Wayland for years now and it works great. The one and only thing I use X for is OBS studio because they're still working out the window capture stuff, which BTW mean poking the right hole through security that X doesnt even have.
Most the things that don't work well on Wayland are old junk.
There is IIRC some chrome setting that fixes this, but it doesn’t help with chrome-based electron apps that don’t expose the internal settings (like Slack).
It took the X window system 30-ish years to get where it is today. Wayland only had 11 years, yet it is already better than X in many aspects.
Except that X11 is NOT "mostly working" for a significant amount of modern usages.
Yes, if you happen to want to run your Terminal, Emacs, etc. remotely over a network connection, X11 is your huckleberry--but only because anything more complicated than a bitmap makes that a very difficult problem.
If you want HiDPI, subpixel anti-aliasing, color calibration, multiple resolutions on multiple displays, smooth video, no tearing, etc. X11 only works to a certain degree, some days, for some people, for some video cards. And it's not even clear how those should work over a network connection.
This is not new. After all, X11 critiques came in for a full chapter in the Unix Haters Handbook and that's 25 years old. Wayland is simply revisiting the same problems as X Server Extensions 30 years later (they aren't ubiquitous so nobody uses them so they aren't ubiquitous).
The problem is that people who use obscure features are VERY vocal about it while people who simply abandon your operating system because accelerated video doesn't work reliably are very quiet.
Maybe Wayland isn't the way forward, but X11 certainly hasn't been the way forward for decades.
The only advantage I can see is that if Wayland manages to tear out the X11-isms in everybody, what comes after Wayland will have a lot easier time of it.
Every single thing you've mentioned can be fixed with Xorg/X11.
(except subpixel antialiasing because that already existed for a long time, i'm not sure what you refer to)
Then why hasn't it been fixed?
In open source, those who make the code get to make the decisions--for better or for worse.
My personal opinion as to why X11 gets so few contributors--the build system is so terrible that nobody wants to touch it anymore. I suspect they would get a lot more contributors if they changed to something like meson/ninja which doesn't need to recompile the universe to be correct.
Are you referring to something else?
And I still see autogen.sh and Makefile.am goop in the top level of that repository.
However, I would be quite happy to be wrong.
I don't know, my guess is that people found making new stuff much more fun than fixing existing stuff.
Which is fine.
However that isn't the same as the existing stuff being unable to be fixed.
Cases in point: this project, https://github.com/const-me/Vrmac/ a non-trivial demo such as 3D teapot or 2D tiger.
Run that in desktop, and you’ll see occasional tearing.
Run the same demo on top of bare OS kernel (i.e. reboot to console), and it will work flawlessly on top of DRM/KMS, on the same Raspberry Pi4.
We had XV, RandR, antiaiasing and color managers with smooth video and no tearing since early 2000's. WTF are you talking about?
It's like saying "Imagine if all the time you, a software engineer, spent on taking care of your child was spent on making a graphical server". Sure, but I don't want to make a graphical server, I want to turn people into dinosaurs.
We aren't talking about hobby work here.
I refuse.
But it bothers me when no clear upgrade path is defined ("drop your stuff" is not acceptable) and a half-hassed incomplete solution is proposed instead, and backwards compatibility is pretty much disregarded.
For what concerns my personal computing, I'll stay on Xorg until XFCE supports Wayland. Then I'll update.
Apple is a multi-trillion dollar company. Microsoft and Google are close behind. Of course they can give away their desktop environment away for free. System76 (et al) can’t compete with that. X.org can’t compete with that.
I mean, this is exactly the reason I use Mac, because it ships with a good DE out of the box supported by a trillion dollar vendor. But that doesn’t help people who prefer Linux.
If it's indeed the LCD and not the backlight, pray tell us the model so we don't end up buying it.
I get it, all these features that used to just be supported by the one Xorg server now need to be supported by individual compositors - but still, it is simply misinformation that "Wayland" is broken because Mutter / Kwin / Sway are incomplete.
A protocol with zero practical implementations is, in practice, broken.
You know, catch up to what literally everything else is doing. Windows, MacOS, iOS, Android, etc.. are all exclusively compositor-based window management systems. And they don't have latency issues, as ways to avoid what little latency compositing adds can be avoided in cases when necessary, like front buffer rendering extensions on Android for VR. Literally only X remains stuck in the 90s.
Wayland compositors provide backwards compatibility with most X11 apps via XWayland, I don't think it's fair to say that they completely disregard compatibility
That's disregard for backwards compatibility to me.
edit: which is not to shit on wayland itself, it's to complain about the general attitude which is like "just don't do that" or "oh that's old, we don't support that"
I've actually used waypipe more often in the last year than I ever used ssh -X, thanks to a shift towards WFH :P It's sometimes useful to be able to run Firefox remotely from my workstation at the office.
It's supposed to fail hard. That isnt just a security hole in X, it's a total lack of security. The notion that any app should be able to monitor or manipulate any other app is archaic and wrong from a security perspective.
That "security" is useless on a Desktop where you run all programs as the same user. If you want a platform to run locked down "apps" that's fine, just don't expect others to be happy with the cost of that "security" when it provides no benefit for them.
Multiscreen is Xorg is kinda mushy so I thought maybe Wayland fixes it, but no it doesn't.
Wayland is now 12 years old and everything is still half-baked.
It quotes an intel developer saying they don't want to do any more stuff on Xorg. But the reality is that as much as I admire intels open source contributions. I don't remember a time where all the features in the Intel driver actually fully worked. But sure, maybe it's an Xorg issue, or they don't know how to do release management.
Either way, Wayland doesn't seem to solve the problems it promised to fix.
Whenever I had a chance to run on nvidia binary drivers, the only things I occasionally missed were some new features, or having to wait a bit longer to update the kernel. Stability was better, drivers more performant, and I don't remember daily fighting with memory leaks.
And X.Org's driver architecture could be replaced completely (in fact, it could be made to run on the same stack as Wayland) - it wouldn't be the first compositing Xserver around, and could use methods that would deal with noticeable to many lag involved in compositor-based UI.
I had a Nvidia Riva TNT2 and later on an Nvidia GeForce. I ran Linux on it.
I had stability issues with the driver, but I solved it the following way: ran one X server with a DE, and another X server with Nvidia's proprietary driver (mostly for games). This way, if I had to kill the X server using Nvidia's driver I didn't lose any work.
If that wasn't enough, all the bloody time there were massive security problems found in Nvidia's proprietary driver. I don't know if that is still the case, cause I switched away to ATi in the 00s, and Intel graphics cards + ThinkPad as laptop. ATi/AMD has come a long way ever since. Their FOSS drivers are stable, and they deliver (see various Phoronix benchmarks).
Many distros do this already. Both for graphics drivers (xf86-video-modesetting) and input drivers (xorg-input-libinput)
There's glamor, but AFAIK it's not as tested as it should, and is still shoehorned into old model.
An example of not following the old model is Xsgi, which was (hw) compositing and quite ingenious in many ways.
Which compositor do you use?
There have been 3 issues I've had regarding it, 2 I'd call minor:
- I haven't found a way to rearrange external displays, though it is theoretically supported
- After a bug in my TV switching to the lowest possible resolution through switching the input in home assistant it would not work with 4K again until after a complete reboot (so it may not even be a wlroots issue)
- XWayland apps are unresponsive in the upper half of the second screen (4K at 1x scaling)
Using mostly native Wayland apps neither of these have been deal breakers for me. Something under-discussed is that virtual desktops are per-screen, which I find quite cool.
So that's my adventure with Wayfire, but I would assume that Gnome and KDE have perfected multi-screen usage on and off of Wayland by now.
[0]: https://wayfire.org/
Seems to be a bit of a dealbreaker for people who want to use 100 percent of their screen instead of only 75 percent.
Also, is there a chance your 4K screen has negative coordinates? It is well known that Xwayland does not react if an output has negative coordinates (or at least partly negative coordinates).
Right now there’s a bunch of competing compositors with different use-cases but nothing says it has to be true forever.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.9...
SunOS 4.0 lists "dynamic linking" as new feature, released 1988
https://en.wikipedia.org/wiki/SunOS
AT&T System V Release 3 got shared libraries in 1986
https://en.wikipedia.org/wiki/System_V_Release_4#SVR3
While the first X11 release was in 1987, the fundamental architecture was designed already since 1984, and this architecture includes a heavyweight server that implements things that in most other window systems are done client-side.
Nothing has changed with Wayland except we have a new thing and lots of groups writing compositors. And this is great — Mutter, Kwin, wlroots, Mir — and they will all speak a common protocol for putting stuff on the screen and handing input events. And projects with similar use-cases “desktops” are standardizing on common dbus interfaces for non-display stuff.
This is genuinely so much better than the Xorg monoculture. Wayland’s design has made it possible for lots of different groups to implement display servers and have interoperability because what we had before was “X11 actually means do what Xorg does.”
There’s lots of in-fighting about the scope of Wayland and people that want to make a protocol for putting pixels on the screen also handle “desktop stuff” like audio, screenshots, screen recording, keybindings, input automation, authentication. I think this is misguided because it would effectively turn Wayland into a generic message bus between “apps with windows” and the display server when we already have a generic message bus for every application — dbus.
Right now we have things like:
org.gnome.Shell.Screenshot | org.kde.kwin.Screenshot
org.gnome.Shell.Screencast | org.kde.kwin.Screencast
which after shaking out will be promoted to org.freedesktop.* after standardization. Despite the fact that notifications have been "DE specific" in the same way for years and years nobody seems to complain about org.freedesktop.Notifications.
A protocol definition could cover multi screen support, requiring implementors to do something sane. Of course one of the reasons that Wayland exists was to cut down the bloat X had accumulated over the years. Given that it is rather surprising that the Wayland spec isn't just an empty page.
I use Wayland daily and have for a few years. It’s clearly gotten better, and I rarely encounter problems. I do have my load of applications still running in XWayland though.
But yes. Support for varying DPI in my multi-monitor setup is handled much better on Wayland than on X11. I would say much better than on Windows too.
Also, can you use xdotool for key input redirection or screen capture programs and stuff yet?
Not sure what you're talking about. Haven't noticed any adverse negative effects.
It's super nice to have a desktop without any tearing though.
> I assume all games run XWayland, which makes it a non-issue.
I don't do PC-gaming.
> Also, can you use xdotool for key input redirection
Not sure what xdotool is.
I'm using sway[1] with libinput. I haven't had a need to use external tools beyond what they support natively.
> or screen capture programs and stuff yet?
I have no issues to do screenshots ad-hoc (in fact, I have keybindings to do this, and throw it right in the wayland clipboard).
I do notice that most Xwayland-based programs which tries to do screen-sharing fails spectacularly though.
I check the state of the linux world about once a year still. And obviously keep using it on the servers.
Best of luck to everyone using it for desktop. I totally get why you do it, but it's just not for me right now.
There is nothing so special going on in Fedora that can’t be done in other distros. Try an Arch based Linux desktop. You’ll get newer packages and better package management. Manjaro has worked well for me.
You either fix them yourself and contribute back if possible. Or switch to distribution where someone still fixes these issues.
I've investigated X.Org caused bug just for two days and since then totally support Wayland development. What we have today is not healthy.
The wayland people replaced that with a half-baked solution because they insisted on boiling the ocean - replacing the entire thing in one go, instead of working piecemeal (which the X protocol was explicitly designed to allow).
Which is a great pity, because now the day of the Linux Desktop is even further off.
> instead of working piecemeal
That's exactly what happened. Do you remember fonts without anti-aliasing? Run xfontsel, that's X11 fonts rendering. Freetype, Fontconfig, Cairo, Pango, HarfBuzz work on client side and push pixels to X Server. Entire rendering model changed, X.Org become compositor. They've faced limits, they've implemented DRI, DRI2 [1].
Now developers decided to make good compositor. And they've done it without disturbing X11 ecosystem, with clean way to port toolkits. Window Managers can't be ported but they can be reimplemented, just look how many compositors people built [2]. It is a miracle.
Linux future is bright. Video drivers moved from X Server to kernel, display configuration parts replaced by KMS, we've got modern font rendering, text shaping, we've got open source AMD GPU driver!
I still use Intel GPU, X.Org and xmonad, but the times they are a changing.
[1] https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructur...
On a 200 dpi display the xfontsel display looks better. :)
The irony.
I run one, which is why to me the irony feels reversed to what you probably meant. It's clumsy, slow and tedious to setup.
X11 problems explained by Daniel Stone [1]. As I understand there are two parallel architectures, one uses X11 server primitives (xfontsel), another renders on client (fontconfig fc-list etc). It is very confusing.
[1] https://github.com/ianyh/Amethyst [2] https://github.com/koekeishiya/yabai [3] https://github.com/Hammerspoon/hammerspoon
Upgrades often break things, I'm forced to use brew to install software which leaves files strewn around the file system and regularly seems to have cross package conflicts.
And don't get me started on the hardware - the laptop is excessively heavy and the keyboard is awful (and I don't just mean the touch bar gimmick).
My personal laptop is a Lenovo Carbon X1 and Fedora runs very nicely on it, requiring very little thought put into management if you're running the default desktop (Gnome). I can update the firmware and BIOS from inside Linux, and Lenovo have even started shipping newer versions of the laptop with Fedora pre-installed.
There's massive scope of tinkering with Linux if you want to, but as long as you're careful with the hardware you buy there's absolutely no need to tinker at all if you don't want to.
Open source I know is often a work of love, but it's a bit painful that everyone is chasing after new things instead of keeping things that already work working. It's like how there are dozens of js frameworks that have thousands of contributors whereas openssl had one which lead to the infamous heartbleed bug. We need to talk about how the culture of open source is broken in this regard and figure out how to fix it.
I agree that this is not good overall, but it's going to be very hard to convince people to work on not-fun things for free. Some might see it more akin to volunteer work, but the amount of people willing to do this are far outnumbered by the people simply doing things for fun. Too be fair, it is at least pretty great in so far as that they're doing open-source work :)
Maybe it's time for people to stop whining in the internet and start writing code?
X.org code is there, support it, contribute to it, improve it if you want to.
> infamous heartbleed bug
Yeah. Because real open source is like that: millions are arguing in forums, few write code.
And that's the problem Wayland is trying to solve BTW, by removing quite a lot of obscure legacy which only a few properly understand.
Writing things from scratch is usually good, it allows:
1) To follow modern practices so modern devs can understand the code and contribute
2) To use modern languages and technologies which are inherently more safe and secure (due to better type systems, linters, language design)
3) To get rid of technical debt
Joel Spolsky wrote a good argument to the contrary: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Any good examples of large projects where a rewrite from scratch has been good?
This is ridiculous. Maybe that's applicable in a very short timescale, but definitely not to the protocol which appeared in 1984.
There is a thing called progress, people invent quite a lot through the years: type systems, patterns, design ideas. Not to mention that hardware has changed quite a lot through the years: X11 was done in the age of terminals and absence of hardware acceleration.
IRIX, OpenGL.
They invented it.
Technical debt i.e. "code that should be refactored, because it was originally implemented in a hurry"? Yes, technically you're right and deleting all of the code is a way to also get rid of the code that should be refactored.
The same way whole-limb amputation is a very effective way to remove nail polish.
More like fundamental design decisions and API's which you can't refactor without breaking compatibility.
This is not true. Developers have been working actively on Xwayland, and I believe it can run most of the applications now, even with hardware acceleration. Is that not a clear upgrade path for you?
> Furthermore, there isn’t a standard API for getting screen shots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so.
An xdotool (an input event automation tool, imagine wanting to inject or intercept input events) replacement is not possible on Wayland (without having separate support for each compositor, of course). These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile), this[0] Reddit comment puts it nicely:
> It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. But for some reason we absolutely need this technology on the desktop, like we had not enough pain and lose ends over here without it.
But the lack of these features AFAIK also causes big trouble for users with special accessibility needs. Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games.
[0] https://www.reddit.com/r/linux/comments/7lb5l7/new_screensho...
https://www.gamingonlinux.com/articles/gnomes-mutter-gets-fu...
Does Wayland support this?
At least if this helps to reduce fragmentation, so that we can have a decent desktop environment, instead of 4.000 half backed ones, could be something positive for Linux.
The lack of a common screenshot protocol isn't related to security. The desktops just haven't been able to agree on a common protocol (yet?)
...and that's unlikely to improve much any time soon, since, according to ydotool's README:
"Since Jun, 2019, I have little time to maintain this project"
I understand you probably don't want to do that because you're fine with xdotool for now, but the options are there should you need them.
Either way, ydotool is clearly not a viable replacement for xdotool right now, if it will ever be.
Also, you're wrong that this isn't related to security, I can't be bothered to dig up some quotes right now, but it is/was actually very common to explain the lack of a screenshot feature on Wayland with security, and even to dismiss the feature altogether as a security issue.
I don't know who was painting it as a security issue but they're mostly wrong. The security issue is in restricting use of those capabilities to only privileged applications. Maybe other (embedded?) compositors left that out entirely for security reasons, but GNOME and KDE always had plans to include screenshots, and wlroots has it too. Weston even had its screenshooter protocol for a while now but the other desktops decided not to use it and went their own way, for various reasons. (Full-featured screen capture is actually not as simple as you'd think, and it gets messier when pipewire and zero-copy capturing are on the table)
Edit: Check here for some background https://gitlab.freedesktop.org/wayland/wayland/-/issues/32
It's really super useful being able to just fire up a program on a remote SSH session and get the window on my local computer. Without having to set up VNC and a window manager etc etc on the remote computer.
Of course this feature also needs a big review. It needs proper security (though tunneling over SSH fixes a lot of that) and there's too many back-and-forths in the protocol leading to it being really sluggish over high-latency connections. Makes sense as it was mainly invented for X-terminals on a local network. Also, more and more features like fonts are now rendered remotely instead of locally on the user's computer (the server in X terminology). NX and X2go fix that mostly but it would be great to have this in the actual protocol. As well as provisions for smooth video streaming.
As well as that, the whole computing industry is moving back from powerful endpoints (PCs) to powerful central computing (now cloud, the mainframes/powerful unix servers in the early days of X). So really, this feature will become more important again.
But yeah I would really prefer to see X11 being brought up to date rather than Wayland. Wayland is focused way too much on the local desktop.
I'm just advocating a modernised X over moving to Wayland altogether, like the poster I replied to.
Trouble is, that security model makes no sense on today's desktop. In 2020, people aren't downloading and running native applications on desktops, not even (especially?) on Linux. The desktop is now solely a manager of browser windows. Everything that normal folks do is done through the browser, from email to office collaboration. Maybe a few Electron apps sprinkled in (mostly targeted for developers, ironically). Maybe the calculator? That's pretty much it.
The most important desktop apps today? Chrome and Zoom. Both which barely work in Wayland. But at least all that non-existent native desktop software can't now spy on my web mail? Too bad screen sharing is now a complete shitshow.
Actually worthwhile problems to solve on the desktop are for example high DPI and fractional scaling, rock-solid multi-monitor support, dynamically plugging in and removing displays, mixing displays of varying DPIs, high refresh rates and variable sync etc. The desktop will increasingly become a niche for high-end developer setups.
No, we download and run them in our web browsers because the operating systems (and X11) failed to implement security models that fit the modern world. Wayland is a move in the right direction here.
At least some users disagree. Flatpak and snap run applications in sandbox. I am to used for open source software, I fear installing closed source like Opera, MS Edge (not supported on Linux yet), Steam. And Steam with Proton is the next thing to bring Linux on the desktop.
Why are you comparing X11 and Wayland?
If something does not work on X.Org we are better with another project than with nothing. If Chrome and Zoom work on X.Org stick to it.
That's an unnecessarily abrasive view: the Wayland protocol designers do not hate power users. But allowing programs to constantly take in arbitrary input & output information in the background, as well as simulate arbitrary input to other programs, is an obvious and glaring security flaw. Unfortunately, that forbids general-purpose screenshotting and key-rebinding programs - but there is no sensible middle ground.
>Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them.
I appreciate that the average HN poster, and to a lesser extent the average Linux user, does not do this - but many, many Windows users do. In order to actually break into a mass desktop market, there has to be consideration of the ways people who do not currently use Linux behave.
I would even argue that lots of current Linux users are guilty of this - how many Arch users are checking the contents of PKGBUILDs from the AUR? How many Linux users, when searching for the solution to some problem with their desktop, have blindly copy-pasted commands from some support post - or worse still, just downloaded a "fix it" script to run?
Wayland is built on sane assumptions, because it also aims to cater to a not-insignificant part of the desktop market. That the response of an X11 supporter is "simply run the correct programs" show how little they have understood the goals and successes of Wayland as a project. It is not X12, and some of us are grateful for that.
For the life of me I can't understand why so many people are always convinced that people who develop replacements for decades old frameworks do it only to spite users.
But the answer is: X sucks. It's 36 year old software with dozens of extensions. No one wants to write software that uses X, and apparently, per this HN submission, no one wants to maintain X.
I don't understand where you are going with your first paragraph, except that you are assuming things about others that you should not. Similarly with the second paragraph.
>> "userhostile"
https://www.google.com/search?q=sway+screenshot
http://sergeykish.com/sway-grim.png
less than a minute. And it is second time in decade I've tried Wayland.
>>> why is it being marketed as a X11 replacement? Why is there a constant FUD-included push to dissmis Xorg in favor of Wayland compositors?
>> "FUD"
> Wayland is intended as a simpler replacement for X, easier to develop and maintain. [1]
"Intended" is not "ready". Could please cite your claims?
> replacing X with Wayland
Would you prefer if X.Org developers just abandoned it? We would have "X.Org is Abandonware" ten years ago.
And it is not zero sum game. These are different projects. People tried to fix X and failed. No one on this thread is going to maintain X.Org. But hope is not lost — another project have risen to maturity in last ten years. It covers some use cases and now you are bashing it because it is not perfect.
All of it while X.Org still works and I use it every day.
Unfortunately, this makes it unusable for 98% of the population. Wayland also breaks screen sharing programs, which are essential for most, especially now during COVID.
Of course there's a middle ground: require special permission for programs that wish to do those things. For example, macOS has permission prompts for "[Application] would like to record this computer's screen." and "[Application] would like to control this computer using accessibility features."
Oddly, the actual mass market desktops have (and have had for a long time) solutions for the 'general-purpose screenshotting and key-rebinding programs'.
I know how bad was X11 technically, and sympathize with replacing it - but that by itself does not make Wayland a success. It took Wayland over a decade to almost get basic capabilities, and it's going to take another decade until all the compositor-based protocols are standardized (probably by eventually only having a single compositor implementation). By the time Linux finishes reimplementing its desktop, Windows and MacOS will be in an entirely different place.
Maybe this can't be helped - Open Source desktop development was always extremely underfunded and undersupported.
I'd just like to note explicity that this would probably be a compositor that tries to cater to only 80% of users (if that), with the rest of us being told to fuck off.
Restricting Wayland feature makes sense if other permission is also restricted like Android. But it's a Linux Desktop that can easily run/install anything with `sudo`. Wayland should support advanced features.
Without this, you will forever be incalculably behind the proprietary OSes and the original X server. Perhaps you're happy in that corner, great! That puts you and whoever else exists there in the same conceptual space where everyone else with impractical and unreasonable restraints on their software lives.
That's a fine space to be in, but you don't get to say that it's the "correct" choice for the average user. It's the wrong choice, because it puts the Linux ecosystem at a permanent usability disadvantage. Instead of going with this "no you can't have it" approach, it would have been entirely reasonable to go with something permissions-based (perhaps even with a default that says it won't happen). Instead, we're stuck with one part of the community yelling that this is what everyone should want and everyone else trying their hardest to ignore them. It's an unhealthy situation for everyone.
>> That's an unnecessarily abrasive view: the Wayland protocol designers do not hate power users.
For the sake of civility and discourse I just want to point out the quote you're responding to does not talk about hating power users. The OP clearly just says that the "decision [is] power-user hostile." That's an important difference, as one is talking about substance (i.e. the decisions) and the other is veering into personal attacks. It's easy to conflate the two and I've certainly done it, but I just wanted to point it out to try and de-escalate the conversation a bit.
I also think it's reasonable to say that many security decisions in many contexts are "user hostile." Hostile design is an actual thing, where security and order are prioritized above convenience and functionality, and not simply an attack on "bad design"[0]. This is not to say all user hostile decisions are bad, but it's a trade-off. Asking for your password before every single interaction is user hostile (the user will never get in the flow[1]), but could be the right decision in certain contexts.
Funny, Android has had screenshots for a decade.
This is a fair criticism. It is true that we see each of the compositors rolling its own extensions to the protocol. But I believe wayland is trying to standardize a lot of the protocols which should cover common use cases.
> each new compositor implementation reinvents the wheel many times
This is not true. There are libraries like wlroots[0] which you can build on top of. You don't have to redo the work that is already done in other compositors.
> application that needs to grab the entire screen will need separate code for each compositor it supports screenshots
There is the PipeWire[1] effort to support screenshot and screen capture on wayland in a unified way.
> Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games.
Also not true. On a properly implemented compositor, video games frames shouldn't have longer latency to screen than on Xorg. X server has to do composition too, whether you run a compositor or not.
[0]: https://github.com/swaywm/wlroots [1]: https://en.wikipedia.org/wiki/PipeWire
X works perfectly for me, and there is nothing I would want it to do that it doesn't do now. Why should it change?
I have many programs I wrote years ago that I don't change and I use every day. Constant changes are not a measure of utility.
But again and again, you'll find users looking at repositories and deciding that something is "dead" because there isn't any recent commit, often blaming developers for not doing more free work for them. This is a toxic attitude. When we have a software that works well and solves our problems, we should celebrate it, not complain it doesn't find new problems to solve.
It wouldn't be that often, though. And maybe they would actually love to have such heartbeat. I would love to hear a packager on that.
If your objective is to improve security, this is better than getting a version with myriad changes that may introduce new bugs.
I think we could use the terms releasing and maintaining. Constant releases is not the same as constant maintenance. And it is hard to agree that our industry sees that.
By way of analogy, we seem to think we can improve the roads by building new bridges every year.
I'm not sure whether a program that works for you is a good indication that it no longer needs to change.
> When we have a software that works well and solves our problems, we should celebrate it, not complain it doesn't find new problems to solve.
I think anyone can agree that, at the very least, screen tearing and proper support for mixed DPI setups are problems that fall squarely in the responsibilities of X and yet it still didn't manage to solve them after so many years.
So it's hardly the case that X is just so good that users nowadays have to try really hard to find new problems for it to solve.
The X11 protocol is the surface you need to maintain but swapping the internals should be do-able. Maybe we should have some call to action or reverse-auction or something. I'd love to support a viable path forward (I feel this effort would be a bit like neovim).
Personally I think it could start as a Xephyr or Xnest type project (to allow you to run rootless X) and then extend it with a from-scratch protocol that slowly replaces X (starting with support for simple but useful applications and going from there).
But clearly I only barely know what I'm talking about. Probably the reason things are the way they are is because of how the whole OpenGL / Vulcan etc. thing is not resolved, so any potential replacement has no foundation to build on (but this is something I don't know anything about).
With this kind of FUD, it is no wonder Linux has a hard time being accepted on the desktop. What enterprises -- and everyday developers like me -- need, is a stable desktop to run IDEs and the like. As an example, Debian with Xorg has been fantastic for me for several years for JetBrains tools and GSuite for mail and docs, which is a pretty complete setup, and in the WFH era, Zoom and Teams just work. This is what we should be striving for -- boring, predictable, reliability, not juggling with chainsaws on the bleeding edge.
X11 comes from a different time, but any successor must be worthy, not just have a different approach. It's also worth remembering that much of Windows' practical longevity is due to its backwards compatibility. It's not shiny, but it works, and that begets loyalty.
Sure - great opinion - but doesn't change the state of the world, which is that X.org is unmaintained and all the real development firepower has moved on to Wayland.
We can all have opinions and I kind of agree with yours, but the article is about the realities of life and facts which we need to accept.
Fact is the people who developed X thought through multi user graphical computing.
That process has not really happened since.
It needs to, or we just won't see desktop Linux compete.
When the thinking it through gets done, the result is powerful.
We have a 30+ year legacy of using X11. I know the CADT development model doesn't care about that. But all the people using X11-based applications do care. We aren't going to move off X11 on the whim of people who care more about "the new shiny" than they do about the real-world needs of people who use this stuff to run their businesses.
These people have done more to destroy the viability of Linux as a desktop platform over the last 15 years than anything else.
* Tiny X (Still Xorg just barebones and faster) - https://github.com/tinycorelinux/tinyx
* Xynth - https://github.com/alperakcan/xynth
* Nano-X / MicroWindows - http://microwindows.org/ (Seems still active? Just needs some modern GUI ports.)
* DirectFB (Needs modern driver support) - https://web.archive.org/web/20120118003245/http://www.direct...
* SVGALib (Needs modern driver support) - https://github.com/akosela/svgalib
* FBUI (Needs porting to modern kernels) - https://github.com/8l/fbui
Probably not, because:
> Design choices [...] no gl
But most of this stuff is basically irrelevant in a post-KMS/DRM linux world.
So few apps were ever written targeting directfb and libggi it's as if they never existed.
SVGAlib apps frequently performed direct hardware access requiring root and disrupting graphics hardware state WRT other graphical apps like X or fb. Unfortunately we have a significant collection of old demos and games targeting SVGAlib, but at this point it's probably best to just run them in a virtualized linux environment lacking any graphics drivers so SVGAlib can run the show on a faked VGA. For such apps where source is available, it's better to just port to something like SDL.
Mplayer on the fbdev2 driver works perfectly. So is DirectFB Links.
>Unfortunately we have a significant collection of old demos and games targeting SVGAlib, but at this point it's probably best to just run them in a virtualized linux environment lacking any graphics drivers so SVGAlib can run the show on a faked VGA.
Or a wrapper trapping SVGAlib calls to SDL/SDL2.
That works for programs limiting their operations to SVGAlib calls.
As I mentioned, but you omitted in the citation:
> SVGAlib apps frequently performed direct hardware access requiring root ...
How do you trap those directly accessing VGA IO ports via inb/outb instructions? I clearly recall writing modex routines in assembly for SVGAlib demos, and I'm pretty sure I wasn't the only ex-DOS graphics coder doing that to make things happen on Linux in the 90s.
1) Wayland is really slow. I don't know if it's the compositing or what but it's unusable on lighter hardware that X ran fine on.
2) Widget toolkits handling window decoration is awful. Before the large number of toolkits just meant some controls were a little different but now basic behavior changes based on how programmers decided to build an app. And if you don't like the window decorations (say, they take up too much screen space) your choices are suck it up, or if you're lucky and willing to spend a bunch of time reconfigure every different toolkit your apps use.
3) basic stuff that worked fine on X11 doesn't work on wayland in the name of "security" (screenshots are a big one, there are extensions but isn't that the complaint about X? And if there's a security problem with something isn't hacking around with it because people need it a really strong indication that the idea is broken and probably making the situation worse?)
This is crazy when you think about it. I remember running an X server, Hummingbird I think it was called, on 386 and 486 machines connecting to Suns and it was fine, this was a perfectly acceptable way to work. Couple of xterms, an Emacs, xbiff for email, maybe some xeyes just for fun. Developing with Tcl/Tk and running those applications. Now we have several orders of magnitude more CPU, memory, network and Wayland doesn't even perform as well as that! My mind is truly boggled.
The old core protocol approach extensively used optimized graphic operations on the server side, with clients sending things like "draw me a rectangle/fill a rectangle/draw a bunch of lines" etc. - today you're going to get pretty big bitmap (especially with high dpi).
It's the same problem that mobile devices faced, and is related to a lot of issues on how android devices were "janky" (and related to the various hacks that Apple did to make sure your application wasn't capable of overstressing the early iPhones - cause just displaying basic UI was close to doing that.)
Abstractions piled on top of abstractions. Something that might have been 5 function calls deep on either side with a carefully crafted packet in the middle is now 100s on each side.
We have a culture that prizes programmer happiness above all and this means everyone thinks "this is a mess, I'll put my own layer on top to make it nice, then work above that layer". Repeat 100 times and now you have processors literally 2000 times faster that struggle to even keep up with keypresses. But what noone wants to admit, is that it's messy because the problem domain is messy and sometimes you just have to live with the mess and get some real work done. The programmers of old understood this.
Engineering-wise it's really hard.
Microsoft reworked GPU driver model introducing WDDM. They invented a new user-facing API for that, introducing Direct3D 10. They did that in close collaboration with all 3 GPU vendors. They made user-mode components like desktop compositor itself, dwm.exe, and higher-level libraries to benefit from all that stuff. Initially they were optional things like WPF, Direct2D, DirectWrite, then with Win8 they introduced WinRT later rebranded to UWP. That one is no longer optional and is the only practical way to render "hello world, GUI edition" in modern Windows (possible to do with DirectWrite or legacy GDI but neither of them is practical).
The problem "render nice high-resolution graphics, fast" affects everything, the entire stack. Modern Linux has decent kernel infrastructure (DRM/KMS), but even so, remaining challenges are hard. Linux has less luck with user-facing GPU APIs (Vulkan is not yet universally available, neither is GLES3+ or OpenGL 4.3+). For some GPUs, quality of drivers is less than ideal. OS maintainers oppose stabilizing kernel ABI for drivers. There's no high level GPU-centric graphics libraries, I tried once with moderate success https://github.com/Const-me/Vrmac but that only supports one specific Debian Linux on one specific computer which happens to support GLES 3.1, and some important features are missing e.g. no gradient brushes or stroked pens.
I don't see any large party interested in making that happen. At least not for desktop Linux. Valve started to do relevant things when they thought Windows 10 is going to kill their Steam business model, then it became apparent Microsoft won't make Win10 into an iOS-style walled garden, and they no longer have much motivation.
It's great for the common desktop case.
It's not as great for some other cases in which Linux is the preferred platform (headless servers, repurposed old hardware, etc).
The problem isn't, of course, that there exists a solution for this on Linux. It's that that solution is being pushed as the only one that should be maintained—and thus, exist—going forward.
Also phones and tablets. Also embedded devices who have a GPU + LCD, I have personally shipped Linux firmware where I used NanoVG on top of DRM/KMS to render touch screen GUI. Also for kiosks, cars, smart watches and many other applications.
It’s great everywhere you have a high-resolution screen. And it’s mission-critical for ARM devices who don’t have CPU power to render that screen on CPU, at least not at 60Hz.
> headless servers
Why would you want a GUI there? Even Microsoft has console-only “core” editions of their Windows Server, since 2008. They made it because competition from Linux, who had that from the very beginning and was thus way more suitable for cloud use cases. It still is due to other reasons, but that’s another story.
> It's that that solution is being pushed as the only one that should be maintained—and thus, exist—going forward.
I get why some people would want the X to be maintained, but the thing is, it’s very expensive, and not fun.
Developing game console emulators is expensive, but fun and people do that in their free time with great results. Moving forward GPU-targeted Linux GUI is expensive, not too fun, but there’re commercial applications with healthy profit margins (automotive, embedded, etc) so people from these areas are working on that tech. Patching x.org for repurposed old hardware, on the other hand…
I work on a serious tool, specifically it’s CAM/CAE stuff. Despite Google, Amazon and MS sales people apply pressure to upper management (they want us to move to their clouds and offering gazillions of free compute credits), our software works on desktops and workstations, and I have reasons to believe it gonna stay this way. With recent progress of HPC-targeted CPUs, and steady downward trend of RAM prices, I believe our customers are happier running our software on their own computers, as opposed to someone else’s computers.
> We wouldn’t be rewriting everything in javascript if only we hadn’t forgotten how cool remote X was.
It was cool in the epoch of OpenGL 2. By the time Metal, Direct3D 12, and finally Vulkan arrived, it stopped being cool. Essentially, these APIs were designed to allow apps to saturate PCIe. You can’t transfer that bandwidth over any reasonable network.
Let's be real here - if you're needing something to "just work" you're going to install X. Sorry Wayland, you're just not there yet.
I didn't downvote but it's because parents comment are anecdotal and not providing further data one might be able to engage/confirm/refute ... and therefore I learned nothing from reading it.
I'm also running a dual setup of i3/sway and the only reason why I still keep i3 around is screen-sharing in jitsi and similar. and my experience is that wayland has a lower use of CPU/memory than when running X (i3) but it's not why I prefer sway. (I'm using sway with "xwayland disable" so maybe this is where a lot of resources are saved). But the whole discussion is pointless without verifiable benchmarks.
Another example I like is the Nokia N900, which ran X on a phone no less, phone hardware from 2009, and it was pretty good there.
Part of the problem is surely software bloat over time on higher parts of the stack, rather than X itself. You couldn't get the 486 in the comment above to run recent gnome or a recent browser. But you could run software of the era well.
It works flawlessly if you have a reasonable amount of bandwidth and reasonable latency.
Sure, it doesn’t work over dial-up.
It's also rather complicated to set-up on the server side (xauth, magic cookie, etc).
waypipe, on the other hand, was a breeze to use, even though it's very young. I tried with Firefox and 500Mbps of upload capacity, it worked fine as long as the window wasn't too large.
you mean "ssh -Y user@host..."?
- X forwarding over SSH: this only requires changing X11Forwarding in OpenSSH sshd's config
- Plain X over network, which is secured with `xhost`, insecure, and needs transfering the magic cookie or other authentication information
So, not nearly as complex to setup as I recalled, though it's much simpler to run a nested wayland compositor (which waypipe does) than a X11 server (which xpra does). The difference between X11 and Wayland remote access thins when xpra is involved.
https://stackoverflow.com/questions/37157097/how-does-x11-au...
That should have been 500 kbps
That's the point, X's claimed advantages here long since stopped existing, and nobody noticed because the "inferior" approach is perfectly fine with modern internet connectivity.
That is entirely subjective no? Personally I think Motif is one of the pinnacles of GUI design.
Alas. That isn't the way the world has went, and it's extremely expensive to be weird.
And? Last time I checked, tunneling Wayland over a non-local SSH connection was slow as glass. Which is to say it didn't work at all.
Modern UIs could do with being a bit more like 1995. Most of my work is performance sensitive so the first thing that goes are all the desktop effects that try to barf pointless rainbows and glitter in my direction.
We played videogames on them. Does anybody remember Netrek, Xtanks, and a F16 vs MIG flight simulator which I can't remember the name of?
I think you don't mean that the Wayland protocol forces slowness but that the compositor you used was slow. The one I use is fast.
> And if you don't like the window decorations (say, they take up too much screen space) your choices are suck it up, or if you're lucky and willing to spend a bunch of time reconfigure every different toolkit your apps use.
No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say.
> basic stuff that worked fine on X11 doesn't work on wayland in the name of "security"
On only the core Wayland protocols you're absolutely correct, you can't even implement desktop shells with those. This means there must be extensions and there are 3 different classes: KDE, GNOME, wlroots, with tools for and incompatibility between each. The wlroots extensions are designed to be accepted into the standard and for wider Wayland acceptance they probably should be.
Screen sharing is still a particular issue that we are starting to see solved with the advent of Pipewire.
Wayland desktops are definitely usable. I've been happy with a wlroots based one (Wayfire) for a few months and KDE before that (from what I see GNOME has been perfect for a while).
One of the last standing real issues I'm facing is kerfuffle with Nvidia drivers, especially the ones paired with Intel GPUs, but I think (surprisingly) Nvidia are actually working on fixing that.
The compositor can implement that protocol and just respond with "this compositor doesn't support SSDs". GNOME does this, so all toolkits must use CSDs if they wanna work on the most popular Wayland compositor.
Incidentally, that's hell for all the simple libraries out there which just exist to get a GL window on the screen. GLFW, GLEW, SDL, etc. all have to implement CSDs now if they wanna work with Wayland. It also means that it's no longer feasible to just make a Linux application which uses the windowing system directly; everything must use a huge toolkit now.
EDIT: To clarify, I don't think this is an issue with Wayland, but with GNOME. There's no reason it couldn't have supported SSDs like every other Wayland compositor. But as it stands, it hurts the Wayland ecosystem.
The way GNOME is built it's not really possible architecturally for them to support SSDs in Wayland. Maybe that will change if they ever get around to redesigning mutter and gnome-shell, but I wouldn't wait for it.
And please don't exaggerate, non-GTK applications do work in GNOME. Qt5 has native CSDs that will show up in GNOME. If the application is a game or something that doesn't support CSD then the experience is somewhat degraded but they still work. You can resize and move any window by holding Super and Left/Middle clicking. I won't pretend the situation is ideal but I also don't believe it's totally unusable or on a bad trajectory at the moment—like I said the other libraries are working on getting CSD support too.
Gnome could stop being unreasonably obstructionist, but that indeed seems unlikely.
That's just one example, but GNOME has a reputation for not respecting Linux desktop diversity for a reason.
But in any case I don't understand what is contentious about that. Some pieces are shared between GNOME and XFCE, but a lot of pieces are different and applications have always needed to choose. If they weren't trying to be different they wouldn't have made a separate desktop environment with their own separate libxfce libraries and components. (To GNOME's credit, they have gotten rid of most of the "libgnome" things since then, but now an application that wants to speak to certain GNOME-specific pieces is usually expected to use their private dbus protocols, things that XFCE would never implement anyway)
Incorrect. I am using a single example to illustrate a trend. A single example to illustrate what "unreasonably obstructionist" looks like. That particular incident made everybody roll their eyes but it hardly surprised anybody because GNOME has earned this reputation. Even back then nobody was particularly surprised by the GNOME arrogance, and I've not seen this change.
(Also, maybe I'm getting old but 10 years ago really isn't that long ago.)
If you're trying to illustrate the trend that GNOME and XFCE (and KDE, and LXQT, and MATE, and Budgie, and Mint...) all have different goals and ideas for how applications should behave then yes, I would say that much is obvious by now, and it has only gotten more obvious over the last few years. If you have a technical solution to this then I'd love to hear it, but aside from that I don't care to bicker about whose fault it is that your applications broke, because honestly no answer is going to pleasing for you to hear. Unless I'm mistaken then we aren't paying customers, this is all just random no-warranty open source and there's no support hotline that's going to care about what's broken.
I'm not trying to dispel any perceptions either, if you have a deep seated belief that GNOME (or XFCE, or anything really) are "not playing nice" because they removed features from upstream, there's nothing I can really say to you to change that view. If you want to challenge your own perceptions, I'd suggest you start developing a new open source desktop and application platform yourself over a period of many years just to see how much work it is, and how it's practically impossible to support everything that every app developer asks for when none of them are paying you a cent.
I honestly don't understand what you're talking about here? If you want to get a window on the screen with OpenGL or Vulkan you don't implement anything special for Wayland.
In fact with Vulkan+Wayland, it's fairly easy to do it without any third-party dependencies, with OpenGL you'll probably need EGL which is a Khronos dependency. Here's some slightly outdated example code [1].
[1] https://gist.github.com/Miouyouyou/ca15af1c7f2696f66b0e01305...
Possibly this is a subtle distinction, but I do think it matters.
[1] https://github.com/wayland-project/wayland-protocols/blob/ma...
Go ahead and make a basic Wayland window in GNOME. Compare the user experience to KDE or Sway.
I was objecting to the fact that you said that windows did not have this capability without the server-side extensions, whereas I think they can be through configure. I did not dispute whether sway had server-side decorations or not.
wlroots performed very poorly on my i5-3427U with 4000 series iGPU. Very poorly. I ended up using neither X nor Wayland and instead having mpv render straight to the frame buffer (--vo=gpu --gpu-context=drm)
X.org, Firefox, and Xterm all work very well on it though. As do other apps like gschem and openscad.
I have to wonder if this is distribution dependent? On Manjaro my experience with Wayland has been fantastic. I cannot perceive any speed differences vs X.org; Wayland just flies.
It would be interesting to poll users and see just what factors are contributing to speed issues. GPU? CPU? Distribution? Wlroots vs Gnome? etc. Learning more about what users experience could be helpful in making Wayland better. Has anyone done this?
* Both Ubuntu and Arch based distro 40%
* Manjaro helped a lot 15%
* Both AMD and Intel 50%
* AMD GPU 40% and rising
* Open source GPU driver 43% (almost all of it AMD)
* 10% own VR Headset
[1] https://www.gamingonlinux.com/index.php?module=statistics&vi...
To be able to maximize vncviewer you do need a compositor running under Xephyr too. I picked i3 to be the most minimal. Again, i3 can be told to run in the Xephyr window by setting `DISPLAY`.
One caveat is that I still use Teams under Wayland to join calls for the audio, so this setup means I need two Teams instances to join the same call. This works for meetings but not for individual calls. Of course if you want to use the Xephyr'd Teams to do audio too there shouldn't be any problem; I just prefer having easy access to the Teams window to mute myself, etc instead of having to reach into the Xephyr window and unmaximize the vncviewer window.
People on the #sway IRC channel on Freenode suggested an alternative might be to use v4l2loopback to create a "camera" device that is sourced from the screen and then have Teams use it as a webcam, but I couldn't get v4l2 to work on my distro (it kept insisting my distro's ffmpeg couldn't encode video even though it could) so I didn't investigate further.
Anyway, a less convoluted setup might be to use the browser version of Teams in a browser where it allows you to screen-share, ie Chromium and not Firefox. IIRC when I tried it a few months ago people on the call said they could only see me broadcasting a black screen, but I know the browser is fine so it had to have been a Teams issue. Maybe it's fixed now.
Hopefully these applications will catch up soon. As another example, Zoom's native Electron application uses a GNOME-specific method of screen-sharing which doesn't work in non-GNOME DEs, but I've heard the browser version works fine.
https://www.phoronix.com/scan.php?page=news_item&px=Chrome-8...
Native applications these days have the option to use pipewire and xdg-desktop-portal for screen-sharing, and it doesn't matter whether they use that from a Wayland window or an Xwayland window. Both Firefox (under Wayland) and Chromium (under Xwayland) use this method today.
Unfortunately Teams does not use that method and instead calls an X function directly, which crashes, as I wrote in the sibling comment.
- An unofficial Teams app (https://github.com/IsmaelMartinez/teams-for-linux) which works great - screen sharing works without problems, no crashing, and native notifications!.
- Use teams in qutebrowser: the dev (The-Compiler) added support for screensharing and it works great. Just like the unofficial app above, it also has native notifications, not the weird popup notifications of the official app.
as a counterpoint: my sway (Wayland) system is the first one I've ever had where I can watch youtube, or vlc/mpv at 60fps without flickering, dropping frames or tearing
I've used nvidia and radeon cards, plus intel onboard in this machine with X and none of them allowed all of the above
the display server also remains responsive even if one client starts going nuts
generally sway is considerably more responsive on the same system than the Xorg it replaced
I am very happy with it
Have you tried Picom?
Presumably your compositor is using llvmpipe software rendering if it's so slow.
Unaccelerated Xorg using something like the vesa driver is slow too.
Xorg is absolutely usable on such machines with compositing disabled, wayland is not.
For this comparison to make any sense at all you need to state which Wayland compositor, Wayland is a protocol.
If there’s a security problem and people are hacking around it, that’s an indication that the either those people have bad needs, or that the security model is flawed — but it’s not an indication that it’s wrong to attempt to secure that resource in the first place.
If a janitor needs the nuclear-missile launch codes to clean the missile silo, you’ve probably fucked something up — but that “something” isn’t the fact that the missile silo doors are code-locked. (Instead, it’s probably 1. the fact that you’re using the same credentials for physical missile access as you are for missile launch, and 2. the fact that your regular janitor is expected to clean the missile silo.)
In this case, the security model of Wayland is the same kind that Windows and Android already have: preventing “low-integrity” apps from screen-scraping “high-integrity” apps. In other words, preventing a random webpage running in Chrome from stealing your credit card details sitting visibly in a sibling text-editor window.
(Or, of course, preventing you from Twitch-streaming your playback of DRMed Netflix video. That’s a use-case that “needs supporting” too, given that the alternative is that type of video not playing back on the platform at all.)
I mean, if you're worried about security of apps from other apps, don't make it something in the apps' domain. Only allow Wayland to take the screenshots, but support that, make it easy, and you won't need to worry about either the security model or users complaining.
I mean, this is the way other OSes do it...to the best of my knowledge (which is certainly not comprehensive) neither Windows nor macOS allow arbitrary apps to screenshot arbitrary portions of the screen; that's handled by the OS itself.
The normal, non-edge-case use of the relevant screen-capturing API is for screen-sharing ala Zoom, or for remote desktop using RDP et al. These are use-cases where one app wants to see what's going on in other apps — exactly the thing you wouldn't want a malicious app to be able to do, but also exactly the thing that you do want these apps to be able to do.
I must admit I haven't tried it, but given NetworkManager, systemd and other pearls from RedHat I'm not optimistic.
Connman is better at least insofar that it is less code than NetworkManager and that it connects to a Wifi network in under a second instead of several seconds. But I believe it can also do less, for example regarding VPNs and such.
sudo nmcli conn up id "VPN" --ask
--password
--user-name
Also `--ask` doesn't ask for your user name.
I mean, sure, it's probably fine when you know how to use it but it has to be one of the least intuitive CLI front ends I have used
I am also frustrated that I couldn't figure it out, which makes me biased
nmcli connection import type openvpn file myconfig.vpn
Even easier than with the usual gui tools.
I gave up on SELinux about 20 years ago when it was a source of endless frustration, or was that 15?
I agree working with selinux is a bit of a PITA but if you learn sealert, ausearch, and/or audit2allow it can severely reduce the pain and allow you to keep selinux enabled. I really like this page personally: https://wiki.centos.org/HowTos/SELinux
i turned off selinux temporarily and activated the connection successfully, and determined that it was indeed SELinux that was preventing NetworkManager from doing its job.
then i re-enabled SELinux went to look at /var/log/audit/audit.log to see what it had to complain about and indeed some files created by NetworkManager in /root/.cert had bad contexts.
I set the proper contexts (semanage fcontext -a -t <context> <pathregex>), applied them (restorecon -Rv /root) and all was well.
SELinux was initially scary but:
- The "SELinux for mere mortals" talks are very informative introductory video (https://www.youtube.com/watch?v=_WOKRaM-HI4)
- The SELinux User's and Administrator's Guide from Red Hat was a deeper explaination (https://access.redhat.com/documentation/en-us/red_hat_enterp... -- linking to rhel 7 because that's what i read at the time)
I had to study this stuff in order to get Red Hat certified (RHCSA, passed with 300/300).
Getting certified is absolutely worth it. Getting certified is the difference between "10-15 minutes to get a diagnosis" and "I gave up on SELinux about 20 years ago".
Edit: This makes sense from an architecture point of view (although unsure whether things have changed since): http://www.landley.net/notes-2014.html#23-04-2014
DefaultTimeoutStopSec=2sA proper fix is to integrate startup and shutdown of all applications with systemd. That's something not properly supported everywhere yet. For example for KDE that's currently in the works: https://blog.davidedmundson.co.uk/blog/plasma-and-the-system...
It got usable within last few years as somewhat general thing (after having already wrestled control over network from you first), of course by the time it got useful work started on replacing it with new thing.
At the time, NetworkManager was gaining steam as "the" solution to wifi woes, and well, I tasted dirt ;)
But the decision to leave people who asked for ad-hoc support (especially when, outside of USA and possibly few other countries, access points were still not as common equipment) was done by design, not because it would require any significant increase in code (IMO).
The updates to network manager decided to change network interface names from looking like enP51p1s0f0 to enP51p1s0f0np0. The rename broke the (also networkmanager) channel bonding configuration, resulting in them being unreachable and requiring a physical visit to get them back online.
Networkmanager adds a lot of automagic, but outside of simple widely used configurations ("laptop with wifi") it causes unpredictable and unreliable behaviour.
I especially like the standard fedora server install where the nics present during the install all get DHCP enabled on them, but only those nics. So if you move a network card to another PCI slot after the install it will mysteriously not work. ... I see nothing wrong with not automatically bringing up interfaces on a server, but mysteriously bringing up some and not others makes for mystifying and difficult to diagnose issues that no one seems to know how to fix.
I don't know when you encountered that behavior, but NetworkManager has for a long time handled wired and wireless as two independent connections; it just sets routing priority to prefer wired if available. I believe you that you observed that behavior, but to the best of my knowledge this does not match any current behavior of NM.
The entire Linux userland is pretty much a Red Hat thing at this point. Deal with it or find another OS.
I'm looking forward to 21.04 for my next attempt to switch, maybe by then Firefox's native wayland support will have progressed as well. After all what's the point of Wayland when most of your software uses xwayland :).
So, I would have to maintain a fork of my window manager and compositor to keep using something like easystroke under Wayland, instead of using a finished tool that hasn't needed any significant maintenance in 7 years. All in the name of ‘security’.
All GTK3 apps runs well on Wayland too. Qt apps runs well but it doesn't feel as polished (I mainly have issues when I use 2 screen with different scaling).
The last big things are chromium and electron. Once those have ozone merged and enabled in stable, it's gonna be a massive step forward. Those are the last apps I can't run natively on wayland. Ozone is in the beta branches now so, hopefully, it will happen next year.
After, it's not that much of a big deal to run those on xwayland as long there's no scaling. As soon as you're on a hidpi screen or just use scaling, it's when it becomes blurry and is quite annoying. I personally still prefer wayland over x because the experience is just better. No flickering, it's smooth and feels more snappy.
In my experience, it doesn't work yet; Firefox can select the IDE window (though you have to select it twice for some reason), and I can see the shared screen on my side (so the Wayland part seems to be working fine, since Firefox can get the window contents), but to my coworkers it appears frozen (they don't see any changes I make to that IDE window). I don't know if it's a bug in Firefox or a bug in Google Meet.
I run a 4k display and a 1920x1080 display side by side, and X is utter garbage at handling it.
I'm running 3 physical monitors, split to 4 "virtual" monitors with overall 3 different resolutions and I have no problem whatsoever (minus dealing with nouveau on 1060).
Happy to see Ubuntu make the switch, it'll pull in a good number of daily users and we can iron out the last few remaining issues.
Frankly, Wayland has been excellent to me. It's hard to describe how nice it is that I can't remember the last time I had to open an xorg conf file to try to get monitors working, or get even basic functionality from my touchpad.
Clipboard works perfectly splendid, screen-sharing works (not as perfectly splendid as clipboard does), input works, chromium/electron is getting support for native wayland. Qt and GTK Wayland support's quite good.
I have had no problems whatsoever and I invite you to try it. I have no hard-proof evidence or numbers to support my opinion, just try it.
I just start new xorg session for screenshare, which, frankly, sucks.
EDIT. I misread Slack for Zoom.
Slack is still a pain point for me as well, but mainly because Slack continues to demand that I install the desktop app for calls/screen sharing.
Zoom's desktop app also doesn't work, but I can use zoom-redirector and have the calls immediately open in my browser (you can get the same thing without the extension, but it requires you pretend that you can't install their desktop app and several button presses for every meeting).
My guess is that we're about 12 months away from having it work by default in most places.
Why? What? Why? The system exactly knows the DPI of all attached displays, why does it still need explicit configuration in 2020 to support HiDPI?!
Sway already detects hidpi displays based on a heuristic from EDID info and chooses an appropriate scale factor.
https://github.com/swaywm/sway/issues/1800
8, now 9, comments in a subthread because no one could bother to validate assumptions or do a Google search.
We've inherited a lot of baggage and odd conventions, some of which were wrong to begin with. I don't think we should be carrying on with it if we can do better. Having these scaling factors directly correspond to physical reality would be a start.
Why do you say Wayland is abandonware? The last activity in the repo is from a week ago https://gitlab.freedesktop.org/wayland
Actually most of repos you linked have the last activity of months ago. It's pretty worrying though.
-- whatwg
Waylands broken architecture makes progress slow through unnecessary duplication, incompatibility and the lack of a smooth migration for many software packages (usually it's rewrite-time). Wayland should be abandoned and the design redone.
But the buffer handling is great, no more flickering...
... so long as you don't care about latency and don't mind a $3000 top of the line 64 core desktop feeling slightly slower than a machine from 20 years ago.
:(
Every time I pull a old system out of mothball and start it up I'm disappointed at how much less responsive the feel is of modern systems sitting right next to them.
And some of the newer Gnome desktops have even removed that, thanks to some tricky work by one guy, as I understand it.
I may have misunderstood the explanation but it seems to involve some nice timing getting all of the application buffers swapped just before the main GPU screen buffer swap. This gives applications long enough to draw updates, for the most part, and gets all updates into the next screen buffer update instead of the update after that.
> Wayland does almost nothing besides render buffer handling. Input? Applications job.
Applications don't do more work to handle input on Wayland as opposed to e.g. X11. It's still event-based, and the compositor feeds input events to applications that can process them as normal. Keyboard, mouse and touch input are part of the core Wayland protocol, and tablet input is part of an extension that all major compositors fully support.
> Window decorations? Compositors job.
Kind of, it's the job of the application (client-side decorations) or compositor (server-side decorations). The compositor can choose which to use. CSDs give more custom look-and-feels to applications that have them (think Firefox or Chrome); SSDs provide consistent looks across all apps. GNOME only supports CSDs, but is an exception in that regard.
> Clipboard? Maybe compositor or toolkit.
Both: https://emersion.fr/blog/2020/wayland-clipboard-drag-and-dro...
Clipboards are (implementation-complexity-wise) scary in X11 as well.
Got a new laptop with amdgpu and am enjoying the new life with wayland and gnome. It just took waay too long.
Kind of. The Chrome browser itself doesn't run on Wayland, it runs on a custom compositor (I believe Aura?). Sommelier[1] is a Wayland compositor used for Linux apps on CrOS (Crostini), but Chrome doesn't use it. There is an ongoing effort (Lacros) to make the Chrome browser itself run under Wayland on CrOS, but it's not public outside of development builds (and not yet on par with the "native" version).
[1]: https://chromium.googlesource.com/chromiumos/platform2/+/HEA...
People who were in the fence about supporting Wayland were now even more convinced they should ignore it. That's one of the reasons a decade later you still have this much FUD.
It could have not gone that way. Now we've got two equally bad alternatives out there.
> That's one of the reasons a decade later you still have this much FUD.
I don't think you know what FUD means.
If Mir was so good and superior they would just keep developing it. Isn't that obvious? If the company who already spent all this dev time aka money on Mir doesn't believe in it, why would anybody else? They were even eating their own dog food and had some major industry pull at their disposal. The answer is they fucked it up.
Not that I care or know a lot about Mir, but do you seriously believe that it was always the best technology that became successful and triumphed over its competitors?
> If Mir was so good and superior they would just keep developing it. Isn't that obvious?
No, that's an arbitrary conclusion you've made. There are multiple reasons why a project might be killed, even if it's a good one. Canonical killed Ubuntu Touch but now it's gaining traction again because we have things like the Librem5 and PinePhone. Premature if you ask me but it makes sense as a business decision.
If we look across industry, would you say killing Google Reader was because it was inferior to others? I wouldn't.
I see that there are a lot of complains about Wayland here on HN. About input, screenshots and other stuff. But I have not experienced any of that. Input works perfectly and I have no problem with screenshots or screencasts.
Maybe it's that I have well supported hardware (Thinkpad X1C7) or is it something that I'm missing?
Essentially, what could depend on shared standards and implementations in X11, can't do so in Wayland, and there are two major forks when it comes to protocol extensions, as well as major fork between GNOME and everyone else on topic of Server-Side decorations.
"We know better" could be their motto.
Honestly, the current state of mainstream desktop environments -- open source or proprietary -- is pretty awful with the exception of perhaps KDE and little ones like XFCE and LXDE. It kind of makes me glad I didn't hop on the GNOME train in the late 90s -- I could see the awful coming even back then -- and just stuck with a bare WM.
We've seen, again and again, that popularity has absolutely nothing to do with technical merit or even lack of overt user-hostility.
The IBus case is classic example - There was high-handed declaration that having one single global IME state is "easier" for users. The problem is when you regularly have to use languages that are incompatible in writing systems and input methods. Whether its one of the CJK or switching between one of the cyrillic variants and latin, life is much easier when you can have separate input state between let's say an Instant Messenger and your IDE.
For me, I recall the "canary in the coal mine" was when they refused (despite earlier promises and roadmaps) to re-implement certain things related to printing, again in a way that probably didn't bother the developers.
A similar case involves all the very deep integration with systemd, where they essentially declared that there's one Operating System under the Sun and its name is Fedora.
And it might feel more polished than Windows 10 on surface, yes. But then it's much less capable and the resources in Windows go towards things like not breaking people's software and behaviours.
It isn't anything to do with the hardware, it is the design assumption that isolating application's input and output should be mandatory.
In hindsight; that was a design mistake. The correct design is probably something like isolation by default but optional (ie, allowing sharing). The current design means further protocols and de-facto standards are required to support, eg, streaming and screenshots. That is bad for an ecosystem that relies on low barriers to entry to get good software written.
Basically, there needed to be a security model but the developers skipped it because it seemed like it shouldn't be the compositor's job. And after a very painful couple of years, seems quite likely that it was the compositor's job.
I'm not really convinced it was. Frankly, Wayland does a great job handling the tasks I want my display server to handle. I don't have to wade into config files every time I plug in a new HID, or a new monitor, and my touch pad is a joy to use.
I think how screen sharing works is actually very dependent on the system in question ( I want a different set of prompts on my desktop from my laptop from my server), and that leaving that complexity out of the display server was a rough, but correct, decision.
That said, I'm with you - I held off on Wayland for a long time because screen sharing and screen recording just weren't there. At least for me, Pipewire is now a working solution. I won't go back to X.
It sounds like screen sharing is a known problem area? Does anyone know if they have fixed these issues in later versions of Zoom or Ubuntu?
That said, Pipewire is a working solution for Zoom today on Wayland. I'm not on Ubuntu, so I don't know if the Chromium package they ship has Pipewire enabled by default, but my guess is that they do.
I use a small extension to automatically default Zoom to opening calls in the browser (https://chrome.google.com/webstore/detail/zoom-redirector/fm...) and there I can share screens just fine (Full desktop, application window only, etc - For the most part, things work fine).
I'd give it another 12 months if you don't want to have to think about it at all, but I'll be honest, Arch/Gnome/Wayland is the happiest I've EVER been on desktop linux.
Wayland should have been a completely new thing built with the lessons learned from X but vastly simplified for how modern display systems are actually used. Unfortunately it was built with no intent to handle many of the common use cases X already handled just fine, leaving that up to third parties to develop their own ways handling it, leading to some fragmentation (Linux really needed more fragmentation!) and very slow adoption.
I think the future of X11 will be that if a vendor --- likely Nvidia --- sees any point in it down the road, they'll fork Xorg and provide, complete with their own driver bundle, the display server.
For now, no vendor of drivers like Nvidia is likely to be concerned about X11 stabilizing because that's less toil for them to keep their drivers stable on Linux. They are busy enough with keeping up with the Linux kernel breaking their stuff every release <--- not a great advertisement for vendors to even support Linux; looked the same with X11 to me during the 2008-2015 period. Changing X11 was not economical to support without a great justification.
Some software is finished --- maybe it's time to call X11 finished.
People make this mistake over and over and over. Nothing prevents the compositor writers from deciding on a common API for screenshots and similar things (and there has been movement in this direction)
They do. It's pointless fragmentation otherwise.
Victims of this mimetic disease have caught on to the idea that 80% of usage needs 20% of the features.
This might well be true in a literal sense, but it ignores that 99% of the users need one or two items from the remaining 80% of the features and its just a different one or two items for each user.
The result is something that isn't completely functional for all but a tiny portion of the user base. :( Workarounds exist to expand that somewhat, though they're often extremely poorly maintained.
For example, I had a gnome3 using system that suddenly started insta-crashing anytime a GTK dialog was opened on it. I eventually had to blow away all its gconf to recover it.
It turned out that at some point someone decided that 300% and 400% scaling had no purpose and caused issues because in some cases they messed up UI layout. They removed them and the removal was just shipped along with security & bugfix updates in fedora. The way it was removed caused instant crashing for people that previously had them enabled!
I'm fixed now, though with the display at 200% I have difficulty reading it (It's a 4k TV that I need to read from a long distance away) ... but since I can't use gtk interface stuff on it at all now I guess I won't be opening any bugs on minor layout issues that might be caused by increased scaling. PROBLEM SOLVED :(
Since it hasn't really caught on or solved the same problems that X.Org accomplished a long time ago, it seems kind of pointless to continue pursuing it at this point. In my opinion, the best thing about X.Org is that it's no longer changing. I remember installing updates for X.Org all the time and booting to a black screen on multiple occasions.
The issue is trying to implement a radical change in the userspace Linux ecosystem. It's not possible without a ton of effort, so it takes an incredible amount of time, sweat and tears. That's the reason it takes 12 years and counting.
The utopian philosophy of "Linux is about choice" has doomed any idea of a Linux desktop.
If it isn't about "choice" - ie. user control and freedom - then what is the point of using Linux in the first place and not stick with Windows where things are already chosen for you and way more often than not work out of the box because it is by far the most tested against desktop environment?
The only truly successful open source software running on a Linux system is the kernel, because there's NO choice. No talented teenager can write their own Linux kernel that does Y instead. Imagine what would the world look like if there were 50 half compatible, community-managed forks of the Linux kernel.
The year of the Linux desktop won't come because apart from the kernel the ecosystem is incredibly fragmented and reaching consensus is pretty much impossible, so in 2020 we're still deciding whether to do client side or server side decorations.
And the point of libre/open is the word from FLOSS you forgot to add: freedom, ie. being in a position to decide and control your software.
Libre/open/free software isn't an end goal by themselves, they the means to be in control.
> The year of the Linux desktop won't come because apart from the kernel the ecosystem is incredibly fragmented and reaching consensus is pretty much impossible
Until Wayland came along, X11 was the only defacto window system for Linux - if you wrote an application targeting X11, it would work on all Linux desktop system.
Wayland fragmented the window system landscape.
> so in 2020 we're still deciding whether to do client side or server side decorations.
This wasn't a question at the past, everyone agreed that server side decorations are better because they allow users more control through their window managers - with exception for special cases, of course (the WMs didn't forbid it after all, applications could do both).
It wasn't until some GNOME "designer" saw iPad, got jealous they didn't thought of it and then mad that people could actually have choice in how their Linux systems looked and behaved that we got client side decorations.
I vastly prefer Wayland on every machine I've used both X and Wayland on (and on laptops, it's frankly hard to describe how much better it is).
Basically - Wayland isn't the future, Wayland is the NOW.
If you want a great touchpad experience on linux? - Wayland
If you want multi-touch and gesture support out of the box? - Wayland
If you want multi-monitor support and mixed scaling? - Wayland
If you don't want to have to edit multiple conf files on every new install? - Wayland
If you want your windows to resize and actually respect the scaling of the current display, instead of the one they opened on? - Wayland
Honestly, it does exactly what I want my display server to do, and then mostly gets out of the way.
My last real sticking point was screen sharing, and I can get that fine with Pipewire and chrome at this point.
I don't open sessions in x anymore.
I've done some programming against GBM directly (wanted an OpenGL ES application to be in a "kiosk mode," didn't want to have to install X / a Wayland compositor + configure it), and the whole DRM+GBM stack is kinda _terrible_. Generously, one could call it barely documented; the majority of the useful and correct documentation I found was on Mesa contributors' blogs, and there were still edge cases in the API that were getting ironed out in the 5.9 kernel release.
I haven't needed to write against EGLStreams, but I might give it a try to see if it's as much of a pain or not; from the 1-page overview on the nvidia docs, I suspect not -- it sounds quite similar to the VK_KHR_swapchain extension.
I see it as another proof that people who depend on the infrastructure do not want to contribute. They would better whine and critique.
Wayland is the protocol and compared to X11 in this context. There are multiple implementations including:
1) Weston (the reference implementation)
2) Mutter (Gnome)
3) Kwin (KDE, also implements X11)
It's important to draw the distinction as many/most of the limitations people come across are in the implementation not with the protocol. People using different implementations will come across different issues too.
...which is the biggest problem of Wayland in my opinion.
By defining protocols only, we now have the development fragmentation problem. The desktop experiences will be more inconsistent between DEs than the era of X11, and minor DE users eventually are forced to switch to major DEs like Gnome because other DEs won't have enough devs to maintain its low-level implementation.
https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...
The CPU jumped to 100 when I recorded my desktop with OBS and had a terrible delay.
It's just not ready yet.
As much as I love Sway, doing all sorts of weird stuff just to share my screen in zoom is too much of a hustle.
I'll probably keep using Sway on my personal device where I don't need that feature, but my work computer will be X11 for a while.
I try to steer everyone toward Google Meet if possible, and unfortunately for the others, I have a decent amount of sway :-D
Kind of a shame.
This desperate push by Wayland people is putting me off of Wayland. You can't FUD a software into being dropped in favor of yours.
Let the impatient get on with beta-testing today's developments, and I'll get around to using them 20 years from now, when only the good stuff remains.
I still do most of my writing and publishing work from Windows 95 and Me, and I love it, because everything is a solved problem, and no new patches to break things are coming out.
Keeping it within NAT and VM is plenty secure enough for my purposes, and IE6 is plenty enough modern for me.
At least I can still read my config files.
The C/S architecture of X11 hits the spot when terminals and thin client are the norm, that means 20-30 years ago, but today, we all have dedicated graphics display devices (GPU, monitors) even in our pocket smartphone, and the way X11 works is holding Linux desktop scene back.
But without X11 there you can't show how much improvement Wayland has. We shall not forget X11.
X11 and its separation of graphic server and window manager encouraged code reuse by placing it in the server, but with Wayland that separation (and the extra context switches) are gone so there is less incentive to share code.
But we don't, and the libraries push other issues into your design as you often are forced to follow their specific idiosyncracies.
I can’t tell if this post is a parody or not. The fact that it’s 2020 and minor annoyances like this are still fairly common in desktop Linux is telling.
macOS SSHing into a Linux VM (either locally hosted or on the cloud) is the sweet spot for me.
I've just had another popup from OSX wanting a password for google, sophos pops up saying it's upset a fair bit, on occasion the entire machine just hangs, and wireguard doesn't set my search domain. There are other niggles but those are the ones that have affected me in the last 30 minutes.
On the other hand the biggest hassle from my desktop is ssh connections time out if I suspend the machine overnight.
(I've used ubuntu LTS on the desktop since 2006, before then it was debian testing since 1999)
That's funny. I was on Linux Mint (windows PC with dual boot) for a few years, then I bought a Dell XPS13 with Ubuntu installed from the factory. I really wanted to like the XPS13, but both the hardware and the OS were just so poor compared to my Mac (that I used at work) that after a few broken things (power source plug broke, the fan was very noisy when I was coding on an IDE, the trackpad was not nearly as advanced as the Macs', shortcuts broke when I upgraded to Ubuntu 19, then to 20, language switching suddenly started taking 2 seconds for no reason, etc etc etc I hope you get the point) that I decided to finally hit the bank and get a little MacBook Air... what a life changing experience: even though the specs of the MacBook Air are a lot lower than the XPS13, it's just a incredibly superior UX. No fan noise even when using the most out of my IDE... trackpad is awesome... even the keyboard is excellent (after the fiasco of the previous Macs, they did get it right), quite superior to the XPS13. The OS itself is just much prettier in all aspects. I feel a small amount of delay sometimes when putting some pressure on the processor, but that's still not something I would call remotely annoying (as opposed to the incredibly annoying Linux UX).
As much as I don't like using Apple stuff due to price and their closed-garden policies, I just can't pass on the superior UX.
Even though my Windows and Linux machines are still available in my closet, I just never had the desire to touch them again since I got the Mac. Unfortunately!
My current desktop PC has been on Debian (mostly Stable, sometimes Testing) for about fifteen years now, and apart from some minor bug here and there, everything works. Including gaming (Steam, as well as some standalone games), work, software development, multimedia.
From where I'm standing, I find Linux desktop much less bothersome than Windows or Mac these days. Every other week, there is an outcry about some new Bad Thing that Apple or Microsoft has done to their OS and half the tech community is up in arms about how all of their workflows are broken.
Or random Twitch streamers often having to fight against Windows more often than I thought reasonable, in order to get their streaming setup back under control.
Or work colleagues annoyed every other month about some VPN app not playing nice with Windows TCP/IP stack and locking them out of company network until they reboot.
Meanwhile, I'm in my little Linux corner, quietly doing my thing and not really having to fix anything other than mistakes I make, and bugs I cause.
IME, Manjaro/Arch unironically provide a better, less buggy experience. Maybe the bugfixes come in faster than the bugs and the devs pay most of their attention to current versions.
And more anecdata: I wouldn't say scripts to fix your resolution are "common" pains on Linux. (Though crashes on Cinnamon are ;p -- stick to KDE or GNOME if you want polish.) The closest I've come to that lately was having to reset the sound daemon due to a Manjaro bug, but that's the only thing in two years I've had to do. Meanwhile, on Windows, the internet dies when I turn my VPN off (the same VPN I use on Linux, at that). And, for that, the scriptable solution's more elusive. "Reinstall and pray" is the only way to go.
input is broken and inconsistent – what?
screenshots don't work – they do. I use them all the time.
remoting is broken – I know it's supported but I've never wanted to do it.
every WM has to be rewritten or abandoned – of course, that's by design. Wayland doesn't even have WMs.
c&p handling are not yet there – do you mean copy and paste? That works fine; it also has a clipboard manager protocol.
they don't work on wayland, they work on specific compositors that implement an extension.
Also, compositors are not mandatory anyways on X (I don't use one personnally and prefer it like that) so it's a weird remark to make.
For example, top level windows and popups themselves are an extension in Wayland (xdg_shell protocol rather than the defunct wl_shell), and so is the rather basic feature of compositing on the GPU (dma_buf) rather than going through some shared CPU memory.
but that is the main critique. Most of the things not being part of core means that there is a lot more fragmentation of the linux desktop than there was with X, which is unilaterally a bad thing.
Currently compositor developers prefer separate implementations and it's really their choice.
Saying "people could just do / not do X" absolutely never ever ever works, not in politics, not in programming, not in "not being an asshole to each other", not in "not using firearms", etc - things have to be enforced & unescapable at some point if we want sanity.
* X11 is a protocol
* Wayland is a protocol
* X11 and Wayland are not compatible protocols
* Wayland protocols are all public
* XOrg is an implementation of the compositor of the X11 protocol
* wl_roots is a toolkit used for creating compositors
From this, it follows that:
* Anyone can theoretically write another X11 compositor which implements a subset of the functionality
* Anyone can write a Wayland compositor which implements a subset of the functionality
I really don’t understand where this supposed extra fragmentation is coming from — unless your objection is that we have more than one Wayland compositor? I don’t see that as a particularly bad; in the same way I don’t see having GNOME, i3 and XFCE existing is necessarily problematic.
It will also get worse, because the architecture of wayland forces an implementer of a compositor (which replaces an X11 window manager) to implement a lot of the display functionality all over again. Wayland itself is just a lib that helps a little with it. In X11 terms, just imagine every window manager developer doing development against their own fork of X.org or a reimplementation of it. Wayland is designed in such a way that it causes incompatibility and fragmentation.
Well no — this is where I disagree. The extensions are standard and hosted within the repository [1]. A repository may support their own proprietary protocol, after all it’s an XML file, but practically speaking without distributing it through the repository means that you won’t get any clients to actually use it. It is wrong to suggest that there is a huge proliferation of interfaces.
It is true that the core Wayland protocols support less functionality than X11. It’s also true that developers implementing windowing managers need to do more work — however, again I point you towards wl_roots, libinput etc. as examples to show that you don’t need to implement anything from scratch unless you want to.
I don’t believe this particular design doesn’t have trade-offs, but to pretend that it has no benefits is also incorrect. The fact that there are less core protocols means that you can implement a simpler compositor if you should so wish. There are comments in this thread pointing to the usage of Wayland in different devices as an application of this.
Screenshots require a privileged application to have access to the whole screen. The X protocol doesn’t provide that, though some implementation might.
I think X11 not seeing a lot of development doesn't necessarily mean that it's abandonware, it's probably more that people like me who still use it feel like it's effectively feature-complete.
And I won't take the word from some graphics hardware vendor that it is abandonned. Over the years they've always done the bare minimum to support the Linux desktop so of course they'll take the first opportunity to claim that X is "abandonware" so that they have a plausible excuse for dropping support.
I used X11 forwarding just yesterday to open & control my linux desktop's music player from my mac - which other 2020 technology allows me to just run
$ ssh -Y my_desktop
> my_music_player&
Xorg (the server) is from 2004 (16 years ago), the X Consortium was founded in 1988, and Wikipedia puts X11 itself at 1984 (36 years ago). Wayland's initial release was 2008 (12 years ago). Wayland is either 3/4ths the age of Xorg, or 1/3rd the age of X11 - bluntly, if they don't have their act together now, why should I expect them to ever get it together?
Granted, there are rough edges, and I wouldn't claim any Wayland compositor is as polished as an X11 one -- but we're not that far off, and for many people the benefits of running a Wayland session today outweigh the cons.
[1]: judging by https://wiki.gnome.org/Initiatives/Wayland
I don't quite follow? modesetting was supposed to replace xf86-video-intel, so it shouldn't be surprising if the latter isn't getting updated.
If the maintainers do not want to maintain it anymore... why not just fork it? I've heard people saying that it is big and complex but some time ago i downloaded the code of the X server itself and it didn't seem that big (i've worked in much bigger codebases myself).
In any case, i wasn't referring to X.org developers - i explicitly mentioned that they do not want to maintain it anymore.
I was referring to those who want to see it continue existing in one way or another.
I am too surprised by critique. Anyone can contribute to X.Org [1], maybe there are no stable releases but it works, have active contributors [2] and recent commits [3] [4].
Wayland lives, ten years ago it was demo, now it has a lot of compositors [5], wlroots shared among many projects.
[1] https://github.com/freedesktop/xorg-xserver
[2] https://github.com/freedesktop/xorg-xserver/graphs/contribut...
[3] https://github.com/freedesktop/xorg-xserver/commits/master
[4] https://github.com/freedesktop/xorg-xserver/graphs/commit-ac...
Last time I investigated this, I went down a rabbit hole that made me vow to buy a Playstation.
In its present state it can't beat "abandonware" I'm afraid. X.org works. Wayland does not. And that's all there is to it at the moment.
The long term plan was to abandon X.org and move to Wayland.
Of course Wayland is still not there, but X.org is mature and stable enough to keep users happy for the time being, until the whole ecosystem catches up with Wayland.
As a matter of fact, abandoning X.org (except for security patches) would be a good strategy to incentivize the ecosystem not to build on top of it anymore.
Maybe X.org should do what request.js and momen.js did and call it done at some point.
So? A "prominent US politician" recently conceded that global warming is a hoax by the Chinese, with coal being the future. Should I be doubling over myself to dismantle my solar panels?
Very weasel-wordy article if you ask me. X11 is fine.
Phone: Nokia8110
Watch: Vostok or Raketa
I would not recommend a OS that is not maintained for day to day work.
My understanding is that Wayland does address some security issues in X11, but that Xenocara (OpenBSD’s branch of Xorg) also attempts to address the security of X11 in a way that integrates with the rest of OpenBSD’s security mitigations.
OpenBSD is a great example of actively developed software that has exceptionally good taste when it comes to change. It’s not that OpenBSD never changes; it’s that OpenBSD only makes changes that feel organic 20 seconds after you experience them.
Exactly! And Xenocara. And Upgrades are painless.
https://lobste.rs/s/vqv6nu/it_s_time_admit_it_x_org_server_i...
[0] https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Xo...
Development hasn't stalled because people think X is good. Development has stalled because the fundamental design is so misaligned from the modern graphics stack that improvements are not worth attempting.
X11 could be easily implemented on new driver framework supporting new graphic stack. Instead we got a piece of sh*t that is fitting for a custom embedded device or some closed environment, but not an X11 replacement.
I haven't seen many serious complaints that Wayland doesn't support the X11 protocol since people can run an X server directly using XWayland.
X11 could be updated a lot. But some of the "weird functionality" is stuff that is slowly becoming available for normal people that was thrown out with the bathwater by GTK3, like ability to use more than 8bit per colour channel.
Yeah, Wayland is a bad protocol. It isn't flexible enough to do what X11 does. But if it was a good protocol, and capable of implementing X11, then it would get X11 for free through XWayland.
They don't need to reimplement X11. They can use X.org or whatever for that.
In term of broken application, what do you mean?
Let's be honest, Linux has a good (but not great) kernel, good-to-great apps on server side, and the crappy UI side (Wayland, windows managers, desktop environments)
The best way to interact with Linux is throught API or commandline. Leave UI stuff for more competent folks (Microsoft or Apple)
The fact that it's not updated with Awesome New Features every month, well, neither is Bash or Postfix.
Some things should just work.
Do officially declared releases really matter all that much?