traxys

Could be that the new 100% and 0% are something like the old 80% and 20%

"nightly" versions also allow to use unstable features, and unstable features may remain so for a very long time (potentially forever) without breaking, so an old nightly could maybe work

I read parts of the Linux kernel source code pretty often, and getting the definition of a function is often pretty involved:

- I don't always know the return code type, as the calling code assigned a field whose definition I don't know to find either

- I don't know if it's a C function or a preprocessor macro

This often results in me searching for the exact function name, and combing through the uses in the drivers. You then need to re-start all that recursively to understand the function you just read.

I could use clangd for that, but I don't have the ressources on my laptop to compile a kernel

I have not really thought too far ahead, I know quite a bit about Linux internals, so when in doubt I tend to follow what was done there. I have not though very far in how to handle most of syscalls, traps, drivers, ...

Thank you for the static site generator! The code highlighting should be very similar to the tokyonight nvim colorscheme, as it uses mostly the same colors & tree-sitter queries as it!

Well yes, but I the main idea of this series is to use no dependencies in order to have a deeper under standing of the entire stack, from boot to GUIs (that is a long term goal!)

Well this part did not have much RISC-V in it, as it builds upon the abstractions of part 2, which had lots of assembly!

I think they meant if you cast a pointer to an integer, do some math on that and then store that. Then you will a stored result that will likely differ from run to run

I think in High-Performance Computing a lot of the networking NICs behave in that way, because you are 100% sure that you know the fabric layout.

Stuff like InfiniBand, HPE Slingshot, Atos BXI, ... There is a consortium that's building a specification for those kinds of things: https://ultraethernet.org/

I got bitten many times by the fact that PATH is not taken into account, because I use Nix to manage by dotfiles, including `clangd`, but when developing libraries that target the base distro (not Nix) clangd sometimes gets confused and does not taken into account the headers in /usr/include, only the Nix headers....

I had a situation where I'm not really sure I could have used something else than null: I need a value in one of two columns exactly (meaning one is NULL and the other not).

You can build a constraint to check that if it's in the same table, but across tables it seems to be a bit more complex right ?

Targeting a RHEL kernel version is quite different than targeting the same official kernel version as they backport a huge number of features, resulting in drivers that may work in RHEL but not upstream, or the reverse

I packaged some python applications in nixpkgs, and it seems the consensus is to try and relax the dependency so that the globally packaged version is used, but if it fails the you can override the version yourself. Though this is not done through the requirements.txt because that file does not have enough information (no integrity hash for example).

In High Performance Computing the most recent Top1 machine ils counted in Exaflops, so there's quite some talk aubout exascale computing.