Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
jude-
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
41 ms
·
331.
▲
by
jude-
6y ago
Better idea: fix the bad life choices that got us to this point, so we don't have to keep re-living them. What a concept!
332.
▲
by
jude-
6y ago
Can you think of even a single thing dbus can do that my approach cannot do? Emphasis on cannot here -- if you do reply to this, I expect you to prove that the thing cannot be done by any simpler means. If not, then why does dbus
333.
▲
by
jude-
6y ago
Except now the whole X server is part of a GNOME-specific or KDE-specific API. The bug is "Wayland makes it so programs don't reliably run anymore because they are no longer guaranteed to work with all window managers and deskto
334.
▲
by
jude-
6y ago
> You asked if other X servers are used, Allow me to qualify: ON LINUX! Sorry if that wasn't blindingly obvious when I said I was totally on-board with a DRI3-only X server. > The point with that is that you're bringing
335.
▲
by
jude-
6y ago
In the event that I do need to use something that is Wayland-only, I'd like to have the ability to run it without breaking everything else.
336.
▲
by
jude-
6y ago
Hey, I appreciate you taking the time to reply as you did. > There is, the non-existant security model that can’t really be backfitted without breaking every program - in which case they can just as well fix all the bad parts. Most X11 c
337.
▲
by
jude-
6y ago
> I just think the solution should lie in : 1) dialog 2) laws If they're not willing to be reasonable (like, you don't get to "dialog" about whether or not genocide is appropriate), then the best and most moral course
338.
▲
by
jude-
6y ago
No, this happens if the particular Wayland compositor you're running the program on happens to implement a Wayland protocol or extension you use in a "unique" way that causes your app to break. This wan't a problem with
339.
▲
by
jude-
6y ago
> AFAIK DRI3 is also Linux-only and is not supported on any X server outside of Linux. So? I never said I cared about the portability of low-level rendering software. It's not like anyone cares that Xenocara and the aperture drive
340.
▲
by
jude-
6y ago
I'm assuming that X.org will go unmaintained after a time, which is fine. But if that means I can't get a usable X server running later on, I wouldn't mind taking a crack at adding a Wayland extension that implemented the X1
341.
▲
by
jude-
6y ago
> If you added all those things as X extensions, it would essentially be the same thing as Wayland, because clients that wouldn't use them would still be broken, and every graphical program and toolkit would still be need to be upda
342.
▲
by
jude-
6y ago
> The basic idea of Wayland is that it is a simplification and streamlining of a display server protocol. The work of designing that core protocol is already done and doesn't need to be done again, the original developer likely did
343.
▲
by
jude-
6y ago
Option 1: add an X extension that lets you configure which windows get to see which input events. Most clients don't actually need to see any events besides the ones they would see while in focus, so most clients don't notice. Op
344.
▲
by
jude-
6y ago
Before, a graphical program would run just fine under GNOME or KDE because it wasn't GNOME or KDE handling the video/input multiplexing facilities. But now with Wayland, a graphical program not only needs to target distros, but
345.
▲
by
jude-
6y ago
Are there widely-used X servers that don't support DRI3? Genuine question -- it's been out since 2013. I realize that DRI3 doesn't work over the network (I also never complained about losing X11's network transparency)
346.
▲
by
jude-
6y ago
> There are X extensions for shared memory buffers. Client isolation for X could also have been implemented as some kind of extension. With both of those you could solve some issues but it still wouldn't be the same as redesigning t
347.
▲
by
jude-
6y ago
That's literally the essence of the CADT[1] model of software development. Why do a comparatively-small amount of unglamorous work to solve a bug when you can just burn everything down and rewrite it from scratch? [1] https:/&#x
348.
▲
by
jude-
6y ago
From what I got from the video, the main complaint is that the X.org reference implementation has gotten really crusty and hard to maintain. If so, maybe the solution there would be to do some housekeeping and start deprecating features
349.
▲
by
jude-
6y ago
Great! So instead of having one standard way to do video/input multiplexing, we have at least four -- GNOME's, KDE's, wlroots, and weston (and probably a smattering of others). If I want to write a program that works with &
350.
▲
by
jude-
6y ago
Doesn't that undermine Wayland's selling point of isolating clients' input? No one was clamoring for this until Wayland announced it, and no one was willing to put in the effort to fix it in X11 all these years (even though
351.
▲
by
jude-
6y ago
If the Wayland/fd.o crowd insists on breaking things I relied on to the point where I have to work weekends to fix everything that used to work, I'm going to spend that time replacing whatever software they wrote that I use with s
352.
▲
by
jude-
6y ago
> Nothing is thrown away -> xserver is there for exactly this reason. Adding the extension for a system with bad abstraction is not too wise, but if you wanted to understand it, you would have done so already based on the video. I did
353.
▲
by
jude-
6y ago
> This is simply insecure. “It is easier to cut holes into a solid block than to patch something that looks like swiss cheese”. What reason does a random app has to see each keypress, when it doesn’t have focus? Do you trust eg. the team
354.
▲
by
jude-
6y ago
Right, and as I said elsewhere, this is a problem with the reference implementation being crusty, not X11. That seems to be the point the speaker is making as well. Like, I'm fully supportive of having the X server simply manage DRI3
355.
▲
by
jude-
6y ago
XCB and Xlib are libraries that implement the client side of the X11 protocol. They are not themselves protocols. I'm trying to fix the problems with X11 that supposedly justify Wayland's existence, because I have reason to bel
356.
▲
by
jude-
6y ago
How much of that 1 million lines of code actually gets executed? Also, everyone runs the X server, so its code gets a lot of testing. This isn't true for window managers -- there's a long tail of them. This is just one data p
357.
▲
by
jude-
6y ago
> you will actually find them to be smaller than the respective X11/XCB backends there, for various reasons. It doesn't seem surprising to me. As X.org has gained extensions over the last 30 years, toolkits that speak X11 find
358.
▲
by
jude-
6y ago
Doesn't that strike you as odd? Like, why is it that X11 was so close to fixing the problem, but everyone who would benefit from it (and who touts Wayland's ability to do it) decides to just throw it all away and re-built everyth
359.
▲
by
jude-
6y ago
> if you're concerned about that you should run a test comparing them yourself on your specific environment. I mean, X.org runs well enough on my end? I'm not finding myself wanting something with lower input latency. > The
360.
▲
by
jude-
6y ago
> I tried to give a hint about the basic reason of trying to get out from under the weight of a huge code base that had become old and crufty while the very architecture it was designed around was becoming moot since things were shifting
More ›