X.Org Needs More People To Run For The Board

[Ironmask]

Where do you get the crystal ball for your blank statements?
X11 is unmaintainable, and yet is it being maintained.

https://lists.x.org/archives/xorg-announce/2023-February/thread.html

There is not a lot of new development, since it works well for ages.
It is a horrible mess, and yet just one year ago, it was used by 90% of Firefox Linux users.

https://www.phoronix.com/news/Firefox-Wayland-X11-Stats

How would you know which APIs are not used by nobody?
If really nobody would be using them, it would be simple to remove them, recompile everything, and we would have X11R8. Apparently there is old software, which use those APIs, and nobody actively develops that old software, but that does not mean nobody is using that software.

It is easy to break the standard and start a new protocol, but it is much harder to replicate the functionality of the old system, and win over the developers... or ever users, if you offer few tangible benefits, and backwards compatibility is not 100%. While rewriting old software is impossible.

X11 was "dead" from the time all Unix workstation manufacturers died. All major Unix related standards were developed by them (NFS, OpenGL, X11, Motif, C, Java, ...). Linux was leeching on this work, re-implementing the standards. To the point where Linux is the only relevant Unix left (being officially certified or not). But Linux has proved to be much less capable of making interoperable standards of its own, and have then accepted into non-Linux platforms. Wayland is the most prominent example of such failure. WSL(G) is struggling for years, and still it has not reached a state, where it would be usable for actual work.
https://github.com/microsoft/wslg/issues

So I'm guessing you're some kind of bank CEO and think COBOL is still alive and kicking because your mainframe software is written in it and you don't see any benefit in replacing it.

[syrjala]

Except there is a problem the board in control of Wayland these days is the freedesktop.org board not the X.org board.

Last I looked fdo was sucked into x.org, and there is just one board. I don't think there ever was a fdo board, even before the merger.

And no board controls wayland development, the developers do.

[kpedersen]

This is where you have to be careful.

https://gitlab.gnome.org/ofourdan/gnome-ponytail-daemon

Sending pointer requests and scraping the screen is very different to the underlying functionality of i.e XMoveResizeWindow, XSetWindowBorderWidth, XSelectEvent, etc.

What are you going to do for a Window Manager on Wayland, analyse the screen pixels and move windows around with careful (mis)use of pointer click/move events? Fragile!

This is interesting right. So information about windows traveling over dbus. What about MIR. Mir use to have its own IPC guess what information about other windows could travel over that.

i3 has an IPC setup too but just like Mir, you can't i.e reparent windows within your own custom drawn ones. Its not flexible enough. Using DBus for window management is daft; it would be like using ToolTalk to control the windows in CDE rather than X11. Using a generic message bus like DBus would be a terrible choice for performance if Wayland people moan about any kind of jitter.

The wayland ecosystem does not say the only IPC you have to use is Wayland Protocol.

No, they delegate much of it to X11

It never crossed you mind for one minute that this design of Wayland may not have been for security alone.

Of course it has. After all, the entire design of Wayland is to throw shit at a wall and see what sticks. Security is a retroactive justification rather than anything meaningful and valid.

Community uptake and market penetration has been their only real goal from inception.

WIN32 API does not attempt to use one IPC for everything either.

Its windowing system is capable enough to manage its windowing needs with a single IPC. In this case, the correct tool is being used for the job rather than saying:

"Oh, shi* I didn't think about that. Oh well, just shoehorn it over DBus, the idiots won't know".

[oiaohm]

Last I looked fdo was sucked into x.org, and there is just one board. I don't think there ever was a fdo board, even before the merger.

And no board controls wayland development, the developers do.

No there is not one board. freedesktop original board is "Software in the Public Interest, Inc."(SPI) Board yes the party in control of the X.org foundations money and assets these days.
https://www.spi-inc.org/corporate/board/ This is the second board.

https://www.freedesktop.org/wiki/

We are part of the X.org Foundation, which is a member project of Software in the Public Interest, Inc., for the purposes of holding assets.

Yes the way this is written is deceptive. Holding assets term the reality is for day to day operations of all assets include servers SPI has final say.

Yes that line looks like freedesktop was sucked into x.org when in reality x.org was sucked into SPI and in that process SPI got full asset control over the little assets x.org owned and kept full control over freedesktop.org assets at the time. Back in the past the X.org board screwed up that badly with financial management(this includes not doing tax returns) that they were no longer legally allowed to take care of their own assets and had to find trustee or merge with some other party. X.org board is like person who has a assigned public trustee in charge of all their assets. You need something done with freedesktop servers and the like you need SPI approval. and the X.org board approval is optional. Basically SPI can tell the X.org board after stuff is done with the servers or not because they have day to day control.

Freedesktop.org was founded as a sub project of SPI. Yes SPI just dumps a stack of public relations stuff on the X.org board so they don't have to deal with it like the XDC conferences..

This is the core problem what X.org foundation board is in control of does not effect day to day operations of those developing x.org or wayland because SPI controls day to day operations. Maybe they would get more people to run for the board if they were more open about what X.org board really can do. Like are you interested in having a public relationship of reasonable size organization on your resume.

This is something that is forgot historically X.org board members were developer but historically X.org board controlled assets that being on the board the developers could control how they were used(see room for major financial miss management). Now that the X.org board does not have that power it makes very little sense for developers of Wayland or x.org to be involved in the board because being in board meeting discussion public relationship stuff is mostly wasting developers time they could spend on project development. Basically remove the corruption of the X.org process and the pool of people interested in X.org board positions dropped massively .

[oiaohm]

