So dogs work just like omegaverse fiction ๐ค
edinbruh
joined 2 years ago
AMD has an nvdec/nvenc equivalent called AMF, on Linux it's going to be deprecated in months in favour of va-api.
To my knowledge, it does not have an nvfbc equivalent. Which anyway, Nvidia has deprecated on windows in favour of a windows-native screen capture with a name I don't remember.
For what is worth, va-api encoding + kmsgrab works pretty well for me, it does have some latency, but nothing too unacceptable. Probably less than the one caused by the Bluetooth controller. And none of this is vendor specific, you can get it working on Intel, AMD and Nvidia (Nvidia needs a compatibility layer, but it works). Also, it works on Wayland, but sunshine needs some privileges to work.
Sunshine supposedly supports nvfbc with patched Nvidia drivers, even on Linux, I haven't tried it, so I don't know if it works on Wayland. I don't see why it shouldn't, as long as you give sunshine privileged permissions (like you need for kmsgrab). Even without nvfbc you can use nvenc, so you don't need the va-api compatibility layer.
Supposedly, since this Nvidia driver release nvfbc is used as backend for pipewire screen capture, so it should just work for apps like OBS, I don't know if sunshine has intention to move to it.
In general, screen capture on Linux pretty much works, even on Wayland. The general sentiment that it's broken is actually old news.
There's a caveat though. Proprietary apps tend to use outdated stuff (e.g. electron builds from 5 years ago) and thus don't support screen sharing on Wayland.
It doesn't replace the editor, it creates a stream and opens it in your default text editor. When you write out, it saves the stream to an appropriate drop in file
Fstab is still there untouched, it's the temporary units files that get replaced at reload.
The mount program works as normally, if you edit fstab and then mount -a it will work as expected, it will just warn you that systemd is not aware of the change. It will reload it anyway at the next boot.
daemon-reload is not daemon-restart, it just makes systemd re-read the configuration to make it aware of the changes, but the services don't get restarted. Some services (e.g. nginx) can re-read their confuration without restarting, those services are also made aware of the changes when reloading and can be reloaded individually.
You can edit any systemd units using systemctl edit so you don't need to reload (fstab is not a systemd unit)
Fstabs gets converted into temporary unit files every time systems reloads config files (reboot or daemon-reload) so you can just keep using it like you always did. Actually it's the systemd suggested way to manage mountpoints unless you need something advanced that fstabs can't do.
Gambling society and its future
Systemd does one thing, it manages services, and does so reliably, without messing around with spagettified shell scripts, with a fuckload of options, and all of that easily is configurable by dropping in files without editing stuff that arrived from the package manager. Seems pretti "do one (complex) thing and do it well"
If you add other things built around it, it can do more. For example, if you install systemd-nspawn it can start and stop containers like it starts and stops services.
Other things that you think of as systemd are entirely separate things (like systemd-networkd) that are just built around systemd. You don't have to use them if you don't like.
On the other hand, you know what does not follow the Unix philosophy? The Xserver, which manages screens, graphic acceleration, input devices, printers, remoting, etc. And it doesn't even do it well
The hardware still needs to be brought up and initialised. But the software is the real problem here. The kernel gets fully up in seconds, but then you have to initialize the rest of the OS
The pc ecosystem is modular by design. The kernel will figure out itself the available hardware, moreover there are only two major CPU manufacturers (in the pc space of course), which means you have only two platforms to support.
Mobile phones instead are not modular, they use SoC. While most common socs are from Qualcomm and mediatek, there are a lot more smaller manufacturers. Plus, even if most often they use the same reference design for compute cores, the rest of the soc is often custom and wildly different from others. All of this to say that the kernel needs to already know exactly how the specific soc of the device works, instead of figuring it out on the fly. Which is why you need to check compatibility.
The brick thing instead is because the bootloaders in these devices are usually very locked down, so sometimes you need to replace the bootloader with a more open one, with all the risks that this entails
Did you solve this in the end?
view more: next โบ
https://youtu.be/xlrOB88A-ZA