HMH

Yes, that does help a little. But how much depends on your threat scenario: If you just don't want your ISP to know what you are doing or hide your true IP from some web site you are probably good but if you want to avoid online tracking the situation with a selfhosted vpn may even be worse as your server probably has a static IP address and makes you easy to identify. Also note that once you login into some website with and without vpn it is easy to connect you to your server.

From my experience wireguard is pretty easy to setup. For what purpose do you want to setup your own vpn though? If it is for privacy reasons this is probably a bad idea because most likely the server that will run the vpn software will be linked to you. And if you are the only person using your selfhosted vpn, it is trivial to identify you.

Yes, that's correct. Weylus itself is only responsible for input and screen mirroring. The program you can see in the GIF is Xournal++.

I mostly agree with the sentiment. The thing that really bugs me is that configuring DNS system wide is broken like that.

Yes you are right, input lag is definitely lower. I don't have numbers though as it is kinda hard to measure.

I think something that definitely is still missing is an obvious way to migrate existing communities over to lemmy as gracefully as possible. Some kind of bridging, perhaps via bots, would be nice and it looks like I am not the only one thinking this: https://github.com/LemmyNet/lemmy/issues/1542

Rust eliminates a lot of memory safety problems at compile time. Roughly speaking once you allocate memory and assign a variable to it, that variable "owns" said memory. A variable owning memory is responsible for its lifetime and just like in many other programming languages once it goes out of scope, the memory is released.

So far so boring. What makes Rust different is the borrow checker. It ensures that all references (equivalent to pointers in C) to some memory (in this case not owned), are always valid. Like that it is impossible to access invalid blocks of memory in (safe) Rust. You never have to wonder who is responsible for deallocating memory and you never have to fear dangling pointers as those simply do not exist in Rust.

I am sure there is much more to it, but this is certainly one of the arguments.

I am not exactly convinced of this:

• The GiHub repo is empty (only a Readme and LICENSE) and I can not read the source code
• Apparently it is just an electron wrapper, so I would not call this native
• Looks like it just uses https://github.com/nativefier/nativefier, so there probably really is no added value to just using your browser

Yes, Weylus is very similar but open source and works on Linux :)

Some numbers I can give you: X11 Screen capture: ~1ms VAAPI video encoding + capturing: ~12ms NVENC video encoding + capturing: ~10ms End to end video latency over WiFi to iPad: ~50ms (Measured by taking a photo of both screens with a timer running)

Tested on a Dell XPS 15 with a screen resolution of 1920x1080.

On Android devices you can reduce the latency brought by WiFi by using USB tethering or adb, see the FAQ.

Yes, you are right, youtube-dl should be at a recent version :P! But I hope that this is all the maintenance there is to it. The script itself is really simple and probably won't need updates any time soon as it just delegates all the work to other tools. Just as things should be with regard to the Unix philosophy :)

This is very impressive work indeed. I have done some development around screen recording on Wayland myself and it's been a rather painful experience. Similarly to what's described in the blog post I have also hit quite some bugs or missing features.

What's also interesting is that OBS directly interfaces with pipewire. The process with xdg-desktop-portal is a request for screen recording permission that opens a popup and once the user grants permission you get a file descriptor, which is a handle to a pipewire remote. That means so far there is no need to actually use the pipewire API at all.

Actually you can even use another library and let it handle the pipewire related things. This is what I did, pipewire ships with a gstreamer plugin and like that there is no need to interface with the rather unstable pipewire API directly and instead the stable API of gstreamer can be used.

As OBS doesn't do this the devs will have to put in quite some more work to keep up to date with pipewire. But I understand why they directly interface with pipewire. Like this they can share dma bufs to display the screen faster and far more efficiently.