vokoscreenNG
us.zoom.Zoom
Our great sponsors
vokoscreenNG | us.zoom.Zoom | |
---|---|---|
18 | 31 | |
982 | 34 | |
- | - | |
9.7 | 6.7 | |
5 days ago | 20 days ago | |
C++ | Shell | |
GNU General Public License v3.0 only | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
vokoscreenNG
-
Aplikasi screen recorder
VokoscreenNG simpel, gratis, opensource
-
Screen recorder for Linux?
vokoscreencastng has some extra options for mixing in audio from microphones and domputer... it's available for windows as well if that's something you like.
-
Help with UVC plugin
You should use RemoteJoyLite & use OBS/Win+G/Vokoscreen to record RemoteJoyLIte's contents + an aux cord with a sound card with line-in to get the audio
-
Free Screen Recorder for a very low-end laptop.
Check out VokoscreenNG: https://linuxecke.volkoh.de/vokoscreen/vokoscreen.html
-
What is the best free screen recorder??
GitHub: https://github.com/vkohaupt/vokoscreenNG
-
Show HN: It is a simple recording program with the ability to record the screen
I learned about the super useful VokoScreen[1] at HN, so now I'm returning the favor back at HN, for those using Linux (although looks like it also has Windows builds? I didn't know before!)
-
NVIDIA Teaming with Valve and the Linux Gaming Community to Bring DLSS to Proton
vokoscreenNG does not work with Wayland: https://github.com/vkohaupt/vokoscreenNG/issues/51
us.zoom.Zoom
-
btw
It seems to divert the discussion to something that doesn't make too much sense. X and Wayland are two different things by design, this probonopd sounds extraordinarily salty that moving an application under a new server breaks some things, making some applications entirely useless, but I say, that is to be expected. Saying that Wayland breaks stuff by design, as if that was their only objective is just petty, of course it's a pity that those devs have thrown in the towel, but let's not pretend like theirs were the only options, e.g. screen recording works perfectly fine with OBS, at least it has done so on my machines with AMD/Intel GPUs; Jitsi works now; Zoom screensharing being GNOME only is Zoom devs being dicks that can't be arsed to support standards, the community came in to work around it and also I don't know how they could bring up a proprietary application that has not made the Flatpak package themselves as an example, the whole thing is a community effort there apparently; etc. etc. (I'm not going to debunk all the others that are invalid, the internet is there for everyone)
-
KDE is starting to treat X11 users as second-class citizens
Can you be specific about the problems with X11? I've been using X11 for decades and it's been ROCK SOLID. And that is exactly what you want from something so essential. Wayland feels like an expensive boondogle, frankly. Wayland breaks everything and only provides 20% the functionality that X11. It also forces application and DE developers to implement special tools and solutions for wayland which have always been provided as a common interface by X11, like screenshots/ recording and screen sharing, e.g. https://github.com/flathub/us.zoom.Zoom/issues/22
-
Will this be fixed with the next linux 5.18 kernel? I'm only getting 2 hours of battery life while getting 5-6 on Windows 11...
Check this out https://github.com/flathub/us.zoom.Zoom/blob/master/zoom.sh
-
Screen sharing on Zoom (Wayland & Fedora 36)
Link to the github issue for the flatpak
-
Gaming on Wayland
More accurately, the developers need to a) fix their buggy implementation of the Gnome-specific protocol they currently use, and b) switch to the standard screensharing protocol.
https://github.com/flathub/us.zoom.Zoom/pull/182#issuecommen...
There is a lot of conversation about Zoom here: https://github.com/flathub/us.zoom.Zoom/issues/22
Apparently, there has been some recent activity via support channels. But I’d bet it’s probably not that difficult, just a matter of the team’s priorities to get to it. Then again, zoom isn’t very active or transparent in the OSS world, so it’s hard to say.
-
Flaptak (and Snap) is not the future
I agree that the implementation is lacking. Snap has the abysmally named "--classic" parameter to allow installs to "run without confinement". Flatpak can request permission changes at install time (albeit declaring them), where users are likely to just click OK/OK/OK. The sandboxing needs to be tightened up.
Flathub is a strange beast. There's no mention of security on their wiki. They stopped publishing minutes (or moved them elsewhere?) in 2017 (https://github.com/flathub/flathub/wiki). They have a buildbot for automated updates from developers, but they accept binaries anyway (e.g. https://github.com/flathub/us.zoom.Zoom/blob/master/us.zoom....), so what's the point? It appears to be a fairly amateur effort, and yet is at the center of the infrastructure Red Hat and Gnome are pushing. I'd love to see some white hat activity targeted at compromising it, to demonstrate the shaky foundations.
But on the other hand, it's nice that I can run Zoom sandboxed (apparently - it's not obvious what the granted permissions are: https://www.flathub.org/apps/details/us.zoom.Zoom). It's nice that Jetbrains and Zoom have a way to publish apps that can run on all distros. It's nice that I could rollback a version of IntelliJ that was buggy with a single snap command that took 5 seconds. The goals are good.
I wish Linus took more of a BDFL approach to the desktop occasionally. Ubuntu & Red Hat need to sit down in a room and have a constructive conversation to converge Snap and Flatpak into something new, deprecating the infrastructure built to date, and fixing some of the glaring problems. There's room for both to make money without further diverging the ecosystem.
-
PipeWire and fixing the Linux Video Capture stack
The weird screenshot thing also leads to confusing issues like this one: https://github.com/flathub/us.zoom.Zoom/issues/223. Zoom for some reason tries to avoid sharing its own windows by using an X window property that specifies the owning PID, so it filters out any window where `_NET_WM_PID == Zoon's PID`. Many different applications can think they have the same PID in modern Linux desktops when applications are sandboxed, so it ends up randomly filtering out other applications.
Not sharing its own windows is nice and all, but I don't think Zoom even does that on other platforms. It's weird how much effort they have put in to doing the wrong thing.
-
https://np.reddit.com/r/archlinux/comments/pk1e1y/zoom_display_issue_under_wayland/hc0lvl4/
That Flathub link from my previous comment shows you the zoom app. From there you’ll find a publisher link which takes you to repo where zoom Flatpak is maintained. This PR experimental PR enabled Wayland support.
-
Zoom display issue under Wayland
Sadly it seems you’ve run into a Nvidia issue. You could try using the zoom Flatpak, if that the normal version doesn’t work there is an experimental branch there that enables Wayland natively.
What are some alternatives?
peek - Simple animated GIF screen recorder with an easy to use interface
flathub - Issue tracker and new submissions
nix-gui - Use NixOS Without Coding
xdg-desktop-portal - Desktop integration portal
obs-studio - OBS Studio - Free and open source software for live streaming and screen recording
xdotool - fake keyboard/mouse input, window management, and more
xdg-desktop-portal-gtk - Gtk implementation of xdg-desktop-portal
flatpak-cve-checker
ScreenRecorder - ⏺️ A simple recording program with the ability to record screens and audio on your computer.
ssr - SimpleScreenRecorder, a screen recorder for Linux
Weylus - Use your tablet as graphic tablet/touch screen on your computer.
nix-bundle - Bundle Nix derivations to run anywhere!