Two problems with this post:
1. You complain about the new Debian, but you then say that it's "awesome". Please make up your mind. (Note that I do not consider sarcasm an acceptable excuse here, as I consider it to be equivalent to lying.)2
2. None of your complaints have anything to do with the kernel. (I *have* had a kernel related issue with buster on my laptop, but I worked around it by just booting the old kernel; almost everything else should still work on the old kernel.)

looks like a pattern when people can't take sarcasm and at the same time can't see the relation between updating your distro and getting new kernel.

let's see what's new with kernel 4.19
1. ACPI errors at querying bios ACPI and as a result no power-saving mode
2. mei mei can't initialize watchdog properly

I had no such issues with 4.9. and that's in addition to other mess that was shipped with this upgrade.

if anyone will try to update to buster make sure you're not using php7.0 otherwise you will be manually installing it from external repos, it is not shipped with buster (like phpmyadmin) and php 7.3 screws scrips with html parser.

And to think, you'd have these things fixed a year ago if you were on a distro that didn't rely on "maintainers" and "stability"

Meanwhile, in Fedora, Python 2 is actively being sunset. I'd hate to see how you'd deal with that. :B

I agree. and thanks for reminding me about the screensaver :) I removed it on stretch but it went back on buster, just to be removed again. not sure about Python 2, if that's Fedora then we have 4-5 years to consider better approach :)

What's a better solution for a depreciated codebase? Is this like the situation where someone claimed they could maintain the whole of Python 2?

Lazy solution for devs - someone maintains external repo and they keep using Python2 to code their apps till something breaks in dependencies. Ideally such apps call for an update to new version of Python but it can be done only for active apps. There's very little chance to see updated some old legacy apps. some very useful apps use Python2 - Bleachbit for example. Linux is getting too old :) We're facing the need to deprecate programming languages and that's always bad for those who learn coding and want to get a grasp of different versions of the language.
Why they have to kill Python2? it is still used. Like you can install php5 if you want, why can't we have same choice with Python? I feel bad when repos drop programming languages, it's missed opportunity for young geeks to learn.

I realize you're too low rep to post links, but maybe you can just give a textual description of this mystical site that knows all bugs in the Linux kernel (even if it is limited to just one version, at one time). If anyone else has that link, that would be great as well. Unless you're talking about the kernel bugzilla, in which case it's just a subset all reported bugs. Thanks.

what it has to do with keeping Python 2 in repos? you can screw your apache 2 config too, should we forbid its usage? learning is the process of getting familiar with subject, mastering subject. you don't have to be helicopter parent to complete strangers, everyone have to decide for themselves if they should learn this or that.

if you still haven't figured out, you *can* use eval() but with ast and by whitelisting expected behavior after it passed ast walk. Or don't ask user for their input :) Since when programming language have to hold user's hand and every feature have to be *safe*? It is the job of programmer to make it *safe*, not a job of the programming language.

The point I am responding is your claim that having Python 2 in the repo would be good for learning; it isn't, unless you already know how to program and expect to have to work with legacy code (like COBOL, but not *quite* as old).

The eval() example I gave is a situation where the default behavior is bad in most cases, and in particular is bad when you aren't aware of it. In Python 3 you can call eval() on user input if you really want to; it just isn't the default Python2 makes that dangerous practice the default, and requires typing a bit extra just to avoid it.

Also, the whitelist approach is dangerous; what if, due to a bug in your code (or in whatever ast library you're using; don't forget that even the standard library may have bugs!), something slips through that shouldn't? Also, what if the input contains characters that would be treated as special by the Python interpreter when passed to eval(), like apostrophes? Similar situations can easily happen in perl with the system() call (and in C, Python, and other languages, though it's easiest to do in perl I believe), or when communicating wth a SQL database (remember bobby tables?).

A couple web pages that are worth looking into about this sort of issue:
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ is about unexpected forms that user input can take. Or, if you'd like some specific examples, see https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/
https://xkcd.com/327/ is, of course, the xkcd that made bobby tables famous. (Possible interview question for someone looking for a SQL-related position: Show then the cartoon (there's a good chance the candidate has already seen it before), and ask what measures they would take to prevent this sort of mishap.)

why would someone try to code if they have no idea how to do that?

same question: if you don't know what you are doing why don't you learn first? people don't learn coding by guessing correct commands, there's learning and practice examples.

something can slip if you blacklist. if you whitelist you disallow everything by default and then allow one by one tested expected input. if something have slipped then you should be more careful next time :)

then you will have to use your common sense. if you ask user to enter their name or age or zip code it won't contain anything except expected symbols, it's your task to make sure you sanitize it properly. never trust user input - this gold rule is the first basic rule of coding. why you're making it an issue now?
similar situation can happen in any language if your command of that language is lacking. it's not the valid reason to remove such languages from repos. If you can't utilize given language to write secured code then use different language better suited for this task. every language has its uses even if it's of no interest for you.

And then Mr. O'Connor tries to register for your web site and has trouble because the web site does not allow apostrophes in names, but his name has an apostrophe.

(Also, read that article about names that I posted.)

My point is that wanting the language for learning purposes, which seems to be what you suggested earlier, is not a good reason to keep Python 2 around. If you are just learning to program, or are learning Python for the first time, you should be learning Python 3.

Also, when it comes to safety and security issues, there's the issue of how easy or difficult it is to use the language in a safe and secure way. Python 2's input() is hard to use safely; you have to write extra code to do so. By contrast, Python 3's input() is easy to use safely; it's safe by default, and only by adding extra code do you make it unsafe. Also, Python 2's version violates the principle of least surprise. (You wouldn't expect a call to input() to result in your home directory being deleted, but it is possible given the right input.)

Now, there *is* a valid reason for keeping Python 2 in the repository (though perhaps not in the default install), and that's to support legacy code, but that's really the only reason at this point. All new code should be written in Python 3 (unless it's part of a Python 2 project and upgrading the codebase to Python 3 isn't feasible), and anyone learning the language should start with Python 3.

(As a sidenote, Python 2's input() at least can be used in a safe manner with some work (though it's easier to just use raw_input(), which is the same as Python 3's input(); C's gets(), on the other hand, *can't* be used safely (unless you're able to strictly control the input, which is almost never the case), and therefore has no business being in the standard library in the first place. How it got into the standard library in the first place I have no idea, as it was a colossal design mistake from the start.)

if you're using Python for web development that's what you asked for :) I never said it is suitable for web development or for anything with user input.
how you would refactor old Python 2 code to Python 3 if you don't have means to run old code? are you aware that scripts written for v2 can produce different results if run on v3? by your logic we need to deprive ourselves from executing v2 in native environment because "it is not safe"? good thinking :)
I'm starting to think that you have to defeat *me* no matter what and you will jump on any topic and will defend any crazy statement just to make it happen. it won't. you're talking coding nonsense for dummies and I don't see how it can defend your initial point about removal Python 2 from Linux repos.

I never said that Python 2 should be removed from Linux repos; if you read my post, I said that the reasons you previously gave aren't the right reasons for justifying keeping it. (In particular, read the second to last paragraph of my previous post, in which I say that the only good reason for keeping Python 2 is legacy code, like those scripts that produce different results, or that code you need to update (there's a program called 2to3 that can help with some of that).)