Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The X.Org Server Is Abandonware?

phoronix.com

Post reply on HN
Print view View original

211–220 of 714 posts

Re: The X.Org Server Is Abandonware?

#211

Post by aidenn0 »

ddevault wrote: post #163
verroq wrote: post #160

Earlier quoted context omitted.

I only really care about performance and Wayland hasn’t been very convincing [0] with no discernible improvement over X11. [0] https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Xo...

GNOME is not a good representative of Wayland. Wayland is just a protocol - it's up to the compositors to have good performance to distinguish it from Xorg, and GNOME does not do well in this regard. Other compositors, particularly wlroots, enjoy excellent performance. Wayland also opens the door to many performance improvements which are not possible on Xorg, and which take advantage of newer GPU features, especiall…

Which embedded systems actually run GLES on Linux stably enough to do anything with Wayland? My experience is the choices are:

Use a binary blob that only works with a 3 year old vendor kernel, and works most of the time (but you can't fix it when it doesn't work, and if you are compositing most of the time isn't good enough)

Use a mainline Linux kernel that is so buggy that fixing the bugs in it is a full time job

Use fbdev

Re: The X.Org Server Is Abandonware?

#212

Post by HeadsUpHigh »

marcosdumay wrote: post #173
ddevault wrote: post #152

Oh, look, more non-experts spreading misinformation about Wayland on HN. Must be Sunday. https://drewdevault.com/2019/02/10/Wayland-misconceptions-de...

So, there are plugins somewhere that support all kinds of basic functionality. I can already see how nice will be to keep a system like this up to date. Do the developers expect to incorporate those plugins at the main code at some time?

The main code of what? Wayland doesn't have a codebase. There are protocols( just like x11) and different compositors support different extensions. The point is that it's much more modular this way.

Re: The X.Org Server Is Abandonware?

#213

Post by hibbelig »

formerly_proven wrote: post #147
kriive wrote: post #57

I have been using sway on Fedora for a year. It's been really good so. It's a smaller niche than X.org's, but I get to do everything I need. HiDPI support is just right, just throw output eDP1-1 scale 2 in the config and you're set. 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 Wa…

> just throw output eDP1-1 scale 2 in the config and you're set 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?!

Maybe my monitor it’s close by and I have good eyes. Or it’s further away. The system can’t know.

Re: The X.Org Server Is Abandonware?

#214

Post by HeadsUpHigh »

snazz wrote: post #198
Athas wrote: post #169

Earlier quoted context omitted.

How would it know what scaling factor you want?

It should start with a reasonable default and then give the user the choice of different scaling factors like macOS does: https://media.discordapp.net/attachments/380570311227342859/...

This is sway, i3 on wayland, a tilling window manager. Not some commercial piece of software that has to target the lowest common denominator to survive in the market. It's meant so that you configure it and it's very configurable. So it doesn't any defaults bar what's needed to launch the manager. The rest is up to you.

Re: The X.Org Server Is Abandonware?

#215

Post by vially »

oriesdan wrote: post #94

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…

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

Re: The X.Org Server Is Abandonware?

#216

Post by mort96 »

solarkraft wrote: post #153
swiley wrote: post #67

Sure X.org is abandonware but there are serious problems Wayland still hasn't solved that X has. 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 programm…

> Wayland is really slow. 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 w…

> No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say.

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.

Re: The X.Org Server Is Abandonware?

#217

Post by ajsnigrutin »

MayeulC wrote: post #199
jleahy wrote: post #194

Earlier quoted context omitted.

I routinely use modern X applications running on a remote (25 miles) machine, all day long as part of my job. It works flawlessly if you have a reasonable amount of bandwidth and reasonable latency. Sure, it doesn’t work over dial-up.

Honestly, X forwarding doesn't work that well in my experience, unless you have a very stable connection, with quite a bit of bandwidth (~1Mbps at the very least). I've had more success using xpra for forwarding, as I'm often connecting over Wi-Fi (hostel, campus rooms...). 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 thoug…

> It's also rather complicated to set-up on the server side (xauth, magic cookie, etc).

you mean "ssh -Y user@host..."?

Re: The X.Org Server Is Abandonware?

#218

Post by podiki »

What's the tiling WM landscape like on Wayland these days? I know of Sway (i3-like), but is that the best game in town? I started with i3 but now love StumpWM (Common Lisp) and XMonad (Haskell), and can't imagine being without something very similar.

Re: The X.Org Server Is Abandonware?

#219

Post by MayeulC »

kbumsik wrote: post #143
agurk wrote: post #123

One important point to note in these discussions is that X.Org is a specific implementation of the X11 protocol (the canonical implementation as it happens). 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 li…

> 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 m…

Wlroots as a library for implementing a Wayland compositor has done wonders to help develop small-scale Wayland "desktop environments". Sure, you pull the whole wlroots things, but under X, you pull xlib, plus some X11 server.

https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...

Re: The X.Org Server Is Abandonware?

#220

Post by severino »

nsajko wrote: post #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 man…

> 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

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.

Post reply on HN