Hacker News Reader

Hacker News

Comment by throw0101a | Hacker News Reader

Parent Full thread

throw0101a

> The risk of unpatched vulnerabilities

If a company as 'small' as (pre-IBM) Red Hat can afford to support Python 2.7, then so can Apple:

* https://developers.redhat.com/blog/2018/11/14/python-in-rhel...

* https://access.redhat.com/solutions/4455511

Further, if Debian has the resources to support Python 2.x, then so does multi-trillion dollar company of Apple:

* https://packages.debian.org/search?keywords=python2

If they wanted to announce at the June 2022 WWDC that macOS 13 wasn't going to have it, that's fine. But we're several months into macOS 12.x and such a large change is bad form.

View on HN

They literally did that, in 2019: https://developer.apple.com/documentation/macos-release-note..., and specifically mentioned *then* that Python2.7 was not recommended.

Yes, and I was surprised when Monterrey launched with Python 2 still included.

But I really did think that since it was in Monterrey, it was going to stick around until at least macOS 13.

They probably had a major customer who needed it for some wacky reason.

Let's face it: at this point macOS version numbers are a marketing tool, and not much more. It's only 2 major releases ago that a "x.y" release *would* have been considered "major".

I don't think that's particularly relevant. It was pretty clear that between 10.0 and 10.15, the second number was the "major" version for all intents and purposes, and now it's the first number.

Maybe they can afford it, but why should they?

Yep. Comparison is not good since Red Hat et al. focus a lot on server side.

To offer a good service. To avoid breaking something the users depend on.

Apple isn't in the business of spending excess money to avoid breaking things. If anything apple is the opposite.

Apple supported Python 2 for two years after it was officially sunset by the Python Foundation. They've been advising that they will drop support for longer.

How long is long enough to avoid breaking something the users depend on? One more year? Five years? Fifty? I think we can all agree that it's reasonable to drop support at some point, making it just a question of when and at what cost.

Again, the issue is "when", not "whether".

They could drop it with v12, or wait for v13, both would be fine. Dropping it in the middle of release cycle what people are objecting to.

"How long is long enough to avoid breaking something the users depend on?"

10 years - a piece of software compiled with 'supported' libraries, SDKs and what have you should function for 10 years. An appliance or a service should function for 10 years and have spare parts avaliable for that long.

That is the guideline I ise as a consumer, if I can see that something won't last a decade, I won't be spending money or time on it if i can avoid it. At that point it's no longer a durable good, it's a consumable.

Python2.7 was supposed to be EOL in 2015(!). It was released in 2010. It had 10 years of support mainline.

There would still be Python 2.7 software being produced up to EOL, so you have to start counting from 2015.

If there are users that still depend on python 2.7, they can install it manually?

I mean I already think it's... interesting that an operating system comes with (multiple) programming language interpreters, available to the end-user.

That’s true if they’re using it from the command-line, but not if they’re using apps that linked against the system SDK’s libpython2.7.dylib (and assumed PyObjC would be present)

Is there any significant software still using that?

Apple is pretty aggressive about breaking backwards compatibility, as they did with x86, so it's no real surprise for unmaintained software to become completely unusable.

Notably, however, Apple didn't drop x86 support in a minor update.

And kept the support present for I think a year and a half alongside a runtime warning message (and removed SDK support earlier than that)

Based on what they’ve done, I guess the answer is no.

My company was shipping (somewhat niche) software linking with the built-in python2 up until last year though, and it’s been a scramble since Monterey to rebuild things to avoid the warning message. Definitely thought we would have python2 until 13.0 though (and part of me wonders whether this is just a “brown-out” for the beta and 12.3 release will be back to normal)

> programming language interpreters, available to the end-user.

Yeah, fuck those end-users who might want to automate things with a script.

I think an end user that wants to automate things with a script can be expected to install their interpreters themselves or use an interpreter that builds on the OS's shell.

I am not to familiar with MacOS, but I imagine it comes with a bash/sh terminal? If so, then that is something that should be first choice for automation.

Everything else, be it python, perl, ruby or whatever should be installed by a user as needed.

And I think that's totally reasonable—as long as Apple makes the change in a major update, when users can expect (some) things to break and should be encouraged to make time to prepare.

Part of it is that it's just a mental burden to keep this kind of compatibility information in my brain. I have VMs set up of past macOS releases in case I need to run something old. I don't have VMs set up for earlier versions of a release, and I don't even know where I'd get an installer. Admittedly, in this case it would just be a matter of installing Python, but I don't necessarily know that as a user, or the software could need to be linked to Cocoa or some such.

What do you think “the OS’s shell” is?

That's what Windows is for.

Bingo. This falls under the scope of support for an enterprise linux company-- orgs pay them to keep stuff backwards compatible long after the upstream deprecates it. Apple is decidedly not an enterprise support organization. RHEL also doesn't want you using system python as your dev python. RHEL 8 uses 'platform-python' for the bits the system needs and if you install 3.6, they share the common bits If your using a mac as a dev box, and really need python 2.7, you still have options.

Supporting stone age system administration tools is basically Red Hat's core business though. That doesn't really seem like a fair comparison.

Debian drops the support of Python 2 starting with Bullseye ([0] and the supported versions list below):

NOTE: Debian 11 (bullseye) has removed the "python" package and the '/usr/bin/python' symlink due to the deprecation of Python 2.

[0] https://wiki.debian.org/Python#Python_in_Debian

Python 2 is still available in Bullseye:

* https://packages.debian.org/bullseye/python2

There has been no dropping of support: if you want Python 2.7 you can install in.

They don't bundle Python, it has to be installed separately.

macOS is going the same way, except that Apple doesn't have a package manager so it has to be a manual installation.

