Yea, for most CEOs, I have no idea what their politics are because they don't wear it on their sleeve and make it part of their company's brand. I can probably guess their politics, but it's not going to affect my purchase decision.
There are a handful of CEOs who just can't seem to keep it to themselves, to the point where they're just begging for people to include those politics in their purchase decisions.
It should be sad but not shocking. They deliberately campaigned on causing maximum destruction, grief and chaos, and frequently used the phrase "we're going to make so much money." It was totally transparent and out in the open what the plan was, and people voted for that plan.
He's been doing this for years. Change the name from something widely used/adopted to something brand new and watch who follows along. Anyone who starts using the new name is a friend, and anyone who doesn't is an enemy.
Trans people typically whose a new name, referring to their old name as their “deadname”. People who insist on using the deadname when they know the person has a new name are deliberately mocking, and even being cruel to, the person who has changed their name.
Musk continues to refer to his trans child by their birth name and gender. I can’t understand how someone would do that to their own child (much less anyone at all).
After purchasing twitter he chose for it a new name and wants everyone to use it, but by not bothering to I’m simply following his example.
It's not about whether or not "Super" makes sense. He could have just as easily changed the name to "potato." The point is to change a commonly-used word to something else, and measure who follows along. If you go along with it, you're a loyal friend, and if you don't you're an enemy.
It's like the Facebook -> Meta rebrand, Facebook was a dirty word at the time while Meta wasn't (gosh that didn't last long though) so it was an attempt to try and get rid of the accumulated negativity and hope that searches for the topic of Meta only returned bland and positive results instead of dredging up the many ongoing court cases.
As long as 3.11 can be "embraced" without breaking on 3.10. As a user, I might still have 3.10 installed and be happy with it, or be stuck on a system that tops out at 3.10. Unpopular opinion on HN, but I really dislike "I can break users on X because Y is now out" policies :(. I guess I'm always free to just stick to an older version of the application that still supports X.
My policy is that if the Python version isn't supported then I don't have to take steps to support it either.
If you're stuck with 3.10 that's fine, you'll just be stuck with the versions of my packages that I released prior to October 2026.
Thankfully Python packaging has metadata which means "pip install X" will continue to get you the most recent release which is compatible with your Python version.
Realizing this is the thing that gave me the freedom to finally stop worrying about all of those stale installations.
That's only the interpreter released by the Python Software Foundation itself. I can't even remember how long its been since I installed their interpreter but probably at least a decade. In recent years its been Miniforge and before that was Anaconda (before they changed their licensing terms for orgs with 200+ people).
That said, its fair enough to drop support for a particular version whenever you want. I'm merely pointing out that there other providers of Python interpreters that are both widely used and support older versions longer. Other folks mentioned OS distributed doing the same already, but personally I don't use the system interpreter and just leave it alone for whatever the distro needs it for.
Because my software is better if people who are running a supported-but-not-most-recent Python can use it. I'm willing to inconvenience myself a little for their benefit.
Older versions of Python packages don't stop being available, they just become unsupported. Nothing stops you from using those versions that still work fine on your older Python installation. It's unreasonable to expect free support indefinitely for open-source packages, especially since that would produce an O(n^2) maintenance burden with the emergence of new Python releases.
Even relatively conservative Linux distros, for example, will only leave you with an unsupported-by-the-core-devs system Python for a small fraction of the cycle. For example, Mint 21.x (which distributes Python 3.10) will be EOL at the end of next April.
I suppose the word "support" has many meanings in software. When I say I wish more developers would keep support for old platforms, I don't mean "provide human technical support" to users on old platforms, or even "continue building features" for those old platforms. Just wish they wouldn't deliberately break them.
EOL doesn't mean the software vanishes from the face of the earth, although we seem to be quickly moving to a world where once the OS vendor EOLs a platform, developers take that as a signal to break everyone on that platform.
I know, open source = I'm not entitled to anything, which is why I say "wish" instead of "demand."
> Just wish they wouldn't deliberately break them.
I don't think anyone™ goes out of their way to explicitly break things for old Python versions.
It's usually more like "oh cool I can make this code faster/more readable if I use this feature. I don't have to care about the old version anymore so I will do that."
If you really to super duper need a backport, you're in luck: python is an interpreted language whose source is in plaintext, on your local machine.
> I don't mean "provide human technical support" to users on old platforms, or even "continue building features" for those old platforms. Just wish they wouldn't deliberately break them.
Okay, but that isn't happening here. There isn't even a real way Python developers could do that, even if they wanted to. That isn't how Python package management works.
When the developer wants to start using features from a new Python version, that requires a new release with a higher version number. The old one is still available, and all standard package tooling will restrict itself to the package versions compatible with your Python version. And the ecosystem standard is to restrict yourself, for current releases, to features available in currently supported Python versions (which is why Simon is talking about 3.11 features and not 3.15 ones, or even 3.12 ones).
If you're writing or packaging software for a specific OS that bundles an old Python, then there's sometimes a reasonable argument for wanting to retain compatibility with that old Python. But now that uv has started bringing some sanity and relative ease to Python package management, it's not much hassle for end users to start running a Python newer than the one shipped by the OS when they want to use a tool or library that requires a newer Python or performs better on a newer Python.
You have to draw the line somewhere though. Python 3.10 is over 5 years old. Is upgrading your system once every 5 years too much to ask? Should webapps still support Internet Explorer 6?
You don't even need to upgrade your system. You just need to be willing to install another newer Python alongside whatever versions you already have, as a dependency of whatever newer tool you want to run.
If python interpreters masqueraded as versioned .so libraries, we probably wouldn't even be having this conversation, because having multiple versions of those lying around is ancient precedent.
How was this even allowed by the judge? I wonder, if AI videos weren't a thing yet, would the judge allow one of the parties to bring in an actor dressed up and made up to look like the victim to offer testimony?
Not sure I understand the site. Each option just shows a grid of names (like a Zoom call) but there's no audio or video. The "How It Works" section implies there's audio at least, but not working on Desktop Firefox / Linux.
Yea, having trained my muscle memory for at least 10 years on macs, my daily driver desktop is finally a modern Linux distro, and I'm having the most trouble with un-learning the ⌘ shortcuts. On Linux, sometimes "copy/paste" is CTRL-C/V, sometimes it's SHIFT-CTRL-C/V (meaning I need to position my pinky AND ring finger like I'm playing guitar or something). In terminals it's never CTRL-C/V, and once in a while there is an application where it's something bonkers. I kind of miss the universal ⌘ shortcuts that the entire macOS system and all 3rd party apps followed.
i'd suggest trying out toshy... it's a game changer for linux. you get almost all of the mac keyboard shortcuts working out of the box. there's a few rough edges sometimes but generally it feels like you're using a mac wrt shortcuts. even stuff like diacritics and textbox emacs shortcuts work if you want.
Yea, I've been having a blast with a RTL-SDR and Claude, telling the LLM to analyze interesting looking signals and try to figure out what they are, and (sometimes) finally successfully decoding them. I'm picking up a bunch of knowledge from the process too, to the point where I'm learning how to do some of the analysis myself.
It's such a low-stakes hobby, and I don't need to care about collaboration or "efficient progress." The local HAM radio group is a bunch of elderly guys who just talk about Trump and their sore backs, not my cup of tea. For some things, you can have plenty of fun alone in your computer room.
There are a handful of CEOs who just can't seem to keep it to themselves, to the point where they're just begging for people to include those politics in their purchase decisions.
reply