[wuunderbar]

I may be missing something here, but why would you need to change the stock installed tools in /usr/bin? Seems like an easy way to screw up your OS installation. And it's not like a VM where you can rollback to a snapshot or relaunch.

If there really was an issue there then you either need to file a bug and have them mainline a fix, or yes hack/shim a fix on top for your needs. Perhaps leveraging PATH precedence.

[luma]

Embedded in your response is the general attitude one hears when concerned about not being able to do "a thing" in the Apple ecosystem: why would you want to do that?

Questioning the use case and insisting that one doesn't actually _want_ to do a thing instead of allowing the user to control their own system is the quintessential Apple experience.

[qeternity]

You can still do this thing, you just do it a different way that doesn't fundamentally risk breaking the OS. I understand that there may be some non-zero sized group of people who absolutely want to screw with protected OS files, and even for this group of people you can go and disable SIP and mess with the OS all you want (one of the Macs I have is a hackintosh, which requires some decent modification).

However most people, including me, and I'd venture most engineers too, would rather have a hardened system.

[AnIdiotOnTheNet]

> Embedded in your response is the general attitude one hears when concerned about not being able to do "a thing" in the Apple ecosystem: why would you want to do that?

Funny, that's a quote I hear a lot in Linux Desktop ecosystems as well. I think it is just the nature of people so accustomed to a certain way of thinking that any other use case that comes along is automatically considered to be doing it wrong.

[msla]

Linux doesn't have a single desktop ecosystem. Apple very much has One Apple Way.

If Linux is going to get attacked for not having a single GUI, it would be nice if it weren't also attacked for having a repressive GUI monoculture. /s

[groby_b]

Apples open source devtools are old as dinosaurs, so that might be a common case.

But more importantly, it's the question whose laptop it is. I continue to think that the tools I build go to /usr/bin, because that's the way I like it. Apple is telling me I'm liking it wrong.

As for filing a bug with Apple - good one. Every single Apple dev considers radr:// a black hole, and the chance of getting a fix from Apple because of bugs filed (vs. Apple wants to fix it anyways) is slim to none.

Overall, Macs are more and more machines that want to prevent shooting yourself in the foot, at the price of less flexibility and access. This is a good choice for some, it's not a good choice for me. (And many other people who like hacking their machines)

[Hamuko]

>Apples open source devtools are old as dinosaurs, so that might be a common case.

Yeah, but there's a certain expectation that the tool that you have installed in /usr/bin is a certain version. There's a reason why tools like Homebrew generally do not overwrite built-in tools.

If you just replaced /usr/bin/python with Python 3, you'd probably break all kinds of things.

[groby_b]

The point is, it is my machine to break. Apple is more and more deciding that I don't get to do that. It's a choice that benefits a large class of customers, but it's detrimental to people like me.

macOS used to be "Unix, but with a great GUI". It is turning into "iOS, but with a few command line tools".

[growse]

> I may be missing something here, but why would you need to change the stock installed tools in /usr/bin?

Because it's my computer that I paid for with my hard earned cash, and I want to.

How far we have fallen.

[Hamuko]

Then you should probably disable SIP and go do whatever the hell you hope to accomplish with that.

[72deluxe]

I can't agree with this more! It's a bleak future. Back to Linux I guess.

[cortesoft]

I had other reasons that I needed my PATH to be in the order it was.