I think the heart of the problem is all these "no code" systems, fully commit into themselves and leave no room for traditional coding or scripting. I can't stress how much I hate "Flow" and "Power Automate" because of this. These systems need to be more like the Office/VBA marriage. Sure... you can do some mighty complex stuff in Excel... and spread your calculations and sub-calculations across multiple columns and worksheets and everything... BUT... if you know how to write some VBA code, you can do all that work in a macro much faster. Traditional Excel for the "benefit of businesses" and the "code" side for the power users and developers.

One of my favorite books. I read it for the first time back in 1994 I think, in college. I got my copy of the book from a friend and since lost it. I re-purchased it sometime in the 20-teens and after re-reading it, it still proudly sits on my shelf to this day. I recommend it to everyone going into cybersec. The book is amazing though. It covers account control issues, brute force, exploits introduced by uncontrolled software, honeypotting, and the somewhat hilarious examples of dealing with "the agencies" who in that day and age wanted nothing to do with things at first. It shows how a hacker will go out of his way to investigate leads and connect dots and spend hours upon countless hours exploiting every angle to accomplish their goals. A+++, can't recommend it enough.

Are you sure it's not telling you that you need to go into your computer's BIOS settings and enable the virtualization settings? It'll either be called "Intel Virtualization Technology" or VTT or VT-x or whatever AMD's equivalent is (AMD-V). Also enable VT-d and IOMMU is those are in there as well. Without those, things move a lot slower.

...also, which dead chicken you use is dependent on your distro. When in doubt, you may have to try all 500+ of them... but try them quickly. The longer you wait, the more seem to hatch! :-D

C# treats chars like an integer?? What happens if they're non-ASCII? What if they're unicode? Sounds to me like it's treating them wrong.

About time a language with modern syntax-parsing beats out one of those C-style languages with syntax still stuck in the 70's. I mean, semicolons at the end of lines?! Why does any compiler need to be told where the end of the line is these days?! Why the need for "=" and "==" when a compiler can be written to figure it out based on the context?! Compiler design is so advanced today compared to the era these junk-syntax languages were developed in, there's no reason for keeping this legacy garbage and inventing new languages that are restricted by it.

I always considered C#'s syntax moving backward in programming language design. Really, the only reason it exists is to appeal to legacy C and C++ programmers and programmers of any other language built on that ancient syntax like Java. People too lazy to learn a better, more modern syntax designed for more modern IDEs and compilers. Visual Basic is far more elegant and intuitive in it's syntax. Simple things like using "End While" or "End Function" rather than generic "}" lets you quickly see what functional block is what. LINQ is another example of being far more elegant in VB. I don't doubt that quote in the slightest.