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

How X Window Managers Work, and How to Write One (2014)

jichu4n.com

Post reply on HN
Print view View original

191–200 of 250 posts

Re: How X Window Managers Work, and How to Write One (2014)

#191

Post by vidarh »

md8z wrote: post #187
vidarh wrote: post #182

Earlier quoted context omitted.

I'm not doing this, it's a thought experiment. I'm happy to stay with X for a long time if necessary. But what you list is not enough, though. There are enough extra bits that goes well beyond what Wayland provides today, like ability to write a standalone wm without having to build a whole compositor, for example, that you'd end up with something quite substantially unlike Wayland if you went down that route and loo…

I still see no purpose to do that, with a lot of hacking it would be also possible to make XWayland work with window managers. But that also would be pretty pointless to do because those other parts of the X protocol are also bad and need to be replaced, you might as well just rewrite the window manager. If you liked bspwm then you might want to try this: https://github.com/riverwm/river

And I see no purpose in switching to Wayland as long as Xorg keeps working just fine.

> If you liked bspwm then you might want to try this: https://github.com/riverwm/river

If I wanted to spend time redoing my configuration, maybe, but I have better things to spend my time on. So in however many years it takes before getting Xorg running starts taking more effort than switching. I'm not expecting that to happen anytime soon.

Re: How X Window Managers Work, and How to Write One (2014)

#192

Post by md8z »

vidarh wrote: post #191
md8z wrote: post #187

Earlier quoted context omitted.

I still see no purpose to do that, with a lot of hacking it would be also possible to make XWayland work with window managers. But that also would be pretty pointless to do because those other parts of the X protocol are also bad and need to be replaced, you might as well just rewrite the window manager. If you liked bspwm then you might want to try this: https://github.com/riverwm/river

And I see no purpose in switching to Wayland as long as Xorg keeps working just fine. > If you liked bspwm then you might want to try this: https://github.com/riverwm/river If I wanted to spend time redoing my configuration, maybe, but I have better things to spend my time on. So in however many years it takes before getting Xorg running starts taking more effort than switching. I'm not expecting that to happen anyti…

It doesn't really work fine though, there are numerous really old bugs that never got fixed. Here's a sample:

https://gitlab.freedesktop.org/xorg/xserver/-/issues/386

https://gitlab.freedesktop.org/xorg/xserver/-/issues/333

https://gitlab.freedesktop.org/xorg/xserver/-/issues/380

https://gitlab.freedesktop.org/xorg/xserver/-/issues/249

https://gitlab.freedesktop.org/xorg/xserver/-/issues/260

https://gitlab.freedesktop.org/xorg/xserver/-/issues/258

And I'm sure you could find plenty more. All this stuff is fixed or is trivially fixable in Wayland, by the way.

"If I wanted to spend time redoing my configuration, maybe, but I have better things to spend my time on"

I don't understand, you were just talking about spending significantly more time rewriting the X server...

Re: How X Window Managers Work, and How to Write One (2014)

#194

Post by md8z »

vidarh wrote: post #190
md8z wrote: post #167

Earlier quoted context omitted.

X ran "fine" on those machines if you were ok with all the problems of 80s-90s era graphics such as flickering, tearing, windows taking noticeable time to be redrawn, stale contents when resizing or when something else moves above them, the occasional "solitaire effect" where the back buffer doesn't get cleared, or any of that other fun stuff from dealing with expose events... Also I think it should be obvious by now…

Avoiding flickering and tearing is something we've known how to do since the early 80's. It's not a protocol issue, but an implementation issue. If you don't double-buffer and and/or sync updates, then sure. Redraw time when the systems were slow enough to for the client app to not be fast enough to render the content, sure, there's no way of avoiding that. But again that is not a protocol issue. Wayland can't help y…

Once you are talking about double/triple buffering every client, you are getting into an area where there are accelerated graphics and where fullscreen compositing isn't going to be a performance issue. Of course Wayland doesn't "solve" it but it does remove the old slow code paths. If you're on an SoC with a GPU then you want to use it as much as you can otherwise you are wasting CPU.

The rest of your comment doesn't really make any sense to me. Somebody could make X12 but I'm sure you understand that doing that would have all the same technical/organization challenges as Wayland. I don't know why you would think making an incompatible fork of the X server and then trying to convince everyone to use it is a simple endeavor, it's not. There is zero will to actually do that, I've heard similar suggestions to make X12 for the last 15-20 years, and nobody has ever cared enough to do it because the only reason anyone ever uses X is for compatibility with old software. Once you take that away, there's nothing left. The closest existing thing to an X12 is, well you guessed it, Wayland.

Re: How X Window Managers Work, and How to Write One (2014)

#195

Post by toast0 »

Hendrikto wrote: post #77
loxias wrote: post #24

Earlier quoted context omitted.

> replacemeant for Xorg WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. There's what feels like a rising attitude in the F/OSS community o…

> I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were. Systemd offers countless advantages over previous init systems: https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d...

> Systemd is neither unnecessary nor stupid.

I'm living a pretty good life without systemd, so it's clearly not necessary. I'm sort of willing to acknowledge that it fits some people's needs better than alternatives however.

systemd doesn't have the ability to cancel tasks from the console like other init systems do, for example when my laptop can't get a DHCP response from the network card that's not plugged in, so it's clearly stupid (and so is the init script or whatever it's called that's trying to get an answer from a not plugged in NIC, but that's a separate although related issue).

Re: How X Window Managers Work, and How to Write One (2014)

#196

Post by loxias »

md8z wrote: post #165
loxias wrote: post #161

Earlier quoted context omitted.

> I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor. Of course! I hate tearing, just as much as the next guy. However I honestly haven't seen any tearing in video watching under Xorg, anytime in .. I donno .. at least the last 6 years. And this isn't exactly a powerful machine. :) If I have a video windowed and I move it around while playing, I can see a…

