Announcement

Collapse
No announcement yet.

OBS Studio Now Ready With Wayland Capture Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by vegabook View Post
    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.

    Leave a comment:


  • vegabook
    replied
    Originally posted by kaprikawn View Post
    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.
    Last edited by vegabook; 05 April 2021, 10:04 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by aht0 View Post
    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.

    Leave a comment:


  • stiiixy
    replied
    Pre-teen? You mean children?

    Leave a comment:


  • aht0
    replied
    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".
    Last edited by aht0; 03 April 2021, 06:53 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by aht0 View Post
    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.

    Leave a comment:


  • aht0
    replied
    Originally posted by oiaohm View Post

    Gnome and KDE are implementing containers because desktop users really do need more control than posix/unix level security can provide.
    https://lwn.net/Articles/834329/
    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by cl333r View Post
    I'm a desktop Linux user, not a cloud supervisor, does it ring a bell?
    Gnome and KDE are implementing containers because desktop users really do need more control than posix/unix level security can provide.
    https://lwn.net/Articles/834329/

    Thinking this is based around systemd in time we can expect "system extension images" what is basically container like flatpak where what you are seeing from the container may not be the real file system contents.

    The reality is the technology that has proven itself in cloud usage is coming to the Linux Desktop to fix this historic problems the Linux Desktop has had.

    Problems that will be Solved by containerising the desktop.
    1) Lack of ability to kill applications correctly. Incorrect kill of a application results in a application that will not restart because part of it is still running.
    2) Lack of ability to run background desktop tasks at the correct times.
    3) Lack of ability to properly give higher priority to the application with current active window.
    4) Lack of something like window SXS

    Yes writing a file manager for windows if you are not using the right APIs you can see files that are virtual that comes from the windows application backwards compatibility parts.

    The reality if you are file manager developer on Linux you are going to have to get use to dealing with containers going forwards unless you are willing to ignore all the Gnome and KDE users. The problems flatpak puts in way are the future problems that you will hit with KDE/Gnome desktops if you don't deal with them now.

    Sorry I'm a desktop Linux user arguement does not cut it. Many people working on Linux Desktops are cloud supervisors so need proper security and application control in a desktop as well.

    Leave a comment:


  • intelfx
    replied
    Originally posted by cl333r View Post
    I'm a desktop Linux user
    So are you a "desktop Linux user" or a "file browser dev"? Or do you just like to incoherently bitch on forums?

    Leave a comment:


  • intelfx
    replied
    Originally posted by cl333r View Post
    Interface toolkits like GTK3 and Qt5 implement transparent support for portals
    I don't see how this quote confirms your words or contradict mine. Portals are not "libraries managed/encapsulated by flatpak, e.g. Qt, gtk, etc", they are low(er)-level APIs used by said libraries.

    Originally posted by cl333r View Post
    Which I as a file browser dev couldn't give a flying fuck about the exact definition
    Well I don't give a flying fuck about what you don't give a flying fuck about. You posted some bullshit, I called you out on that.

    Originally posted by cl333r View Post
    1) Flatpak is not fit for an app like a file browser which I hoped to distribute as a flatpak.
    True. Nobody said it will be fit for all kinds of apps from day one. You can wait until someone improves it, or improve it yourself (or uselessly bitch about it on forums).

    Originally posted by cl333r View Post
    Whatever happened to all the other systems of security inherent for a Linux (therefore unix) desktop? To me this is plenty, I don't need yet another layer of security on top of it.
    You don't need, others do.

    There is the only form of security inherent to a Linux desktop: POSIX discretionary access controls, which are horribly ineffective and inadequate for a desktop.

    Leave a comment:

Working...
X