If only…

Those are POSIX acls, and they suck

We could have had NFSv4 ACL, of which windows ACLs are a subset. In fact, every other unix os did… Except for Linux, they decided it didn’t fit well to Linux. And so we are stuck with UGO permissions, and posix ACLs.

I pronounce it spelling out only C H, but spelling them in my native language, so it sounds like “chee akka mod” and of course the same goes for “chee akka own”

Have you tried gnome connections? It’s more on the “quick and easy” rather than “professional” side, but maybe it does the job.

Tho I wonder whether it’s more of a windows-side issue… maybe windows 11 requires some kind of online authentication that cannot be implemented by other clients, and maybe this authentication can be turned off. I’m merely speculating here, but I know that remmina works for windows 10 so it’s suspicious.

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.

OpenWRT

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?

Try checking the sampling rate in your pipewire config. It should be 48000. I don’t remember exactly how to set it, check on the arch wiki.

Last time I had issues with digital audio that was it.

Flatpak 🤷

Kali user

found the problem

Wsl runs on hyper-v. I don’t think you can use it in a VM

I’m sure Carl is fine, I’m worried for everyone else though

Italy, 16€/month 5gbps down 600mbps up. Also I have a /60 IPv6, and a static but shared IPv4 (3 other users have the same IPv4 and each of us only get a range of 16000 ports) tunneled over IPv6.

Unix needed only \n because it had complex drivers that could replace \n with whatever sequence of special characters the printer needed. Also, while carriage return is useful, they saw little use for line feed

On dos (which was intended for less powerful hardware than unix) you had to actually use the correct sequence which often but not always was \r\n (because teleprinters used that and because it’s the “most correct” one).

Now that teleprinters don’t exist, and complex drivers are not an issue for windows, and everyone prefers to have a single \n, windows still uses \r\n, for backward compatibility.

Is this supposed to replace bluez?