The discussed issue is not related to any meaningful difference between Windows and Linux – Crowdstrike used a kernel driver, apparently containing a serious bug, which took down the system, which is something any kernel driver can do, no matter which kernel you use. At least Windows have a well-developed framework for writing userspace drivers, unlike Linux.

> Linux being the most advanced operating system in the world without question.

Very strong and mostly unfounded claim; there are specific aspects where Linux is "more advanced", and others where Windows come out ahead (e.g. almost anything related to hardware-based security and virtualization).

> your system will be supported for many years

Windows Server 2008 was supported until earlier this year, longer than any RHEL release.

> you won't suffer BSoDs in 2024

Until you install a shitty driver for a dubious (anti)malware service.

Not a good comparison, given how bad of a track record in "adapting" the truth the vlang author has.

This is a myth.

V compiles itself in <1s, can translate entire DOOM, has a working kernel/OS (Vinix), 10k+ PRs, 600+ contributors etc.

While the bad track record you mention is about junk like git/libc dependencies and system("curl") (doesn't happen).

Can you list actual lies?

Math experts are not necessarily good cryptographers, and authors of MTProto were not renowned cryptographers (unlike with Signal).

Most people in the cryptographic community agree that the Signal protocol is well-designed, is widely believed to be secure, and the authors react openly and swiftly to potential issues. Meanwhile, a lot of the MTProto crypto is just weird (that is, it does not follow standard practices of the field, without strong reasons to do so), and many cryptographers treat it with suspicion.

With aliases, powershell can be quite terse as well, and since it's case-insensitive, you can just type everything in lowercase.

E.g. instead of the script presented in the article:

    (Get-ChildItem -Filter '*.txt' | ForEach-Object { $_.Length } | Measure-Object -Sum).Sum

You can do

     ls *.txt | measure -Sum Length | % Sum

From a quick read through the source code, .NET seems to use CommandLineToArgv, so the behavior is the same. Additionally, the behavior of internal parsing in the CRT and CommandLineToArgv is very similar, and from my experience, it's easy to escape arguments in a way where both interpret them the same way (it's dumb that there's a difference between the two in the first place, but it only really comes up with manual input).

In practice, with the exception of `cmd.exe`, which is an old beast that cannot be redeemed due to backwards compatibility, there is a consistent way to round-trip argv to more-or-less all programs one encounters in the wild. It's not a guarantee and I'm sure you could find a program which does something weird, but you could find the same in the POSIX world. In both cases, we can probably agree that it's the mistake of the program that it's parsing arguments in a non-standard way.

More compact example (not to scare the POSIX people away :) ):

    0..1000000 | where {$_ % 10 -eq 0} | foreach {"Got Value: $_"}

The streaming behavior of the range operator is weird though. This is tested on PowerShell 7.4.1

    > 0..1000000000 | % { $_ }
    # Starts printing out numbers immediately
    > 0..1000000000
    # Hangs longer than I had patience to wait for
    > $x=0..100
    > $x.GetType()
    # IsPublic IsSerial Name     BaseType
    # -------- -------- ----     --------
    # True     True     Object[] System.Array

It's an array when I save it in a variable, but it's obviously not an array on the LHS of a pipe.

Not exactly. Non-native PowerShell pipelines are executed in a single thread, but the steps are interleaved, not buffered. That is, each object is passed through the whole pipeline before the next object is processed. This is non-ideal for high-performance data processing (e.g. `cat`ing a 10GB file, searching through it and gzipping the output), but for 99% of daily commands, it does not make any difference.

cmd.exe uses standard OS pipes and behaves the same as UNIX shells, same as Powershell invoking native binaries.

Oh, that's what I missed! I managed to find out about it while trying to do an equivalent of `curl ... | tar xzf -` in Powershell. I was stumped. I guess the thing is that a Unix shell would do a subshell automatically.

I'm using AutoHotkey as my own custom IME, allowing me to type special characters, navigate in text and switch between applications without leaving the middle 3 rows of the keyboard: https://github.com/MatejKafka/KeyboardRemap/

The README contains layout diagrams if anyone's interested.

You might find the QtRVSim simulator interesting:

- WASM version: https://comparch.edu.cvut.cz/qtrvsim/app/

- source & native releases: https://github.com/cvut/qtrvsim

It visualizes the inner workings of a basic RISC-V CPU, you can choose a basic single-cycle CPU, or a full 5-stage pipelined CPU with a hazard unit.

I also recently wrote a 5-stage RISC-V CPU in SystemVerilog, the implementation should be reasonably well-commented:

https://github.com/MatejKafka/risc-v_pipelined_cpu

Here's a modal remap I've been using for the past few years. It's a bit rough around the edges, but should work reasonably well: https://github.com/MatejKafka/KeyboardRemap