It has an LTS kernel. Not a separate version. This does not make everything LTS. This is very different from LTS distros.

I don't think there is a good license for that. The ones MongoDB used turned the open source community against them. But that is not really my point. I just mean that some projects using MIT won't suddenly mean every company will start stealing and closing that software. Some things like coreutils and sudo just don't have the commercial value to make that worth the effort. So there is no real need to worry about these two projects IMO. Other projects are a different story altogether though. Each project needs to make its own decision on what licence best suits it. The GPL is not the one and only license that is worth using.

I have more then once gave up on pressing up, hit ctrl + c to reset only to see the command I wanted briefly flash up as I am hitting ctrl + c

That is a month to fully cure. It should be dry to the touch before then, though that can still take weeks at worst. Keep it in a warmer and dryer place if you can as that will speed it up.

Upon reading the article I think the title is just misleading.

What titles are not these days?

You don't need to worry about that in rust. Cargo is built from the ground up to understand package versions and downloads/builds the right versions for each project. The global package caches understand versions and can cache multiple versions of each package. Where as python just uses one or more global stores of packages shared by all projects. venv is basically there to isolated these package stores along with the version of python which can have breaking changes between different releases (this is something rust avoids at all costs so you can upgrade it without worrying as much as with python).

What? You can easily escape from it if there are better alternatives you can use. Pointing at one language and saying it is not easy to code like it is another language is a pointless argument. You can do that about any two languages. They all differ for good reasons and as long as you can solve similar problems in both, even if in different ways then what does it matter that you cannot do it in the same way?

It doesn’t technically have drivers at all or go missing. All supporting kernel modules for hardware are always present at the configuration level.

This isn't true? The Linux kernel has a lot of drivers in the kernel source tree. But not all of them. Notably NVIDIA drivers have not been included before. And even for the included drivers they may or may not be compiled into the kernel. They can and generally are compiled with the kernel but as separate libraries that are loaded at runtime. These days few drivers are compiled in and most are dynamically loaded depending on what hardware is present on the system. Distros can opt to split these drives up into different packages that you may or may not have installed - which is common for less common hardware.

Though with the way most distros ship drivers they don't tend to spontaneously stop working. Well, with the exception of Arch Linux which deletes the old kernel and modules during an upgrade which means the current running kernel cannot find its drivers and stops dynamically loading them - which often results in hotplug devices like USB to stop working if you try to plug them in again after the drivers get unloaded (and need a reboot to fix as that boots into the latest kernel that has its drivers present).

Creating functions is IMO not the first thing you should do. Giving variables better names or naming temporaries/intermediate steps is often all you really need to do to make things clearer. Creating smaller functions tends to be my last resort and I would avoid it when I can as splitting the code up can make things harder to understand as you have to jump around more often.

Not technically. unetbootin and some similar tools like rufus take the USB, partition it, and copy the contents of the disk to it after manually setting up a bootloader on it. This is not required for most Linux ISOs though where you can just cp or dd the image directly to the USB as they are already setup with all that on the image. But other ISOs, like I believe Windows ones have a filesystem on them that is not vfat so cannot be directly copied. Although these days for windows you just need to format the USB as vfat and copy the contents of the windows ISO (aka the files inside it, not the iso filesystem) to the filesystem.

I tend to find unetbootin and rufus break more ISOs then they actually help with though. Personally I find ventoy is the better approach overall, just copy the ISO as a file to the USB filesystem (and you can copy multiple ones as well).

Theoretically you could build a male to male contraption from multiple adapters and a cable.

You already can as these exist:

letting you plug in any existing USB A to mini cables together to get a male to male device - nothing unsafe about that though. So this is not a very good reason to not allow USB C to mini adapters.

Also you could be providing too much current to a device, however this is specific to the combination of adapter, cable and power supply you use.

Current is pulled by the device - you cannot supply too much current. Devices take just as much current as they need or as much as the adapter can supply. The only way a device would take more than that is by badly designed or faulty - but that is a problem with the device, if the power supply can supply the power there is no issues on that side.

Also USB C connectors can and do by default operate with USB 2 power - supplying 5V and limiting the current to the USB 2 standards and so any existing charger with USB A or mini connectors on. Thus any USB 2 device will only have access to the power given by the spec. You would require a handshake from newer USB protocols to get access to more voltage/current that some USB C chargers can supply.

There is nothing unsafe about any other this baring faulty devices - but if we worried about faulty devices then we would not allow any electronics devices to exist as any of them could be faulty. USB C to USB mini does not dramatically increase any risk of fire or devices exploding no more so than any device using USB mini or USB C alone.

The real reason is there is likely just not much of a market for them so they are harder to find - but they do exist.

But a big problem with this dataset is error handling - or really the complete lack thereof. Real code needs to deal with errors and they can add a lot depending on the language.

I was very surprised to see rust and go so close as I find go vastly more verbose due to error handling and need to reimplement things like searching a list. But code golf type problems ignore these types of things that you see in real code.

So there is not really and useful conclusion that can be made except if you spend all day writing code golf problems.