The reason you don't see any tearing is probably because video players under X have gotten better about "guessing" when the frame is supposed to be displayed. The knowledge to do that has accumulated over the last 30 years and it's a pile of hacks, and it's still possible for them to tear under various circumstances because X is still fundamentally an unsychronized protocol (unless you use a compositor with frame syn…

Thanks for this! I was thinking similarly, but you phrased it better than I could. My observation was "it used to suck, just like wireless, and suspend/resume, but now it doesn't." which matches perfectly with "software has built up a pile of hacks... aka bug fixes".

BTW, despite any appearances to the contrary, I recognize (and look forward to!) the superiority of an architecture based on fixed rate interrupts rather than a freewheel unsynchronized protocol. I was just afraid, previously, that:

1) All my stuff is gonna break! (Consider I've been using the same setup unchanged since the mid 2000s, and it's got a lot of self written code)

2) I'm gonna be stuck with a system I consider ugly!

3) My stuff breaking will be in exchange for nothing I consider worthwhile in return!

Now that I read the great article https://www.phoronix.com/scan.php?page=article&item=x_waylan..., much of my FUD has melted away. I know that #2 and #3 aren't true, #1 is probably true but now I'm looking forward to it.

Re: How X Window Managers Work, and How to Write One (2014)

#197

Post by yjftsjthsd-h »

md8z wrote: post #181
yjftsjthsd-h wrote: post #166

Earlier quoted context omitted.

> And I am sure, if you really think about it, you know this yourself. I already disliked systemd on its own merit, but the condescending "if you disagree you're a troll or an idiot" attitude of its proponents really helped cement the feeling.

Please avoid making bad faith interpretations. I'm reading that comment as this: surely you can acknowledge that sysvinit is not a good solution for many people? And just for the purpose of adding some structure around sysvinit, systemd does an adequate job? And if you have an advanced use case that requires a very specialized init system, I hope you can understand how that is uncommon?

I don't think that is a bad faith reading; when the original statement was (basically) "systemd is bad and overcomplicated", saying "it's not and you know it" is a bad-faith statement. And no, sysvinit was perfectly fine for most people; if anything, I could fairly describe systemd as a very specialized init system for uncommon requirements. Now, I'm happy to agree that systemd is also basically fine for the most common uses (because, honestly, the most common cases are covered by anything), but it also introduced pain points for even non-esoteric cases (I've personally witnessed systemd getting stuck in fascinating nondeterministic ways more than sysv).

Re: How X Window Managers Work, and How to Write One (2014)

#198

Post by loxias »

md8z wrote: post #163
loxias wrote: post #162

Earlier quoted context omitted.

> ... "correctly" ... You and I have an opposite definition of "correct" in this context, perhaps neither of us should use it! See enriquto's comment above, this is subjective . To us, we expect a window of size WxH to be WxH pixels, regardless of display. That's my definition of handling it properly, and when I use Wayland that's what will happen. I will (grudgingly!) concede that perhaps it's not "universally and o…

We don't though, I mean if you explicitly change the scaling factor. Of course if you don't change the scaling factor then your scaling would technically be correct.

You're right! I'm sorry! You said "scaled correctly" but I misinterpreted as "appear/behave correctly".

Before this discussion I didn't have the concept of "scaling" my windows.. because that doesn't make sense to me, and it's something I'd never want. So my scaling factor for everything would be 1. Given that, Xorg "scales" perfectly.

Re: How X Window Managers Work, and How to Write One (2014)

#199

Post by md8z »

yjftsjthsd-h wrote: post #197
md8z wrote: post #181

Earlier quoted context omitted.

Please avoid making bad faith interpretations. I'm reading that comment as this: surely you can acknowledge that sysvinit is not a good solution for many people? And just for the purpose of adding some structure around sysvinit, systemd does an adequate job? And if you have an advanced use case that requires a very specialized init system, I hope you can understand how that is uncommon?

I don't think that is a bad faith reading; when the original statement was (basically) "systemd is bad and overcomplicated", saying "it's not and you know it" is a bad-faith statement. And no, sysvinit was perfectly fine for most people; if anything, I could fairly describe systemd as a very specialized init system for uncommon requirements. Now, I'm happy to agree that systemd is also basically fine for the most com…

That doesn't seem to be what most Linux distributions were thinking around 10 years ago when the upstart/systemd/openrc/etc arguments started happening. The general consensus seemed to be that sysvinit needed to be replaced, or at the very least it needed to have a ton of other scaffolding on top of it in order to make it keep working.

Sysvinit never got stuck in those cases because it never had service dependencies and thus never needed to have a constraint solver for the dependency graph... So could you honestly say that pain point was better?

Re: How X Window Managers Work, and How to Write One (2014)

#200

Post by mcguire »

DonHopkins wrote: post #76

https://donhopkins.medium.com/the-x-windows-disaster-128d398... >As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics…

"[Footnote: We have tried to avoid paragraph-length footnotes in this book, but X has defeated us by switching the meaning of client and server. In all other client/server relationships, the server is the remote machine that runs the application (i.e., the server provides services, such as database service or computational service). For some perverse reason that’s better left to the imagination, X insists on calling the program running on the remote machine “the client.” This program displays its windows on the “window server.” We’re going to follow X terminology when discussing graphical client/servers. So when you see “client” think “the remote machine where the application is running,” and when you see “Server” think “the local machine that displays output and accepts user input.”]"

Still having problems with the difference between a client and a server, eh?

P.s. I'm starting to view this article the same way Tesla did the Top Gear review episode: it was cute the first time, but...

Post reply on HN