The differences between distros in fact break scripts that need to refer to these tools by their absolute paths, which includes anything called from cron where the value of PATH can be anything and systemd services, or any script where use of relative paths is risky for security reasons, exactly to avoid malware in /home/user/.local/bin, for example.

So for all sense and purposes, the current state is broken. Your suggestion that will foil script kiddies, while in theory plausible and potentially having occurred some times, is ridiculous and is an example of security through pseudo-obscurity. If your security relies on your script kiddie not knowing where update-alternatives is, your system lacks any security.

On the other hand, the fix will temporarily make things more broken, as now people referring to tools with absolute path and using Fedora (or Arch) will not know where the tools are supposed to be, even for tools where the path was previously consistent across distros and will hardcode /usr/bin/fsck, which in Debian would be in /usr/sbin/fsck (and if someone hasn't yet performed their /usr merge, even /sbin/fsck). Which means Arch and Fedora will be compatible, but not Debian, and Debian will be forced to also merge them eventually.

I did mention phones, because Nautilus is usable devices like tablets as it has touch-friendly navigation, with an adaptive interface that hides the sidebar on small screens like a phone. They've recently almost fixed the constant issue where the window would become too big to fit on a screen by adding a lot of ellipses, though some other parts of GNOME (the file picker, for example), would become too wide to fit any screen by simply navigating into a directory whose name is too long.

As an avid user of orthodox dual-pane file managers (far2l, Midnight Commander, Double Commander, and Krusader when using KDE), I am not sure of it. Allow us to have file managers that are best suited for the task at hand and best fulfilling the preferences and needs of the user.

Some tasks --- editing files, watching video files, managing files on a phone screen, rarely even some file organisation within subdirectories --- are best accomplished with a single directory view, without a second pane taking up your real estate. Opening a second window to take the job of a second pane is a minor hassle if suddenly required, and can be much more flexible --- sometimes you might need three of four, or to close and open more of them as needed. Some single-pane file managers even offer opening a second pane with F3 (Dolphin and pcmanfm, for example), and this is valuable, but it is neither that much significant improvement over opening a second window, nor does it offer the power of a primarily dual-pane manager like the ones I mentioned.

It might be prudent to have such mode in all file managers, but even when everything in my life is dual-pane I seldom use it, because every operation in a truly dual-pane manager is aimed at the presence of exactly two panes. Copy, move, symlink are aimed at the opposite pane (as opposed to drag & drop with windows, or with an F3 split), macro actions can be created that reference the active and inactive pane, or left and right pane (useful for making diffs), comparison and directory synchronisation features may be also provided. That's the true value of the design, so simply splitting the view does little to give you that.

On the other hand, single views --- splitable or not --- are great for what they do. Sometimes you just need smaller window, sometimes you just need independent views where a dual pane wouldn't be the best fit, sometimes you even more than two. I've even been in a situation where I needed to run multiple instances of a certain dual-pane FM (because of the macros I had in them, or the ability to use them over SSH), and all operated in a single directory, the second pane sitting there eating screen space for no reason.

Perhaps you forgot to check that argumentum ad populatum is still a logical fallacy in 2021.

My company makes up some of those 80% powered by PHP, I make my salary supporting PHP web sites and coding PHP code myself, I even like some of the overall language, and PHP happens to be the first language in which I coded any non-toy programs.

Yet it is still pretty much THE shitty language. A primer on how you DO NOT create a programming language, from security hell to just absurd language features that trip you on every step. You wouldn't need to look past what kind of absolute crap has to be fixed with breaking changes in each major release that's came out in recent years. For example, the recently released PHP 8 fixes the absolute insanity of PHP comparison operators: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.php.net%2Fmanual%2Fen%2F...

Before this change (and since PHP 8 compatibility is not here yet in popular libraries, you can say it is still the case), you would struggle with BASIC things like checking for an empty string:
if ($s == '') // WRONG, if someone passes 0, it will evaluate to true, yet result in non-empty string
if ($s === '') // WRONG, if someone passes false or null, it will evaluate to false yet result in empty string
if (!$s) // WRONG, if someone passes "0" or 0, it will evaluate to true yet result in non-empty string
if ((string) $s == '') // CORRECT (though it could probably result in an error in a number of cases, good by me)

That's what we're fixing in 2020/2021. In the decades, it's a language that brought absolute wonders like magic quotes, which would any mangle any input string with C-style escapes, in the false belief that this protected you from SQL injections. SQL injections resulted from this, yet it also brought the joy of web sites in which passwords containing " or ' or \ would not work, because they would be “escaped”, and your password would differ from what you actually typed.

Mind you, when that was happening, the default MySQL library didn't even contain the ability to pass parameters to queries. And when parameters were added with MySQLi, it happened with an over-engineered complicated system that totally discourages you from using it. Now, to add query parameters, you individually bind each of your query parameters to a variable, which it now references, and can set to whatever value you want. That's powerful, but complicates code for passing simple parameters, thus discouraging people from doing so, and still writing vulnerable code. To this day.

And if you're going to say that these are things of the distant past, think again. MySQL has been fixed, but shell commands still haven't been - on POSIX, there's no way to safely run a command composed out of execl() arguments, it always goes through the shell. Not only that invoked shell vulnerabilities like shellshock in the past, it means you have to carefully escape every argument, individually, with escapeshellarg(), which breaks badly on different locales, and is still prone to the programmer forgetting an argument, as with SQL queries without parameters.

To make it all harder, changes brought to fix these gaping holes of the language have been done in ways that would be disruptive to existing code, and done so often, all the while support for earlier releases have been made short. In other words, we break your code, and break it often. When magic quotes was removed, so was the ability to turn it off, making attempts to do so a fatal error, and complicating the upgrade between two versions that both lack the stupid thing.

Or, along with wanted fixes to the comparison operators, PHP 8 decided to make the signatures of methods during inheritance mandatory. Now, that technically makes sense, but in a language where you can dynamically take and pass the arguments, the new PHP version rejects code that does so with a fatal error, thereby breaking scripts that are correct. It's probably still the correct change, but add that to the fixes for outstanding issues that are also breaking, you're looking at a never-ending stream of breaking changes. And all code needs to be updated within a couple of years, because support for the PHP versions without the breakage is dropped fast. It's better than the Python 2 to 3 transition, which was one big pain in the ass, but at least that one you could put behind you. The PHP breakage is an ongoing process, and I have no confirmation it is done yet.

And let's not forget that the majority of GNU/Linux malware happens on PHP installations. And while the bad security of PHP scripts is not a fault of the language (except when it is, see above), and while the tendency of PHP users to download outdated unauthorized copies of commercial software even less so, PHP has become nesting grounds for malware. That's on top of the database leaks in which it has been complicit.

There wouldn't be any ninth planet, as such a body would be a dwarf planet!

Look, son, a planet is a solar system body that needs to have cleared its neighbourhood. That be virtually impossible at the proposed orbits even for a gas giant-sized body.

Look, you don't go all the way in introducing a half-cooked* definition just to disqualify Pluto as a planet as it didn't look like one to you just because you thought excluding it explicitly would feel arbitrary, and then immediately ignore your own definition when a thing that looks a planet to you becomes possible to exist.

* The definition doesn't even account for extra-solar planets, as it requires planets to orbit the Sun.

Yes.

‘INTER-UNIVERSAL TEICHMÜLLER THEORY I:CONSTRUCTION OF HODGE THEATERS’

‘The goal [...] is to establish anarithmetic version of Teichmüller theory for number fields equipped with an elliptic curve—which we refer to as “inter-universal Teichmüller theory”— by applying the theory of semi-graphs of *anabelioids, Frobenioids, the étale theta function, and log-shells* developed in earlier papers by the author. ’

The majority of terminology and constructs that follow is totally lost on the others working in the same field.

Of course, outputting 1000.0 MB and 1.0 GB for different values of bytes is an issue, but fixing it doesn't mean the choice of threshold to change unit makes the result making more sense. The snippet still prints different sizes with different precision. 981.3 MB has 4 digits of precision, whereas 1234 MB will be printed as 1.2 GB, reducing the number to only 2. That's way more serious either whether cosmetically you get 1000.0 MB for some weird corner case.

So your solution to some innocent people getting murdered is... Murded enough innocent people until someone notices?

Right, Linux audio works nowadays. Almost. Except when PulseAudio starts corrupting audio. Or stops outputting audio. Or hangs. Or forcibly mutes my headphones, requiring me to call amixer after PulseAudio has started. Or requires me to re-learn something that I learnt to do with ALSA, and now I need to start over. And except when GUI tools decide to hide ALSA devices when PulseAudio is running, ruining my ability to unmute my inputs or fine tune my volume control in many other ways.

And I can't "stop using PulseAudio", because:
1. When somebody asks me for help with their audio, I can't simply go and uninstall it every time.
2. Certain distributions, such as Ubuntu, make it extremely difficult to remove PulseAudio.
3. Even distributions like Debian do install it automatically, so you need to ban it in /etc/apt/preferences.d. I learnt how to use APT pinning solely for getting rid of PulseAudio. That should speak volumes for how broken it is.

Funny enough, I was using PulseAudio long before it became popular, because it was arguably the best network audio server for casual use. I had to stop doing that because it started breaking the sound in many applications, playing with my volume, etc. It was also funny when the authors decided that the mode in which I was using PulseAudio (as a system-wide daemon) was "unsupported", and asked distros to get rid of their init scripts, thereby breaking my dedicated sound server. Not that it isn't trivial to fix, but why would anyone remove a feature in that manner? It was probably the distros fault, since Debian are still keeping the init script, but I wasn't using Debian at the time. One day I had my sound server working, and the other day I was greeted with a message telling me what I was doing is a bad idea and I should stop doing it ASAP.

That should read “vote Gary Johnson”.

Ron Paul doesn't believe in evolution.
Ron Paul doesn't believe in a government-funded space program.
Ron Paul doesn't believe in the right of a woman to control her own body.
Ron Paul says he stands for civil liberties, but all that he wants to do is transfer the takeover of civil liberties to the states government.
Ron Paul is ready to go against the status quo by applying unusual ideas, but he's not willing to adapt those ideas to the real world. Some people would argue that this can be nearly destructive.

Gary Johnson carries a similar message, but he's more reasonable, has proven himself as a governor, and has far less gotchas in his policies. He also has a chance of making a difference - while he could not win, he can get his party noticed, and could have an effect on the policy of whoever gets elected. Ron Paul is now only seen as a clown of the Republican party.

Of course, Gary Johnson has a few problems of his own - like his stance on Net Neutrality, but the rest of his stances make up for that, and make up for it by much.

OpenVPN beats both solutions.

Everyone knows that the cloud formation is caused by a rocket launch.

It's very much likely that it tastes like an elephant. Just like how an ape tastes almost like a human. (The brain is the most tasty part if you eat while the specimen is still alive)

Not really. Although completely frozen, the mammoth flesh was terribly rotten. And even the Russians who sometimes enjoy a piece of slightly rotting meat found it totally unpalatable. It was so rotten it was utterly uneatable. I believe it's an exaggeration to say anyone ate a part of it. It was so disgusting that they could not go that far. And even if they did, fresh mammoth meat's taste would be completely different.

The problem with the GIL has the same solution as the problem with speed: C extensions can turn off the GIL and run multithreaded.

Granted, that's not a great solution if your CPU-heavy code is a lot code using Python dictionaries for example, but you still have the option of doing what Guido suggested.

And for those who say that this is just a hack - the heavy loop and/or the part with the GIL switched off can be written in a language like Cython. It has Python-like syntax, it supports a subset of real Python and can have subsections that translate into pure C. So the end result will still be consise, won't look like a hack. You also have the option to implement your whole module in Cython in many cases, with optimisation directives only for the respective part.