no-panic uses link-time shenanigans to prevent panics in the compiled binary, but this isn't 100% reliable (as explained in the README, just pointing this out)
The user you replied to likely means something different: The priority of the event often depends on the exact contents on the event and not the hardware event source. For example, say you receive a "read request completed" interrupt from a storage device. The kernel now needs to pass on the data to the process which originally requested it. In order to know how urgent the original request and thus the handling of the interrupt is, the kernel needs to check which sector was read and associate it with a process. Merely knowing that it came from a specific storage device is not sufficient.
By the way, NMI still exist on x86 to this day, but AFAIK they're only used for serious machine-level issues and watchdog timeouts.
When it comes to exchangeable lens cameras (DSLRs/DSLMs), as you increase the number of pixels you very quickly reach a point where you're limited by the optical performance of the lens instead of the sensor. Lots of systems offer a choice between a 24MP and a high pixel count camera (e.g. Nikon Z6/Z7), and you'll find that the high pixel count sibling requires very good lenses to actually achieve a meaningful improvement over 24MP. For these cameras, common wisdom says to stay with 24MP apart from certain niche use cases.
In other words, I wouldn't expect a improvement in capturing actual 48MP pictures in phone cameras, apart perhaps from pixel binning to a smaller size and similar techniques.
Disclaimer: I haven't followed camera tech very closely recently, and I'm not an expert. Take my opinion with a grain of salt.
Isabelle/HOL has Quickcheck, which is precisely what you think it is. Although it only works if the free variables in the thesis you'd like to prove are sufficiently simple AFAIK (think integers or lists). The more powerful alternative to Quickcheck is Nitpick, which is a purpose-built counterexample finder.
The workflow you'd like already exists one to one in Isabelle: You can simply type "nitpick" halfway through a proof and it will try to generate a counterexample in that exact context.
Of all the BSDs, I'm only a little familiar with OpenBSD through its OpenSSH fame, so I'm a little surprised to hear that a (probably) somewhat related project would use XML in a system call. In other words, if an OpenSSH release introduced XML as a wire format I'd assume it to be an April fools's joke. [1] But I guess OpenBSD and NetBSD are less related than I thought.
When choosing a bowl for your potato salad, you need to keep some important properties of potato salad bowls in mind. Different bowls have different designs that make some better suited to storing potato salad than others. For example, a higher quality bowl might have been manufactured to a higher standard than a subpar bowl. You might also want to choose different bowls depending on the amount of potato salad you want to prepare. There are bigger bowls and smaller bowls, differing in size and thus in the amount of potato salad they can accommodate. A smaller bowl is great when you're aiming to cook for just a few people, while a larger bowl is ideal for bigger groups. Brand name bowls like the classic SALADBOWL(tm) are preferred by some potato salad fans, while others appreciate the great price offered by newer, less established brands. Keep in mind that while a cheaper bowl is more affordable, it can also break more easily, so it's not a bad idea to compare the warranty period offered by different manufacturers.
Disclaimer: Not a native speaker, I hope I got the annoying structure of those "what to look for when buying X" blog articles right...
Based on its name I think it's used in Arch Linux packages (at least makepkg says it is generating an mtree file at some point during the build process IIRC). However it appears mtree (the tool) isn't packages, so perhaps it's only using the mtree specification format?
I'm not familiar with how it compares to ARM/Intel's profiling tools, but I found the Linux perf suite to be very capable (though limited to Linux obviously). And Hotspot [1] allows effortless profile visualization using flame graphs, including some very interesting features such as off-CPU time profiling [2]. "perf record" coupled with Hotspot forms a very smooth edit-compile-profile cycle.
I'm a little confused on how this tutorial somehow explains several tasks at completely different levels of difficulty (setting up a VM, installing a compiler via apt-get, modifying/updating the bootloader, building a custom kernel, and finally creating a new syscall) with a relatively constant depth of explanations.
It's difficult for me to judge the usefulness of this guide because I'm familiar with those steps, but I'm wondering if it might have been better to define a more narrow scope for this tutorial with certain prerequisites, and going into detail about the ramifications of adding a new syscall? Especially since I feel the guide barely mentions a few interesting details:
1. Only arch/x86/entry/syscalls/syscall_64.tbl is modified in this tutorial, glossing over the fact that that file only affects x86_64 syscalls (disclaimer: I'm 90% sure on this one, but don't quote me on this). Of course I wouldn't expect the tutorial to explain how to modify all the architecture-specific files, but I'd say this fact is worth noting.
2. The user-space story: The post doesn't mention how to actually use this syscall - even though that's one of the critical parts of a syscall. Essentially, if you call open() in a C program, you're not actually issuing any syscall directly. Rather the C library (e.g. glibc) implements an open() function that internally performs the syscall. This is primarily because many syscalls don't map 1:1 to C library functions, in addition to some differences between platforms and architectures. So if you'd want to use the syscall you'd have to implement a syscall wrapper yourself or use the low-level syscall(2) [1] function that allows you to access system calls not provided by glibc.
There is also some political drama attached to this, essentially the glibc maintainers don't want to implement/provide functions for certain Linux syscalls because of certain reasons (IIRC it's mostly about portability concerns, but I think there are some syscalls that the glibc maintainers just don't like for whatever reason).
3. The "What if you really wanted to add a syscall to Linux?" story, which boils down to: The Linux maintainers don't want to add any new syscalls except in very few cases (because syscalls generally can't be changed once they're introduced). Instead, you're supposed to use more flexible kernel interfaces, such as sysfs or debugfs (or previously, ioctl and procfs, but they're frowned upon nowadays and only used in certain areas). See the Linux documentation on adding syscalls [2].
In contrast to the current sibling replies, I think this is a very fitting categorization of documentation. Off the top of my head, I can think of several examples where one type of documentation is excellent but others are very lacking, for example:
* Rust Library Documentation: Most libraries have complete and up-to-date reference documentation, but are lacking even basic introductions (tutorials/guides) on how to use the library. This is totally just my personal experience so maybe I've been looking at the wrong crates, but with most of the crates I spend several minutes looking trough all the modules in order to find that all the juicy functions are hidden in the Connection struct, or something similar.
* Linux Kernel Documentation: The Linux kernel has excellent in-depth explanations on several high-level concepts, but on the other hand a little more systematic reference documentation on the supporting library code would help a lot.
* While I can't think of a good example right now, a lot of projects have a few basic getting-started tutorials but don't explain advanced concepts or high-level design at all, leaving you to wade through the sources yourself in order to understand how to actually use them.
This is incorrect, TUM has a PET scanner (site in German): https://nuklearmedizin.mri.tum.de/de/Patienten-Zuweiser/Pet-... Can't comment regarding the other observations.