[HN Gopher] Some might not see how much work it was to maintain ...
___________________________________________________________________
Some might not see how much work it was to maintain xorg server
Author : luu
Score : 57 points
Date : 2023-11-28 19:47 UTC (3 hours ago)
(HTM) web link (mastodon.social)
(TXT) w3m dump (mastodon.social)
| gumballindie wrote:
| What lessons have been learned and what has changed that give
| confidence wayland wont end up in a similar state?
| dralley wrote:
| To start with, Wayland isn't a server, it's a protocol.
| yobert wrote:
| X11 is a protocol too :p
| yjftsjthsd-h wrote:
| That just pushes the problem to the compositors
| hsbauauvhabzb wrote:
| Does the multiple compositor situation result in duplicated
| effort and/or constraints for the end user such as being
| unable to run Konsole on Gnome3 etc?
| yjftsjthsd-h wrote:
| My understanding is that simple applications like Konsole
| should be fine because they only use widely-implemented
| protocols. Where it goes off the rails is when you want
| to do exotic things like take a screenshot, and GNOME,
| KDE, and wlroots have each implemented a different
| protocol to do so.
| t0b1 wrote:
| > exotic things like take a screenshot
|
| I'm not sure but is this meant ironically? Because taking
| a screenshot is a thing people do very often. Capturing
| your screen is, too. Even by third-party programs. And
| yet they never put it in the protocol but just said to go
| to dbus.
|
| > GNOME, KDE, and wlroots have each implemented a
| different protocol
|
| Is that true? My understanding was that GNOME never put
| forth a protocol but always did their dbus thing. I know
| that wlroots proposed a bunch of protocol extensions but
| those never went anywhere since, well, GNOME didn't want
| to implement them[1]. Nowadays I think every
| compositor(?) just implements the xdg-portal stuff.
|
| [1]: https://gitlab.freedesktop.org/wayland/wayland/-/iss
| ues/32#n...
| eadmund wrote:
| I think to the Wayland folks, anything other than using
| Windows is an exotic use case. They're not entirely
| wrong, but if we wanted to use Windows, we ... would be
| using Windows. The great thing about Linux was that we
| could do _more_ than Windows or macOS permitted.
| jdiff wrote:
| Weird take. Windows and macOS both let you do things
| Wayland doesn't currently have widely adopted protocols
| for. Only thing Xorg can do that any of the others can't
| is let a client application manage windows, and it's only
| macOS that really doesn't like that.
| csande17 wrote:
| You definitely get discrepancies in hardware support.
| Historically, different Wayland desktops had wildly
| differing support for Nvidia cards, for example, from
| "works perfectly" to "deliberately rejects them because
| the maintainer is angry about their lack of commitment to
| Wayland".
| zlg_codes wrote:
| What semantics do you think you're conveying? If you
| implement the protocol, _you have a server_. A protocol
| without a server implementation is useless.
| bitwize wrote:
| So is X11.
|
| Xorg is a server.
| MadnessASAP wrote:
| There's been volumes written about the problems with X and what
| would've been done differently. Of course given enough time I'm
| sure Wayland will end up in the same place, it does have the
| advantage that it was designed to be extended upon and for
| implementations to be built from interoperating components (vs
| the monolithic Xorg).
|
| The big difference really comes down too that X was designed to
| connect applications, input devices, and displays (including
| printers!!) across a network in a time when the concept of a
| untrusted network didn't really exist. Neither was there a
| concept of a GPU as they exist now.
|
| Conversely Wayland was designed to connect those items (sans
| printers) within a computer and to default to providing the
| minimum amount of trust to those things, particularly
| applications.
| yjftsjthsd-h wrote:
| I don't think the network thing actually matters; modern Xorg
| doesn't expose anything to the network by default, and IIRC
| will actually fight you about trying to do so to the extent
| that when I wanted to use it that way I ended up using socat
| to bridge TCP to the local socket.
|
| The general comment about trust and security is true, though;
| ex. the usual complaints about any X11 application being able
| to keylog any other (which XACE exists to counter, but since
| nobody seems to have done so I'm assuming it had
| problems!?)).
| cptskippy wrote:
| > I don't think the network thing actually matters; modern
| Xorg doesn't expose anything to the network by default...
|
| It matters from the design and architecture perspective.
| It's foundational underpinnings we're constructed to
| support remote terminals. That really hasn't been a usecase
| for a very long time but the core architecture was built
| with that in mind and the monolithic nature of the code
| makes it very hard to change that.
| roenxi wrote:
| The issues that got us to where we are with X are twofold and
| unlikely to repeat:
|
| 1) The nature of the hardware changed completely. The core X
| protocol [0] was designed around 2D shapes and is prepared to
| do things like FillPoly or PutImage. This means it was largely
| caught unaware by the move to shader-based graphics and the
| absurd amount of processing power we have todaty in graphics
| cards. Wayland from what I understand just manages buffers
| which is better design. Things like OpenGL were tacked on to X
| as an extension, and now pretty much everything wants to be
| handled through OpenGal, but the X design wasn't prepared for
| that.
|
| 2) That would have been enough to kill X from what I've seen,
| but ... the major vendors had horrible binary drivers that only
| supported X, so every fork or new project died. The big change
| was AMD buying ATI and taking the drivers open source from
| 2007, since then there have been the sound of plate tectonics
| as the Linux graphic stack has reformed because now it is
| possible to develop deep in the graphics stack independently of
| AMD/Nvidia support. Note that if Wayland needed to work well on
| Nvidia it would have likely died a decade ago.
|
| So the positive things are Wayland probably won't be hit by the
| same level of hardware change, and if it is it is much easier
| to replace. Really what has changed is that the majority of
| vendors have open source drivers, and Nvidia is eventually
| going to fold and join the club. Not that it matters, anyone
| who cares in the Linux ecosystem buys AMD - this deep learning
| thing has been an unfortunate stumbling block but that looks
| like it will be transient to me.
|
| [0] https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html
| eadmund wrote:
| The cascade of attention-deficit teenagers pinky-promise that
| it won't.
|
| Meanwhile, I understand that Wayland in 2023 still doesn't
| support what X11 supported in 2000. If true, then it's simply
| not fit for purpose.
| 1oooqooq wrote:
| > confidence wayland wont end up in a similar state?
|
| wayland have the issues of today. So they are not the same as
| the issues of yesterday like x11. guaranteed a different state!
|
| In ten years you will probably be crying that opening a window
| on wayland requires you to enter a hostname which is long gone
| into your etc hosts file, pointing to a local server, so it can
| download the window theme on the fly, as root, or something.
| You know, today's problems.
| bsder wrote:
| Wayland is already there.
|
| However, the fundamental problem is that Linux is the only OS
| with _more than one GUI toolkit_. This means that you have to
| insert extra layers of abstractions that other OSes don 't deal
| with.
|
| Every other OS has a native toolkit which is integrated with
| native drivers. The GUI and compositor and OS go together. And
| even those have lots of issues.
|
| When you try to sidestep that integration, you get lots of jank
| and problems (see: Flutter, for example).
|
| Wayland and Co. are wrangling a bear that other companies
| struggle with with way less resource and way less control over
| the interlocking layers.
| anthk wrote:
| Xenocara works right under OpenBSD and HyperBola GNU/Linux. It
| works on legacy devices and newer ones. Security? Use separate
| accounts for work and entertainment. Don't run untrusted crap. If
| any, use an UXterm with the keyboard locking option in the menus
| and do the sensitive stuff there.
| WesolyKubeczek wrote:
| > Use separate accounts for work and entertainment.
|
| Doesn't quite save you if one of your work programs secretly
| siphons all your clipboard contents away to a third party. This
| is why we can't have nice things.
| foul wrote:
| You're thinking too much in the realm of user-friendly. _Of
| course_ on openBSD you would enclose work programs in a
| xephyr and an ad hoc rdomain, or connect a xephyr to a vmm 's
| Xenocara with its own tap device. Xephyrs don't share
| clipboard per default.
| yjftsjthsd-h wrote:
| I guess I'll repeat something I kind of wondered in the other
| thread - if xwayland works, including in rootful mode, is it
| practical to just polish it a tiny bit and ship a... xorg-server-
| shim package or however is easiest, that acts as a drop-in
| replacement and just runs on top of Wayland? I've been playing
| with this on my local machine, and running cage[0] with xwayland
| seems to mostly[1] just work - you run cage, you run an X11
| window manager on it using xwayland, and then you ignore the
| underlying Wayland stuff and run X11 programs, including things
| like xdotool or such that don't really work in a mixed
| environment.
|
| The advantage is that you _can_ have it both ways - users who are
| ill served by Wayland can keep running an _effectively_ pure X11
| environment, but ex. graphics drivers only need to support
| Wayland.
|
| EDIT: Oh hey, it looks like Puppy Linux actually did exactly
| this, including using cage: https://github.com/puppylinux-woof-
| CE/woof-CE/pull/2265
|
| [0] https://www.hjdskes.nl/projects/cage/
|
| [1] Not 100% - there's some weirdness with keyboard
| configuration, and of all things xscreensaver-settings wouldn't
| run, even though everything else I ran worked just fine.
| WesolyKubeczek wrote:
| I think the reason for rootful XWayland to exist, and the fact
| that it's like 100% made by Red Hat, hints that this is why
| they are doing it.
|
| But I would like to run native Wayland clients too, and have
| them behave in such an environment. Can a compositor be made in
| such a fashion that it would cooperate with XWayland and manage
| native clients?
| yjftsjthsd-h wrote:
| > I think the reason for rootful XWayland to exist, and the
| fact that it's like 100% made by Red Hat, hints that this is
| why they are doing it.
|
| I had assumed the same, but then they announced that they
| were discontinuing xorg-server without pointing to rootful
| xwayland, so I'm not sure how to read the situation.
|
| > But I would like to run native Wayland clients too, and
| have them behave in such an environment. Can a compositor be
| made in such a fashion that it would cooperate with XWayland
| and manage native clients?
|
| You can have a mix with non-rootful xwayland on a wayland
| compositor; that's the easy path, really. I don't know if
| there's a way to have a X11 window manager control Wayland
| windows in that kind of system, though.
| gpderetta wrote:
| > of all things xscreensaver-settings wouldn't run
|
| jwz must be so happy...
| wharvle wrote:
| Just 9 years to go before Wayland's replacement protocol is
| revealed, going by the X11 timeline.
|
| Or, in the next year or two, going by the Xfree86/Xorg timeline.
|
| It'll be interesting to see whether the (inevitable) Wayland or
| X11 compatibility layer is the more-heavily-used one in that
| future system.
| MadnessASAP wrote:
| A decade before people start looking for a replacement is
| pretty good numbers. Especially if you consider that's when the
| search for replacement starts. Xorg continued to see
| significant development for about a decade alongside Wayland.
|
| Of course W was only a couple years old before being replaced
| by X. So maybe we'll see Waylands replacement much sooner. I
| wonder if people were debating W vs X the way we debate X vs
| Wayland?
| bitwize wrote:
| X was pretty much W, but async.
|
| Wayland is a fundamental rethink of the entire graphics stack
| -- much needed for modern systems.
| dang wrote:
| Recent and related:
|
| _Red Hat Enterprise Linux 10 Plans for Wayland and Xorg Server_
| - https://news.ycombinator.com/item?id=38440607 - Nov 2023 (160
| comments)
| zelon88 wrote:
| Whenever I think of X or Wayland it always makes me think of what
| the Windows code must be like. What secret monolithic struggles
| have the Windows devs secretly been fighting with for the past 30
| years that nobody will ever appreciate?
| idonotknowwhy wrote:
| You can get some insights from the guy who made the task
| manager via his youtube channel
| estebank wrote:
| https://devblogs.microsoft.com/oldnewthing/
|
| Enjoy
| agumonkey wrote:
| I think it was raymond chen's blog that made it clear a lot of
| work was done by MS trying to survive the market with
| competition, legacy, partnership constraints .. a lot that was
| never mentioned because it wasn't a business argument and was
| just expected to be done behind curtains.
| ndiddy wrote:
| I don't really understand how one engineer working full-time on
| Xorg, two weeks of QA, two months for a feature, etc. should be
| even remotely considered a burden to a company as large as Red
| Hat.
| jtgeibel wrote:
| Well RH is already locked into this level of maintenance
| support for existing RHEL releases. By dropping Xorg support
| now, they can fully drop this effort in a decade plus. If they
| keep Xorg support in new releases, it keeps pushing that
| horizon out further and further.
| dralley wrote:
| >two weeks of QA,
|
| What he said was, a couple of weeks of QA, per stack, _per
| hardware enablement_.
|
| Given that new hardware is constantly being released every
| couple of months, that adds up to a _lot_ of QA. And as they
| said in a followup, that 's "a couple of weeks" for a team of
| people and not just one or two.
|
| So yeah, "two (additional) weeks of QA" wouldn't be that bad,
| except it's more like "two (additional) weeks of QA, multiple
| times a year, for a team of multiple people". And that's not
| insubstantial given the meager revenue opportunities in the
| desktop linux market.
| ndiddy wrote:
| Thanks for replying, that makes more sense. Since you work
| for Red Hat, do you happen to know what the process for
| certifying hardware is? I'm curious to know what goes into
| guaranteeing that a given hardware configuration is supported
| by RHEL.
| dralley wrote:
| I have no idea, sorry. I've never worked on any part of
| RHEL.
| gwynforthewyn wrote:
| The author addresses this misunderstanding in a comment at
| https://mastodon.social/@csoriano/111490414205548053
|
| The tl;dr is that the comment on one engineer's tasks and the
| QA that one of the chores takes weren't intended to communicate
| that the team was 1 person big (or, presumably, that there's
| only one QA chore).
|
| FWIW, my read of the wording around QA was that when a each new
| hardware platform is enabled, it takes 2 weeks for the whole
| team to work through their test cases. I assume, though I don't
| know, there's a lot of other QA done, such as when a new
| feature is added or something.
| jancsika wrote:
| > Customer with expectations that are difficult to match. e.g.,
| using xorg modesetting you had tearing, which is not acceptable
| for e.g. digital signage. Intel-drv driver had tearfree, but then
| new hw didn't work. Solving took more than 2 months. This is
| standarized in Wayland.
|
| I'd like to know more about this one.
|
| I mean, suppose the digital signage hardware/software supported
| OpenGL GPU-accelerated rendering. In that case how would Xorg
| tearing/tearfree matter? The software is just rendering using
| OpenGL so Xorg vs. Wayland shouldn't make any difference. IIRC
| some game dev mentioned this once, how their game is just using a
| toolkit doing full-screen accelerated rendering-- the underlying
| display server didn't really make a difference.
|
| If I'm right, then the signage hardware must have been using non-
| accelerated path under Xorg.
|
| That leaves me wondering:
|
| * is most modern digital signage running without any GPU
| acceleration?
|
| * does software rendering work well enough under Wayland to
| deliver smooth animation for professional use cases on
| underpowered hardware?
|
| I'm just having trouble thinking of digital signage constraints
| that need high-enough framerate that Xorg was a problem, but also
| low enough that software rendering was feasible.
| wtallis wrote:
| I expect a lot of digital signage is running through a browser
| engine these days, like everything else. Who would be targeting
| raw OpenGL surfaces these days?
| jdiff wrote:
| Even if you render with whatever you please, software, OpenGL,
| Vulkan, you have to communicate with Xorg to slap it on the
| screen, and that'll result in tearing. On my Nvidia machine,
| the only escape from tearing is manually enabling the full
| composition pipeline in Nvidia's settings application. Nothing
| else, even Vsync settings, can save me from it.
| andrewstuart wrote:
| What does this mean?
|
| Is this saying xorg server is dead?
|
| I don't understand - there must be virtually infinite (relatively
| speaking) software built around xorg.
|
| Is there an official announcement of the death of xorg or
| something?
| chias wrote:
| Presumably it refers to the removal of xorg from redhat's
| repositories.
| dralley wrote:
| In RHEL 10, a year and a half from now.
| wmf wrote:
| Yes, Xorg died years ago. It is barely maintained.
| https://www.theregister.com/2020/10/30/x_server_lead_maintai...
| tapoxi wrote:
| Red Hat maintains Xorg, and deprecated it back in RHEL 8.
|
| Someone can of course take up the mantle, but no one is
| interested and most of the Xorg team has moved on to Wayland.
| Uptrenda wrote:
| Yeah, this makes sense to me. One problem that open source has is
| like a million fractured efforts for the same wheel. It can lead
| to a million half-baked solutions instead of maybe just a few
| solid options. I know it has pros, too, but in many ways it would
| be easier if there were less projects and more people
| contributing to main projects.
___________________________________________________________________
(page generated 2023-11-28 23:01 UTC)