I'm not saying CachyOS is bad, just that it is in my opinion another layer of complexity that may change/deprecate/etc.

Have your lost your old configs that you worked hard on? That's a shame if so. I love moving my configs I've worked hard on to new machines and instantly getting up and running in a now-familiar environment. It saves so much time and effort.

I have a server which has many peripherals and multiple GPUs. Now, I can use vfio and vfio-pcio to memory map and access their registers in user space. My question is, how could I start with kernel driver development? And I specifically mean the dev setup.

Would it be a good idea to use vfio with or without a vm to write and test drivers? How to best debug, reload and test changing some code of an existing driver?

Realistically speaking, most files I have in my cloud are read-only. The most common file that I read-write on multiple devices is my keepass file, which supports conflict resolution (by merging changes) in clients.

Also used to happen when I tried editing some markdown notes using obsidian on PC, and then using text editor (or maybe obsidian again?) on android, but I eventually sort of gave up on that use-case. Editing my notes from my phone is sort of inconvenient anyway, so I mostly just create new short notes that I can later edit into some larger note, but honestly can't remember the last time this happened.

But yes, if not careful, you could run into your laptop overwriting the file when it comes online. In my case, it doesn't really happen, and when it does, Nextcloud will have the "overwritten version" saved, so I can always check what was overwritten and manually merge the changes.

P.S. If anyone wants to set this up, here's my nixos config for the service, feel free to comment on it:

  # don't forget to run `rclone config` beforehand
  # to create the "nextcloud:" remote
  # some day I may do this declaratively, but not today
  systemd.services.rclone-nextcloud-mount = {
    # Ensure the service starts after the network is up
    wantedBy = [ "multi-user.target" ];
    after = [ "network-online.target" ];
    requires = [ "network-online.target" ];

    # Service configuration
    serviceConfig = let
      ncDir = "/home/username/nextcloud";
      mountOptions = "--vfs-cache-mode full --dir-cache-time 1w --vfs-cache-max-age 1w";
    in {
      Type = "simple";
      ExecStartPre = "/run/current-system/sw/bin/mkdir -p ${ncDir}"; # Creates folder if didn't exist
      ExecStart = "${pkgs.rclone}/bin/rclone mount ${mountOptions} nextcloud: ${ncDir}"; # Mounts
      ExecStop = "/run/current-system/sw/bin/fusermount -u ${ncDir}"; # Dismounts
      Restart = "on-failure";
      RestartSec = "10s";
      User = "username";
      Group = "users";
      Environment = [ "PATH=/run/wrappers/bin/:$PATH" ];
    };
  };

I understand, they have UI kits, books, etc. but just fundamentally, it was never going to be easy to monetize around that long term, with or without AI.

I think they're aware of and like D :)

I agree that D has gotten a bit complex. We're introducing the notion of "editions" in order dispose of obsolete and unnecessary features.

For example microcontrollers or aerospace systems.

Everything is manual.

I get you people are trying to be cheeky and point out all modern OS’s don’t have this problem but C runs on a crap ton of other systems. Some of these “OS” are really nothing more than a coroutine from pid 0.

I have 30 years experience in this field.

Without virtual memory, I would either need to force the use of a garbage collector (which is an interesting challenge in itself to design a GC for a flat address space full of stackless coroutines), or require languages with much stricter memory semantics such as Rust so I can be safe everything is released at the end (though all languages are designed for isolated virtual memory and not even Rust might help without serious re-engineering)

Do you keep notes of these types of platforms you’re working on? Sounds fun.

The good news is that this work is dying out. There isn’t a need to modernize old war birds anymore.

I haven’t looked at C3 yet, but I imagine it can’t be used in a formally verified toolchain either unless the toolchain can compile the C3 bits somehow.

I provided the C solutions as well but an interpreter written in C could at least allocate objects and threads within the interpreter context and not leak memory allowing you to restart it along any services within which is apparently better than whatever framework people sharing this sentiment are using.

I'm genuinely curious. What kind of mission-critical embedded real-time design dynamically(!) allocates objects and threads and then loses track of them?

PS: On topic, I really like the decisions made in C3

But no, tell me I’m wrong, tell me I’m an idiot for doing things this way, put me down for asking, and then deny my reality when I tell you.

This is why people dislike software engineers, they think they know everything.

You drop a keyword and the aero-drones report. I do not mind it and I am not going to reply in kind.

I have 0 experience in aerospace but reading up on ARINC-653, it appears to mandate a reasonable RT design with threads and hard slices. Even comfortable with "partitions".

Where and why does the memory leak? If it is inherent in the mandated interfaces, you don't need to feel personally attacked.

If it is a layer laid down by your software –whether legacy or otherwise– why can't you keep track of allocations and ownership? Unless there are 200 bytes left and all slices are accounted for and running on the edge, I feel a solution could be worked out.

I wish you luck switching to Rust maybe a Rust2C translator could help.

As an adult I just couldn't be bothered buying this again year over year, let alone even once. I'm dropping the site instead of going to the store to buy this. Guess I'd just go fully offline.

Correct.

Umm...good? You'll have better mental health.

It is lexx/yacc style lexer and parser generation and generates an LR1 parser but using the CPCT+ algorithm for error recovery. Iirc the way it works is that when an error occurs, the nearest likely valid token is inserted, the error is recorded and parsing continues.

I would use this for anything that is simple enough and recursive descent for anything more complicated and where even more context is needed for errors.

What drew me to the grmtools (eventually contributing to it) was that you can evaluate grammars basically like an interpreter without going through that compilation process. Leading to a fairly quick turnaround times during language development process.

I hope this year I can work on porting my grmtools based LSP to browser/wasm.