Sending pointer requests and scraping the screen is very different to the underlying functionality of i.e XMoveResizeWindow, XSetWindowBorderWidth, XSelectEvent, etc.

Remember you brought up the WIN32 API. WIN32 API is Client side decorations (CSD). Yes parties who have made windows managers for windows has found they have had very limited control.

i3 has an IPC setup too but just like Mir, you can't i.e reparent windows within your own custom drawn ones. Its not flexible enough.

The original MIR protocol could do custom drawn replacement. WIN32 windows manager cannot. WIN32 windows manager only has window position control no drawing of boarders or title bars.

Of course it has. After all, the entire design of Wayland is to throw shit at a wall and see what sticks. Security is a retroactive justification rather than anything meaningful and valid.

No throwing stuff at wall and seeing if what sticks you have to have some benchmark for working out how well stuff sticks. Security is one of the benchmarks Wayland project uses not the only one.

Its windowing system is capable enough to manage its windowing needs with a single IPC. In this case, the correct tool is being used for the job rather than saying:

MS Windows does not use a single IPC for this. Those making replacement shells under MS Windows finds out Microsoft uses 8 different IPCs for windows management. Writing a functional replacement shell for windows is a true trip though hell and it only CSD.

Doing your own custom drawn windows MIR protocol end disappearing to be replaced with a .so plugin with MIR due to the issues this causes.

application->wayland compositor/mir server->windows manager->wayland compositor/mir server->screen vs application->Wayland compositor/mir server->screen..

Why is the first one so bad. Lets follow the worst case of the kernel CPU scheduler handing out time slices where you don't have a locking issue. When I write application in the line next it does not include the Wayland compositor/mir server or windows manager and I will be just calling "Wayland compositor/mir server" the "server"

1) all applications get a CPU time slice
2) server gets a cpu time slice
3) all applications get a CPU time slice
4) Windows manager gets CPU timeslice
5) all applications get a CPU time slice
6) server gets a cpu time slice finally screen.

This is starting to look horrible long right.

Lets just for fun do X11 server with windows manager and compositor of I will be calling X11 server just server and applications don't include the compositor or windows manager or server.
1) all applications get a CPU time slice
2) server gets a cpu time slice
3) all applications get a CPU time slice
4) windows manager gets a CPU time slice
5) all applications get a CPU time slice
6) server gets a cpu time slice
7)all applications get a CPU time slice-
8) compositor gets a time slice
9) all applications get a CPU time slice
10) server gets a cpu time slice and we are finally at screen.

Please note this 10 deep is not the absolute worse case. The windows manager and compositor and server with X11 could get CPU slices at the wrong time then having to yield back the CPU scheduler. This is why there are some quite massive documented stall outs with X11 servers. When I say massive I mean your interface comes non responsive for over 1 hour.

Now lets do the one that does not seam to stall.
1) all applications get a CPU time slice
2) Wayland compositor gets a CPU time slice and screen output done.
Please note this apply even if using a .so plugin.

IPC is not always the best choice for it. Remember Wayland does not mandate 1 IPC. Windows managers over IPC boundary Mir did try the stall is smaller than the X11 stall but it still there yes roughly a 40% improvement yes running X11 without compositor people see 40% less stalling as well and yes Wayland no windows manager 80% improvement over X11 at a rough worst case not the absolute worse case. This is a case it does not matter if you use Wayland IPC, MIr IPC or Dbus IPC the kernel CPU schedulder making error handing out timeslices is going todo the same thing of run though the complete list of applications on the system before it gets back.

There is a strict reason why Windows and mac OS is CSD as well there is a buffer cost to server side decorations(SSD). KDE shows that the buffer cost is small. The big cost you want to avoid is the CPU scheduler time slice issue this means you want to keep you IPC hoops to a min if you want good latency.

You have to remember the lead developer that started Wayland had all the massive stall out bugs of X11 dropped on his job que with the instruction fix it.

Yes stalling due to CPU scheduler in the OS kernel doing the wrong assignments of cpu slices is always going to happen at some point but how bad this is directly linked to how much IPC you do that must happen in a particular order. More IPC you do that must happen in a particular order the worst the stall when the CPU scheduler stuff up.. dbus is not immune to this.

Something else to consider a time slice allocated by CPU scheduler is only so long. This also explains why the Wayand protocol developers are always asking should this be in the Wayland protocol. Remember if wayland compositor is using more than time slice processing something before it gets another time slice ever other application may have been given a time slice first. You are wanting low latency drawing of graphical output right. This also explains pushing items to dbus if they are not speed sensitive as low importance items can be queued up there and done when the compositor has part of a timeslice that not need for low latency items.

Wayland protocol core IPC is basically the high priority channel and you don't want to be over filling this thing. You don't want to have to be sorting what is high priority and low proirty at the compositor because this will consume time out the very precious allocated CPU time-slices instead you want them coming to the compositor pre sorted.

This is a case where you want 2 IPC. High priority IPC and a low priority IPC yes Wayland current usage is wayland IPC is high priority and dbus is low priority. we don't want MS Windows 8 IPCs for windows management.

[dpeterc]

So I'm guessing you're some kind of bank CEO and think COBOL is still alive and kicking because your mainframe software is written in it and you don't see any benefit in replacing it.

If it works and it is less expensive to maintain it than to rewrite it, you keep on using it.
That is how things work with people who pay the bills.
You will get there some day.

[Ironmask]

If it works and it is less expensive to maintain it than to rewrite it, you keep on using it.
That is how things work with people who pay the bills.
You will get there some day.

I'm glad you agree with RedHat's decision to cut back on maintaining Xorg then.