I have never had to do anything more than sudo apt install nvidia-driver, even with wacky setups such as:

• Nvidia GPU connected with an ExpressCard eGPU dock to a ThinkPad with integrated Intel graphics
• two Nvidia GPUs, an AMD GPU and an Intel GPU all in the same system

EDIT: debian btw

sudo apt install hollywood

no seriously install hollywood and run it it’s hilarious

There is no reason that you couldn’t, for instance, bind-mount the host’s nvidia drivers into the container namespace when launching the flatpak. Would avoid having to download the driver again, and reduce runtime memory pressure since the driver code pages would be shared between everything again.

A huge chunk of Linux development is subsidized by the hundreds of corporations which depend on it and pay developers to maintain things. There is no corporate interest in developing and/or maintaining an alternative browser engine when chromium already exists and dominates the market.

Y’all are too creative for me… I have:

• poweredge-r520-0
• poweredge-t620-0
• poweredge-t620-1
• pi4-0
• pi3b-0
• pi3b-1
• pi3b-2
• pi3b-3
• vostro-3525-0
• ideapad-c340-0

That’s ~2.4Gbit/s. There are multiple residential ISPs in my area offering 10Gbit/s up for around $40/month, so even if we assume the bandwidth is significantly oversubscribed a single cheap residential internet plan should be able to handle that bandwidth no problem (let alone a for a datacenter setup which probably has 100Gbit/s links or faster)

50MB/s is like 0.4Gbit/s. Idk where you are, but in Switzerland you can get a symmetric 10Gbit/s fiber link for like 40 bucks a month as a residential customer. Considering 100Gbit/s and even 400Gbit/s links are already widely deployed in datacenter environments, 300MB/s (or 2.4Gbit/s) could easily be handled even by a single machine (especially since the workload basically consists of serving static files).

I’ve got an old HP laptop which I’ve been running a Jenkins server on for years. The fan died back in like 2018, and I just kept putting off buying a replacement, so it has been running with no fan for 7 years now. Remarkably it still works fine, although a but slower than it used to thanks to thermal throttling :P

Roscoe is one of my professors at ETH, and he gave a keynote at VISCon a few months ago where he discussed this stuff and what his department is working on. Apparently a lot of their (they being the systems department at ETH) current work is related to formally modeling which parts of a system have access to what other parts, and then figuring out which of those permissions are actually needed and then deriving the strictest possible MPU configuration while still having a working system. The advantage of this approach over an entirely new kernel is that, well, it doesn’t require an entirely new kernel, but can be built into an existing system, while still allowing them to basically eliminate the entire class of vulnerabilities they’re targeting.

This guy (Roscoe) is one of my professors and I’ve heard him give a few talks related to this before, so I’ll try to summarize the problem:

Basically, modern systems do not really match with the classic model of “there’s a some memory and perhipheral devices attached to a bus, and they’re all driven by the CPU running a kernel which is responsible for controlling everything”. Practically every component has it’s own memory and processor(s), each running their own software independently of the main kernel (sometime even with their own separate kernel!), there are separate buses completely inaccessible to the CPU specifically for communicating between components, often virtually every component is directly attached to the memory bus and therefore bypasses the CPU’s memory protection mechanisms, and a lot of these hidden coprocessors are completely undocumented. A modern smartphone SoC can have 10s of separate processors all running their own software independently of each other.

This is bad for a lot of reasons, most importantly that it becomes basically impossible to reason about the correctness or security of the system when the “OS kernel” is actually just one of many equally privileged devices sharing the same bus. An example of what this allows: it is (or was) possible to send malformed WiFi packets and trigger a buffer overrun in certain mobile WiFi modems, allowing an attacker to get arbitrary code execution on the modem and then use that to overwrite the linux kernel in main memory, thus achieving full kernel-level RCE with no user interaction required. You can have the most security-hardened linux kernel you want, but that doesn’t mean a damn thing if any one of dozens of other processors can just… overwrite your code or read sensitive data directly from applications!

As I understand it, the goal of these projects is basically to make the kernel truly control all the hardware again, by having them also provide the firmware/control software for every component in the system. Obviously this requires a very different approach than conventional kernel designs, which basically just assume they rule the machine.

This is specific to page reclamations, which only occur when the kernel is removing a block of memory from a process. VMs in particular pretty much never do this; they pin a whole ton of memory and leave it entirely up to the guest OS to manage. The JVM also rarely ever returns heap memory to the kernel - only a few garbage collectors even support doing so (and support is relatively recent), and even if you have it configured correctly it’ll only release memory when the Java application is relatively idle (so the performance hit isn’t noticeable).

Yeah, it’d definitely be faster while pages are actively being moved to swap.

This probably won’t make much difference unless your application is frequently adding and removing large numbers of page mappings (either because it’s explicitly unmapping memory segments, or because pages are constantly being swapped in and out due to low system memory). I would suspect that the only things which would really benefit from this under “normal” circumstances are some particularly I/O intensive applications with lots of large memory mappings (e.g. some webservers, some BitTorrent clients), or applications which are frequently allocating and deallocating huge slabs of memory.

There might be some improvement during application startup as all the code+data pages are mapped in and the memory allocator’s arenas fill up, but as far as I know anonymous mappings are typically filled in one page at a time on first write so I don’t know how relevant this sort of batching might be.

Tangentially related, but I recently stumbled upon this GitHub repository and seeing this same xkcd in their README had me giggling for like 5 minutes

Investors won’t be interested in that, it sounds too complicated. How about /dev/null as a Service?

Debian-based distros (and probably most othera as well) actually have a package called “intel-microcode” which gets updated fairly regularly.

I search for stuff in qBittorrent and download it directly onto my home server using the web UI. I’ve got most of my family’s devices set up to be able to access it either via an NFS or SMB mount, and then it’s just a simple matter of opening the corresponding video in VLC.

Couldn’t that just as easily be solved with a database of illnesses which can be filtered by symptoms?

Traditional graphics code works by having the CPU generate a sequence of commands which are packed together and sent to the GPU to run. This extension let’s you write code which runs on the GPU to generate commands, and then execute those same commands on the GPU without involving the CPU at all.

This is a super powerful feature which makes it possible to do things which simply weren’t feasible in the traditional model. Vulkan improved on OpenGL by allowing people to build command buffers on multiple threads, and also re-use existing command buffers, but GPU pipelines are getting so wide that scenes containing many objects with different render settings are bottlenecked by the rate at which the CPU can prepare commands, not by GPU throughput. Letting the GPU generate its own commands means you can leverage the GPU’s massive parallelism for the entire render process, and can also make render state changes much cheaper.

(For anyone familiar, this is basically a more fleshed out version of NVIDIA’s proprietary NV_command_list extension for OpenGL, except that it’s in Vulkan and standardized across all GPU drivers)

“Better” in the sense that it actually has the ability to check for corruption at all, as all metadata and data are checksummed.