This is false. Homebrew is no different from any other open source package manager.

There is no need for a manual installation.

>> except that Apple doesn't have a package manager > This is false. Homebrew is no different from any other open source package manager.

Just to quote the literal slogan of homebrew:

>The Missing Package Manager for macOS (or Linux)

I think it is fair to say that Apple does in fact not have a package manager. Unless they do bundle homebrew with their OS nowadays?

You quote a marketing slogan. “Missing” in the sense that Apple doesn’t ship it.

> Apple doesn't have a package manager so it has to be a manual installation.

The quoted statement is clearly false. To maintain that python has to be installed by hand is incorrect.

Apple the corporation doesn’t have a package manager.

MacOS, the ecosystem does.

No different from Linux. There is no Linux package manager. There are numerous open source package managers for Linux.

> Apple the corporation doesn’t have a package manager. > MacOS, the ecosystem does. > No different from Linux. There is no Linux package manager. There are numerous open source package managers for Linux.

macOS the OS has a package manager in terms of a tool to install packages. It does not have the ability to find/download packages to install though.

In the sense of a package manager being able to download and install additional software, macOS has several choices available but none of them are included with the OS, or have the ability to update the OS.

There is arguably no single "Linux ecosystem". There are numerous Linux-based distributions, which are largely comparable to macOS as an OS. One of the very key differences between each family of distro's is the package manager the OS ships with by default and uses to update itself.

So no. macOS does not "have" a package manager that's comparable to those included by default with linux distributions, but there are several third party package managers available for it.

> or have the ability to update the OS

A red herring that is nothing to do with what we are discussing.

> It does not have the ability to find/download packages to install though.

Another false statement. Homebrew is just as capable of searching as any Linux package manager.

> Another false statement. Homebrew is just as capable of searching as any Linux package manager.

I wasn't talking about homebrew.

It helps if you understand the comment before you reply to it and make accusations.

Edit to add, because fuck the HN timeouts. Heaven forbid someone make 6 comments in two fucking hours:

Try reading the whole fucking comment again, with the points being made really hammered home for you:

> macOS the OS has a package manager in terms of a tool to install packages. It does not have the ability to find/download packages to install though.

This is about the built in macOS package manager, that the OS itself uses to install packages. It's invoked via `installer` on the command line, or Installer.app in the GUI. It does not expose the ability to find/fetch packages from remote URLs.

> In the sense of a package manager being able to download and install additional software, macOS has several choices available but none of them are included with the OS, or have the ability to update the OS.

This is referring to homebrew, macports, etc.

We certainly do see things differently, because only one of us is repeatedly calling the other a liar due to poor reading comprehension.

If you don’t include homebrew, as a package manager for MacOS, then you aren’t having a serious conversation.

This whole line of conversation is about whether it’s necessary to manually install python.

If you claim it is you are lying, because it can easily be installed via homebrew, and you are clearly aware of that.

If you have some need to claim that homebrew isn’t a MacOS package manager or that MacOS doesn’t “have” homebrew, because Apple doesn’t ship it. Go right ahead, but it’s a red herring.

MacOS the thing that comes preinstalled when you buy a computer from Apple doesn’t have a package manager. You have to install one yourself, manually.

By that logic MacOS doesn’t have any third party software at all.

No, it means that macOS and its third party software aren't one in the same thing.

Is faker.js a macOS vulnerability because there were people using Macs who installed npm and then installed faker.js? This isn't a theoretical question—whenever you install something, you need to consider where it's coming from and whether they can be trusted.

MacOS has third party software.

MacOS has homebrew as an open source package manager.

It has a third party package manager, yes. I'm pretty sure your parent meant that there isn't a first party one.

On Debian, packages in the official repositories are considered to be literally part of the Debian project. The maintainers are considered Debian maintainers, and bugs go into the Debian bug tracker.

This matters due to the trust issues I alluded to above. It also means that on Debian, there is one definitive version of Python (or at least one per Python version). The Homebrew, MacPorts, and Python.org Python binaries are all slightly different, such that it's possible for software to work with one but not the other.

No two Linux package managers are identical either, and not all Linux distributions work like Debian. Debian is a collection of volunteers. The choice to trust it is no different to the choice to trust Homebrew. Considering the package manager to be part of Debian doesn’t change this.

However none of this has any relevance to the claim in question, which is that python must be installed manually.

MacOS certainly has a package manager that can install and maintain python.

Except that most other open source package managers strive to be good at what they do.

Brew has a long history of treating any criticism of their truly woeful approach to security, dependency management etc, with "well fuck you we dont want to hear your opinion".

There were other better macOS package managers before it; macports was sort of even Apple sponsored.

Everyone switched to brew even though it was the most poorly designed because it came from the Rails hype era where everyone wanted all their tools to be written in Ruby and didn’t care about anything else.

Yeah no kidding.

I used and still use macports, but there were valid reasons to switch to homebrew: macports did not have precompiled packages, did not use system libraries, and machines were not as powerful as they are now.

This meant if you wanted to install, say, ImageMagick, you would spend one day compiling stuff.

Also contributing a brew recipe was (and probably still is) easier than contributing to macports, and brew casks are pretty convenient.

I deeply dislike some of the choices of homebrew, but I can understand why it was popular, and it wasn't just because of the ruby hype.

Bad form is coding against system binaries...

Just because someone has the resources to do something it doesn't mean that doing so is the right {business, technical} decision. You're confounding the two.

{business, technical}

Very HN: Business || technical. No concession for "Customer service."

Customer service is still a business reason. It serves to keep your customers happy, and the calculus here is probably that there aren't enough customers to keep happy by maintaining python2.7 that would justify the costs and headache.

You can't please everyone

Reply on news.ycombinator.com