Goodbye, Green Recorder(github.com)
github.com
Goodbye, Green Recorder
https://github.com/foss-project/green-recorder/commit/5fc594b44f76b7a1469a893d8502ca3f1fb89312
24 comments
How is that feasible? Adopting a more or less complex codebase of random projects that you probably have little interest in, have they got any success story that goes beyond the good intentions?
I've personally picked up a few abandoned projects, and a few more people have picked up others. It's a good introduction to OSS development, it takes five seconds to do and it beats just archiving the repo even if nobody takes it up.
Sad to see, but OBS is a very capable and easy to use application if you need.
Besides the fact that OBS is not open source, why is this comment being down voted?
It's also free, isn't it? And therefore a very viable alternative to the vat majority of users
It's also free, isn't it? And therefore a very viable alternative to the vat majority of users
Free and Open Source GPLv2 (the O is for Open even):
https://github.com/obsproject/obs-studio
https://github.com/obsproject/obs-studio
It's not open source? The repository says GPLv2...
[deleted]
Does anyone know the true backstory to this one?
Why, do you doubt the "it took up too much of my time and energy" story?
He could have just moved the maintainership to someone else. I was wondering if there was something that triggered the decision is all. I wasn't trying to be snarky or mean, I just wanted to know what had cause the burnout.
Sorry this got taken the wrong way.
Sorry this got taken the wrong way.
Why would someone post this commit of a practically unknown project here if there was no juicy backstory?
It’s simple open source economics: Since no one is being paid to maintain the software, there is little incentive to continue developing it. However, since it is open source, anyone who feels inclined to can fork the code and create a maintained branch.
There's a link to the true backstory here: https://github.com/foss-project/green-recorder/commit/5fc594...
Just taken at face value, it looks like they didn't want to put in the significant effort of moving to newer display stacks. Wayland has a very different story for screen recorders, in ways which are likely to require significantly more ongoing effort.
Which I'm not sure I understand fully since I was under the impression that Green Recorder was pretty much created for the singular purpose of supporting GNOME+KDE/Wayland.
I'm surprised that GNOME and KDE dropped the ball on this since all they had to do was provide a stable dbus API and any app would be able to consume it with very little fanfare.
I'm surprised that GNOME and KDE dropped the ball on this since all they had to do was provide a stable dbus API and any app would be able to consume it with very little fanfare.
Yes, except that wayland would have been the proper place to expose it, but they declined because it would supposedly compromise security (spoiler: to reach that interface, you must already have arbitrary code execution). So every compositor is now faced with reimplementing that same wheel on their own - each exposing their own interface somehow.
Okay, there's a lot to unpack here. First arbitrary code execution doesn't really matter. We're talking about a client-server relationship. Just because you have arbitrary execution on your laptop doesn't mean my server's security is compromised. And just because you have arbitrary code execution in a sandbox, container, flatpak, VM, or other host and can talk to my compositor doesn't mean it's compromised.
The security model for Wayland is that it should enable you to create secure systems if you wish to plug the rest of the holes. You can't really use Xorg in a secure system because being able to talk to the X server at all exposes too much privilege.
Screen recording (and taking screenshots) is a bad fit for the Wayland protocol because then what is a very small and lean protocol suddenly needs to know about things like image and video encodings. And since it's a display-only protocol you either have to teach Wayland about auto streams and mixing or stitch together your audio out of band.
But fine, we somehow all agree that such things are in the scope for a display protocol. Recording your screen is still a privileged operation and Wayland doesn't have an authentication or permissions system. How should they authenticate? In a way that a malicious program can't fake?
We end up just reinventing dbus, polkit, pulseaudio, pipewire but in a way that ensures that you can't swap out those components for something else.
If you care about standardization then it's really not that bad: GNOME and KDE typically work in tandem when desiging dbus interfaces and smaller DE's end up implementing those. So far the world hasn't ended for media controls and it won't end for screenshots.
The security model for Wayland is that it should enable you to create secure systems if you wish to plug the rest of the holes. You can't really use Xorg in a secure system because being able to talk to the X server at all exposes too much privilege.
Screen recording (and taking screenshots) is a bad fit for the Wayland protocol because then what is a very small and lean protocol suddenly needs to know about things like image and video encodings. And since it's a display-only protocol you either have to teach Wayland about auto streams and mixing or stitch together your audio out of band.
But fine, we somehow all agree that such things are in the scope for a display protocol. Recording your screen is still a privileged operation and Wayland doesn't have an authentication or permissions system. How should they authenticate? In a way that a malicious program can't fake?
We end up just reinventing dbus, polkit, pulseaudio, pipewire but in a way that ensures that you can't swap out those components for something else.
If you care about standardization then it's really not that bad: GNOME and KDE typically work in tandem when desiging dbus interfaces and smaller DE's end up implementing those. So far the world hasn't ended for media controls and it won't end for screenshots.
Sorry, you are wide off the mark. Arbitrary code execution is game over because performing privilege escalation is usually prettyntrivial after that. Also, wayland is just a local IPC protcol.
To be more precise, its graphics related part is a GPU buffer management protocol only. No graphics data is passed between processes through that channel. All that happens is buffer allocation and buffer access brokering. This ties into what the wayland part of a screen capture tool is: read access to the frame buffer after composition. No image encoding, no video codecs or anything else, just the ability to get to the raw pixels.
This also means that sound is a non-issue for wayland because the audio stack is separate.
Also, I remember that adding authentication prompts to compositors was seriously comsidered when screen capturing came up on the wayland mailing list. IIRC it was only rejected because it created weird synchronization issues because of the unspecifies time interval between the request by an application and the response by the compositor. And I seem to remember that there are some compositors who allow whitelisted applications to perform operations that are comsidered privilieged.
Anyway, I consider a display server that doesn't allow an application to query window positions and acreen resolutions and forbids explicit window placement to be broken as far as any serious GUI apllications are concerned. This combination of restrictions makes implementing features like sane tooltips and context menus impossible.
To be more precise, its graphics related part is a GPU buffer management protocol only. No graphics data is passed between processes through that channel. All that happens is buffer allocation and buffer access brokering. This ties into what the wayland part of a screen capture tool is: read access to the frame buffer after composition. No image encoding, no video codecs or anything else, just the ability to get to the raw pixels.
This also means that sound is a non-issue for wayland because the audio stack is separate.
Also, I remember that adding authentication prompts to compositors was seriously comsidered when screen capturing came up on the wayland mailing list. IIRC it was only rejected because it created weird synchronization issues because of the unspecifies time interval between the request by an application and the response by the compositor. And I seem to remember that there are some compositors who allow whitelisted applications to perform operations that are comsidered privilieged.
Anyway, I consider a display server that doesn't allow an application to query window positions and acreen resolutions and forbids explicit window placement to be broken as far as any serious GUI apllications are concerned. This combination of restrictions makes implementing features like sane tooltips and context menus impossible.
My guess is that its due to comments like this:
https://news.ycombinator.com/item?id=20695387
Well if it was Python 2 only then he wasn't maintaining it much to begin with.
Skeptcism can be good, but not in excess. If you decided to respond by saying "In your opinion(s), what led them to close shop?", folks would have responded more kindly.
It's a community that aims to help take care of OSS projects when the maintainer no longer can.