229 karma · joined March 17, 2015
⿺辶⿳穴⿲月⿱⿲幺言幺⿲長馬長刂心
[1] https://en.wikipedia.org/wiki/Biangbiang_noodles#Chinese_cha...
I did actually prototype an idea for attempting to fix this. The tool would take a list of symbols from a text file and produce a (non-functioning) .so file that ld can link against. The newly created .so file can be injected in via an environment variable (LIBRARY_PATH iirc).
Since the list of symbols is just text, it's easily modified to contain only the one's that you want to target.
It's not a complicated tool to write, but there are some issues like how to reliably get ld to pick the correct .so file when you're overriding an existing on, LIBRARY_PATH is not 100% reliable. The other issue was if it's nessassary to recreate all the symbol types (like weak, etc..) exactly, I'm not sure exactly what's required for ld.
So I'm inclined to say that they have had a breach.
I guess I should get really around to getting the nvidia-vaapi-driver to work inside the decode sandbox, rather than requiring it to be disabled.
No sure it works on wayland though, not tested it there.
It's nice to use compared with grub, just edit a file and reboot. I've struggled to understand exactly how the fedora boot system is configured, and which command I need to run or file to edit to get it reconfigured.
foo | bar
STDOUT --> STDIN
ALTIN <-- ALTOUT
You could detected it by looking for specially number fd's open on program launch, or maybe an environment variable.Burrito: Taco:
edit No, it stripped those :'(.
Likely that PCIe switch IC they've got in there is a fair chunk of that price.
The device tree file does contain the range of memory to use for the PCI BAR, could it be as simple as increasing that number (the last value of the 'ranges' item I think) and rebuilding it? Seems unlikely, but might be worth a go. I'm uncertain how much the device tree file is describing the actual setup of hardware, and how much is used to actually configure the hardware.
The larger issue might be the complete lack of I/O space. Again this could be added in the device tree file, but who knows if the underlying device even supports it.
ffmpeg -activation_bytes <your magic bytes> -i inputfile.aax -vn -c:a copy output.m4a
You'll need to search around for how to find out your magic bytes, but it's not difficult. private static <T extends Throwable> T sneakyThrow(Throwable ex) throws T {
throw (T) ex;
}
Due to generic type erasure, the entire throw clause gets erased so it looks like this method doesn't throw anything.NetworkManager used to be configured to save it's config to /etc/sysconfig/network-scripts on Fedora, for backwards compatibility (see /etc/NetworkManager/NetworkManager.conf).
/etc/network/interfaces is the Debian alternative to network-scripts. I don't use Debian based distros much so I don't know too much about that.
There's also systemd's networkd, which has it's own config in /etc/systemd/network.
Honestly I'm surprised you've got a Fedora machine with networkd. Usually NetworkManager has been the goto choice (and is what my Fedora 32 install has, although this install has been upgraded from Fedora 23 so take that for what it's worth).
Most of this mess comes from ifconfig (which again, only operated on runtime state), which people then wrote scripts around to automate the setup of the networks. Then ip came along to access networking features that ifconfig couldn't.
You best off sticking to NetworkManager (in my opinion) for desktop usage. It has a far better GUI integration than networkd (which is fine for server/embedded use).
smartctl -a -d sat /dev/sda
Newer versions of smartmontools shouldn't need it, only the older one that Raspberry PI OS has.
There is a library that maps VA-API to VDPAU (their other video acceleration library), but that doesn't support DMA-BUF either.
I wouldn't hold your breath that this would ever be supported. It'll probably be easier to modify Firefox to use NVDEC directly, given that FFMpeg already supports that. But I don't think that'll be easy given their reliance on DMA-BUF for composition.