Live data from Hacker News

The X.Org Server Is Abandonware?

phoronix.com

131–140 of 714 posts

Re: The X.Org Server Is Abandonware?

#131
post #99

Earlier quoted context omitted.

We do need some form of signal that indicates a project has a maintainer though. It doesn’t matter that he has been inactive for 4 years (on that project), but if I submit a PR, it’s nice if there’s someone at the end of the line.

Repos could really have exactly that. A dead man's switch that asks you every, I don't know, three.to six months - via email even - "you good for this repo still?". You answer with a click "yup" and that's it - a signal on a repo on github or whatever that says "still alive". Otherwise "uh oh - we need help" and then a mechanism there to immediately offer alternative forks with a good enough signal "strength". It's l…

But someone has to volunteer to implement this process. Do you have time for that?

Re: The X.Org Server Is Abandonware?

#132
If Wayland is the future, the future is grim. People often complain that Wayland is taking a long time to catch up to X11, but that actually stems from a deeper issue: Wayland has a horrible design, for an X11 replacement, a design that leads to massive fragmentation issues across the graphical part of the Linux ecosystem. Implementing a Wayland compositor requires much more effort than implementing an X11 window manager and each new compositor implementation reinvents the wheel many times, leaving users with less options for a desktop environment than on X11. Even worse, Wayland does not standardize on or is hostile to some essential features, meaning that users need to rely on compositor specific behavior for those features, if they are even available. E.g., an application that needs to grab the entire screen will need separate code for each compositor it supports screenshots on, or it must use a protocol outside Wayland to get the screenshot. Quoting Red Hat:

> 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...

Re: The X.Org Server Is Abandonware?

#133

This sounds like a bad case of Cult of Release. 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 recen…

If somebody discovers a security bug, what are the chances that somebody can cut a high-quality release with the fix in it, if it hasn't been done for two years?

Re: The X.Org Server Is Abandonware?

#134

Earlier quoted context omitted.

Repos could really have exactly that. A dead man's switch that asks you every, I don't know, three.to six months - via email even - "you good for this repo still?". You answer with a click "yup" and that's it - a signal on a repo on github or whatever that says "still alive". Otherwise "uh oh - we need help" and then a mechanism there to immediately offer alternative forks with a good enough signal "strength". It's l…

You wouldn’t even necessarily need git/github to implement a new system! Agree on a standard file name like .githeartbeat containing a timestamp. Every few months (or w/e), active maintainers could push a commit to update the timestamp.

It sounds like a good idea, but I'm afraid it may be a nightmare for packagers (like the ones providing packages on GNU/linux distros), as they see updates to upstream only to realize they are just pings and don't need to be repackaged.

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.

Re: The X.Org Server Is Abandonware?

#135
post #120
post #95

Earlier quoted context omitted.

It's fine if you're stuck in time. No more releases, no changes, no fixes. It's great if you seek stability and don't want to upgrade anything for the rest of your life.

That sounds like paradise. Where do I have to sign? I’m tired of crapware breaking on every “upgrade”.

OS: OpenBSD

Phone: Nokia8110

Watch: Vostok or Raketa

Re: The X.Org Server Is Abandonware?

#136
post #53
post #15

Earlier quoted context omitted.

What's your problem with NetworkManager? It's generally good, and certainly much better than what came before.

It took about a decade for NetworkManager to gain CLI, all the time it tried to eat more and more control over network stack. It was also opinionated in the worst possible way, like responding to requests to support ad-hoc wifi mode (back when NM was only about WiFi) with "your request is dumb, you're dumb, and we will never do that". It got usable within last few years as somewhat general thing (after having already…

Not saying I don't believe you, but do you have a citation for when they responded to requests in that way?

Re: The X.Org Server Is Abandonware?

#137

Earlier quoted context omitted.

I disagree and think a clean break was the way to go. X had acquired a whole lot of legacy baggage and compatibility with that should be provided by a separate piece of code. 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 alre…

I love how people say that an unified method of taking screenshots, screen streaming, screen recording and performance in general is legacy baggage.

The big mistake with W was leaving so much of function specification to the implementor. W was a spec, but totally incomplete for what was needed to build a usable power user desktop. The Linux DE landscape was already fractured to the degree of inefficiency for such a small user base, and with W this fracture actually deepened due to the Great Unsharing of implementation details. Nothing global. Everything local, from decorations to whatnot. Now, besides competing implementations of an entire display server stack, you have the huge communications & politics overhead between the camps that is required to agree on such simple "protocols" like "inhibit screensaver start" (the "idle-inhibit wars") --- not a good use of resources.

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 Some software is finished --- maybe it's time to call X11 finished.

Re: The X.Org Server Is Abandonware?

#138

Earlier quoted context omitted.

If those are your best arguments against Wayland you are making a good case for it because: 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…

> screenshots don't work – they do. I use them all the time. they don't work on wayland, they work on specific compositors that implement an extension.

Are there even any Wayland compositors in actual use that don't support that extension?

Re: The X.Org Server Is Abandonware?

#139

This sounds like a bad case of Cult of Release. 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 recen…

Having an active maintainer fixing security bugs as they arise isn’t “finding new problems to solve.”

Re: The X.Org Server Is Abandonware?

#140

I have been using Fedora with Wayland daily for over 7 months now and I it works pretty well. 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?

I last tried Wayland on Ubuntu 19.10, but quickly went back to Xorg after discovering some issues trying to share my screen on Zoom. I don’t remember what the issues were specifically, but given that Xorg was working perfectly fine, it wasn’t something I was willing to spend much effort troubleshooting.

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?

Post reply on HN