The article only talks about Windows 11 Home. There might be exceptions for a Pro version.

How do I change the baud rate on this thing? Without recompiling and flashing the firmware?

Presumably you don't. You can probably hack something into the firmware to change the baud rate based on the port you're using to SSH in, but I haven't had any need to myself so I can't tell you.

The author does not seem to know f.e. Erlang.

Relevant section of the RFC: https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.3

Doesn't this enable ksm, instead of disabling it like the article suggests?

  echo 1 > /sys/kernel/mm/ksm/run

I think you're right. From the documentation [1]:

  set 0 to stop ksmd from running but keep merged pages,
  set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
  set 2 to stop ksmd and unmerge all pages currently merged,
      but leave mergeable areas registered for next run
  Default: 0 (must be changed to 1 to activate KSM,
             except if CONFIG_SYSFS is disabled)

[1] https://www.kernel.org/doc/Documentation/vm/ksm.txt

You are talking about certificates with subject alternative names. SAN has nothing to do with SNI (server name identification).

Do you have some examples for tools to handle the deobfuscation stuff?

The upgrade process of south was pretty shitty.

The documentation was telling something like: Ensure you applied all previous migrations and then start from scratch. Thats not an upgrade path. It may work for standalone web applications, but I have a python project (packaged as deb/rpm package and using the packaged django version of different distributions) that should work with multiple django versions and the user may upgrade the django version at any point.

I had to write raw sql statements to get the mirgration status of south (after the upgrade, without a working version of south anymore) and "fake" apply the migrations of the new native solution.

If you were supporting applications which needed to work with or without South at the time of the transition, the best thing to do was probably ship two separate sets of migrations (one set written for South, one written for Django's built-in migration framework).

Yes, that's what I am doing. The problem is, how to preserve the state of the migrations when the user updates the django version.

Then a new round is started and the final board is removed.

The certificates are signed with a SOAP-API. The the individual institutions do not have the keys for the sub-CAs.

The DFN will change this praxis while migrating to a new root certificate from "Deutsche Telekom" until 2019, but the staff at my university has major headaches. It's far more easier to document, that the members of the university should only trust (e.g. enter their password on) sites with a certificate signed by a CA with the same name as the university.