4 ms·

Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package ma

Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.

rurban 2y ago
Apple would certainly favor macports over that rubbish ruby thing. Ports are from FreeBSD, MacOS is from FreeBSD.
- pxc 2y ago
  Then why did Apple hire the creator of Homebrew to work on the package manager for Swift?
  - saagarjha 2y ago
    You should read https://en.wikipedia.org/wiki/MacPorts#History https://en.wikipedia.org/wiki/MacPorts#History. But to answer your question: why not? Apple employs thousands of software engineers.
- dewey 2y ago
  No need to call someone’s free open source project “rubbish”.
- latexr 2y ago
  That is provably false from so many angles. * Apple has no aversion to Ruby, and on the contrary has multiple developers pushing for it. They themselves had MacRuby, a project that allowed one to create Mac OS X (at the time) applications with Ruby.¹ * The reason there’s even an Xcode command line tools package available officially from Apple is because of Homebrew. A third-party made it first by extracting the necessary bits and then Apple officially supported it.² * There’s a liaison between Homebrew and Apple, who helped during the Intel to Apple Silicon transition.³ ¹ https://web.archive.org/web/20100908131627/http://developer.apple.com:80/mac/articles/scriptingautomation/cocoaappswithmacruby.html https://web.archive.org/web/20100908131627/http://developer.... ² I know this from a reliable source and it is public information, but it was so long ago it’s hard to find. ³ The official Homebrew Twitter account tweeted about this at the time. I no longer have a Twitter account so can’t dig it up.
  - rurban 2y ago
    Wrong. MacPorts started as official DarwinPorts, supported by Apple. It became independent later. It is a proper ports package manager. Homebrew would have a good head start, because it can use a better language, ruby. But it blew its chances with many questionable choices, they are just amateurs. But as always, worse is better.
arvinsim 2y ago
IMO, it's just counter to what Apple aspires MacOS to be. If they would do it all over again, I would bet that they would have wanted to make MacOS be like iOS.
- Lio 2y ago
  I’m not sure. Back in the day Apple marketed macOS as a serious Unix system for scientists and engineers boasting about NASA’s use of it. I think if Apple aspired to lockdown general purpose computing they would push the ipad pro range with more models and slowly kill off the Mac but they’re not doing that.
  - throw0101a 2y ago
    > Back in the day Apple marketed macOS as a serious Unix system for scientists and engineers boasting about NASA’s use of it. They still jump through the necessary hoops to be certified as UNIX® with each macOS release: * https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/
- robxorb 2y ago
  > IMO, it's just counter to what Apple aspires MacOS to be. Every OS wants to be attractive to developers. Apple has a long history of underdelivering this core proposition. To me it's an odd situation to reason about - look at Apple's dev conferences and then look at what it's like on the ground in dev's reality.
freep1zza 2y ago
What a nonsensical conclusion. Homebrew existing is no reason for Apple to do replicate that trainwreck.
- CydeWeys 2y ago
  I thought it was clear from my comment that I was suggesting Apple would do it better. Think of how useful something like apt, npm, or pip is, and then realize that MacOS has no in-house equivalent.
meindnoch 2y ago
>Apple should have written it themselves. Please don't. It would be a resource hog SwiftUI monstrosity like the new Settings app. And while they are at it, they would probably introduce the 46353th bespoke feature into the Swift language too, because why not?
- CydeWeys 2y ago
  It would be (or at least have) a command-line utility like rpm, npm, apt, or pacman. That's necessary for it to integrate well with various installation scripts. So you wouldn't have to use a UI at all, especially if it's bad.

rurban 2y ago

Apple would certainly favor macports over that rubbish ruby thing. Ports are from FreeBSD, MacOS is from FreeBSD.

pxc 2y ago
Then why did Apple hire the creator of Homebrew to work on the package manager for Swift?
- saagarjha 2y ago
  You should read https://en.wikipedia.org/wiki/MacPorts#History https://en.wikipedia.org/wiki/MacPorts#History. But to answer your question: why not? Apple employs thousands of software engineers.
dewey 2y ago
No need to call someone’s free open source project “rubbish”.
latexr 2y ago
That is provably false from so many angles. * Apple has no aversion to Ruby, and on the contrary has multiple developers pushing for it. They themselves had MacRuby, a project that allowed one to create Mac OS X (at the time) applications with Ruby.¹ * The reason there’s even an Xcode command line tools package available officially from Apple is because of Homebrew. A third-party made it first by extracting the necessary bits and then Apple officially supported it.² * There’s a liaison between Homebrew and Apple, who helped during the Intel to Apple Silicon transition.³ ¹ https://web.archive.org/web/20100908131627/http://developer.apple.com:80/mac/articles/scriptingautomation/cocoaappswithmacruby.html https://web.archive.org/web/20100908131627/http://developer.... ² I know this from a reliable source and it is public information, but it was so long ago it’s hard to find. ³ The official Homebrew Twitter account tweeted about this at the time. I no longer have a Twitter account so can’t dig it up.
- rurban 2y ago
  Wrong. MacPorts started as official DarwinPorts, supported by Apple. It became independent later. It is a proper ports package manager. Homebrew would have a good head start, because it can use a better language, ruby. But it blew its chances with many questionable choices, they are just amateurs. But as always, worse is better.

arvinsim 2y ago

IMO, it's just counter to what Apple aspires MacOS to be. If they would do it all over again, I would bet that they would have wanted to make MacOS be like iOS.

Lio 2y ago
I’m not sure. Back in the day Apple marketed macOS as a serious Unix system for scientists and engineers boasting about NASA’s use of it. I think if Apple aspired to lockdown general purpose computing they would push the ipad pro range with more models and slowly kill off the Mac but they’re not doing that.
- throw0101a 2y ago
  > Back in the day Apple marketed macOS as a serious Unix system for scientists and engineers boasting about NASA’s use of it. They still jump through the necessary hoops to be certified as UNIX® with each macOS release: * https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/
robxorb 2y ago
> IMO, it's just counter to what Apple aspires MacOS to be. Every OS wants to be attractive to developers. Apple has a long history of underdelivering this core proposition. To me it's an odd situation to reason about - look at Apple's dev conferences and then look at what it's like on the ground in dev's reality.

freep1zza 2y ago

What a nonsensical conclusion. Homebrew existing is no reason for Apple to do replicate that trainwreck.

CydeWeys 2y ago
I thought it was clear from my comment that I was suggesting Apple would do it better. Think of how useful something like apt, npm, or pip is, and then realize that MacOS has no in-house equivalent.

meindnoch 2y ago

>Apple should have written it themselves. Please don't. It would be a resource hog SwiftUI monstrosity like the new Settings app. And while they are at it, they would probably introduce the 46353th bespoke feature into the Swift language too, because why not?

CydeWeys 2y ago
It would be (or at least have) a command-line utility like rpm, npm, apt, or pacman. That's necessary for it to integrate well with various installation scripts. So you wouldn't have to use a UI at all, especially if it's bad.