OBS Studio Now Ready With Wayland Capture Support

[oiaohm]

I went through that article twice and all I could eventually conclude was: You are like brand of politicians. You are literally "solving problems" you created for yourselves to begin with, complicating things even further and then call it enlightened progress.
Jesus.

Yes and no. Like KDE did not make firefox or chrome be multi process applications.

https://lwn.net/Articles/834329/

Fairness is also an increasingly important issue. Edmundson gave an example of Krita, an advanced graphics application. It performs some heavy processing, all contained within a single process. On the other hand, Discord has those 13 processes, many of which will be making heavy use of the CPU "because it is written in Electron". The system's CPU scheduler will see those two applications as 14 opaque processes, not knowing what they correspond to. This means that Krita could get only 1/14 of the available CPU time, even though it represents half of the applications running. Metadata about running applications needs to propagate through the whole software stack to be available to the scheduler, he said.

Posix process system was designed when thread was pthread that was threading in userspace that the application was slicing up the thread it got and applications like the Krita example. We move forward up today threading is in the kernel and more and more applications are multi process. I would say we are over a decade over due to deal with the problems.


aht0 yes you are kind of right to say solving problems you created in the first place. Using multi processes can gain program crash resistance it can also make a program unable to restart dependable if all parts of the program are not shut down.

This is more of case solve one problem cause another
1) developers of applications solved one problem like increase applications crash resistance by using multi process then this causes secondary problem that the posix process system written into the posix standard no long is that useful.
2) developer of DE have problem like users want search results to be close to instant. DE developers add background process to perform these tasks now management issues with background tasks come a problem.

aht0 yes its kind of right to say they are attempting to solve a problem they created themselves. This is also missing that this problem comes about because they are implementing features users want and the end result of implementing those features is you need better resource/process management than what is in posix standard so everything works right.

[aht0]

Another issue right out of the hat is shifting of blame. "POSIX doesn't have that", "POSIX doesn't support this", "POSIX has left this ambigious"..
Well, when you do have issues - propose what'd you'd see as fixing changes to Austin Group, get things cleared up, instead of "doing your own thing" hundred times. Get over your NIH and it's not personal to oiaohm. I generalize it to Linux devs in general: you have server market sort of grasped into hand by balls and many of them seems to think they can just do things without giving thought about anybody else. Like preteens "we do what we want because we can get away with it".

[stiiixy]

Pre-teen? You mean children?

[oiaohm]

Another issue right out of the hat is shifting of blame. "POSIX doesn't have that", "POSIX doesn't support this", "POSIX has left this ambigious"..
Well, when you do have issues - propose what'd you'd see as fixing changes to Austin Group, get things cleared up, instead of "doing your own thing" hundred times. Get over your NIH and it's not personal to oiaohm. I generalize it to Linux devs in general: you have server market sort of grasped into hand by balls and many of them seems to think they can just do things without giving thought about anybody else. Like preteens "we do what we want because we can get away with it".

Really go to the Austin Group yourself on this point. Solaris when controlled by Sun when implement zones attempted to get a generic API for extra control around applications into the Austin Group define of POSIX. FreeBSD developer of Jails also tried to get a generic for it into Austin Group as well. POSIX standard has a cross platform requirement. This is not the Linux developers alone how to add this extra security and control there is no agreement.

Like it or not some areas you attempt to propose change with the Austin Group POSIX due to lack of agreement between operating systems on how this should be done the result is POSIX standard will not take the change.

There is a problem to being a generic API at times you end up in a impossible location.

aht0 little note here I have brought things up with the Austin Group before and I have asked about this very point in a Austin Group meeting to be told the very much the same answer I just gave you. To get it into POSIX you would need at least FreeBSD and Linux core developers both to agree on how cgroup/zones/jails like stuff is done.

The hard reality here POSIX is not a magic cure all and has it limits. Right back at the start of POSIX you had Unix operating systems offering their own features not covered by POSIX and if proposed to POSIX standard being rejected for not being cross platform enough.

There is a historic precedent with POSIX that does kind of get in way where a feature has to be support by multi platforms before it comes part of the standard when there is no agreement like the zones/cgroups/jails problem you are stuffed going the POSIX route.

Yes the doing the own thing is a Unix thing predating Linux that is coded into the way POSIX standard development works.

aht0 like it or not the correct answer is POSIX standard does not cover it and will not cover it due to lack of agreement so to cover those problem cases you have no choice but to do your own thing and hope you have large enough market share to force others to follow.

Remember POSIX standard does not cover X11/Graphical either. POSIX Standard has many lines in the sand they do not cross.

[vegabook]

Fantastic work, one more crossed off the list of 'Xorg > Wayland' Luddite complaints.

Personally I don't consider myself a Luddite, but I do need certain things to work, the most important of which is screen share on Zoom/Gmeet, and also teamviewer. It's just a basic requirement when you're team working under lockdown. I actually have moved to Wayland now full time, because it offers the real advantage of much better scaling on different DPI monitors. I tend to logout back to Xorg when I have to screenshare and that to me is a legitimate pain which cannot be classed as coming from a luddite. That said you're probably right that the list of real (that is non-dogmatic) complaints is now short enough for a lot of people now to move.

[oiaohm]

Personally I don't consider myself a Luddite, but I do need certain things to work, the most important of which is screen share on Zoom/Gmeet, and also teamviewer. It's just a basic requirement when you're team working under lockdown. I actually have moved to Wayland now full time, because it offers the real advantage of much better scaling on different DPI monitors. I tend to logout back to Xorg when I have to screenshare and that to me is a legitimate pain which cannot be classed as coming from a luddite. That said you're probably right that the list of real (that is non-dogmatic) complaints is now short enough for a lot of people now to move.

Also we do need to think long term as well. Just remember there have been many cases of people showing stuff on Zoom/Gmeet/Teamviewer due to notifications and so on that they never intended to.

The way screensharing has been done was not really designed for something to be used all the time with increasing risk of goof. There has been a serous need for security around what is screenshared so that if a notification on like your personal email that the notification window is only displayed to you not the parties you are screen sharing with.

Of course getting all those application that have been using screen sharing to update to a protocol where security can be done has been problem.