Not surprising at all. It's become clear that what they've been doing with iOS all along is bootstrapping a new operating system. They started with Unix, not because Unix was optimal for what they wanted to do, but it's what they had and it worked well enough. Copland and Taligent and the rest failed because of Second-System Effect, which Apple was smart enough to avoid.
(As RMS wrote in 1983, "Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.")
Whereas such features as "background tasks" were simply a natural consequence of the architecture of Unix, Apple didn't expose that on iOS. Now they've finally gotten around to designing the background task subsystem they really want, and it's not just an emergent property of the generic Unix way. It's built for protecting battery life and privacy. It happens to be built on Unix processes (right?), but that's just an implementation detail for them.
They've been gradually deprecating Unix for 20 years, and designing the OS they want. iOS and its App Store allowed them to kill off large sections of the old interface at once. I fully expect inside of 5 years for all of Apple's operating systems to drop "UNIX" certification and become almost unrecognizable as "Unix". They've got enough market clout now that people will port Ruby/Python/Perl to a non-Unix macOS, just as they port them to Microsoft Windows.
I think you’re overthinking this. The vast majority of Ruby/Python programmers have been installing their own copies themselves, because Apple was pretty slow in updating them (Ruby is usually a few minor releases behind, Python is still 2.7 IIRC). People will just keep doing that, and nothing will change.
They may or may not be moving off Unix, but this isn’t evidence of that.
With brew as the de-facto package manager for macOS this is a great move. Having Python and Ruby bundled with macOS is confusing when trying to install "regular" versions of the software through brew or other methods. Because the default installation can't updated without updating the OS, the system versions are not useful for most developers.
This has been a topic brought up internally at Apple many times over the past decade. Glad to see it finally moving forward. Although I see the benefits to having a system-version of these packages.. if you're doing anything serious for production then the environment should be containerized.
Python and pip just being there is a huge advantage for newbies. I really think that part of programming is constantly ignored because all the decision-makers are not newbies.
The problem is not doing anything serious. Of course this would need an updated language runtime.
The problem is doing something simple, like an installer. bash => zsh: fine. You can still install with the old /bin/bash. but for many cases a shell is not enough, and then you have to compile something statically for a trivial dynamic task. Which makes the download 10x larger. Not cool.
I think this is great, but at the same time, auto-installing homebrew ought to be an option (perhaps enabled by default) when installing the “XCode command line tools”.
Better yet, offer a “developer setup” app that sets up the command line tools, homebrew, iTerm2, updated bash/zsh, and more.
Apple would do best to pave the cow paths developers have already worn into macOS, especially when it comes to command line utilities. A dev setup app would just make it quicker/simpler and pave the way for newbies to get into development.
I think the second you start auto-favouring one particular tool you're in trouble. Why iTerm2? Why not Alacritty? iTerm2 is more popular now, but 5 years down the line when someone else has come up with a iTerm2 replacement how is Apple meant to decide to switch? Where does Apple draw the line on which tools to add and which to leave out?
It sounds like what you're really asking for is something like Ninite for mac, which I think frankly is safer to stay as a 3rd party thing, rather than Apple getting super-involved in choices that are going to be very user taste specific.
It's a script that installs all kinds of useful stuff and sets some - in my opinion - nice options. I just recently started a new job and I had a brand new Macbook Pro up and running (as in: ready to start working) in less than 30 minutes.
A good tip is to fork it and modify it to your liking. At a new computer you can then just pull down your version and install away.
I'm trying to understand how these two points reconcile. "Future versions of macOS won’t include scripting language runtimes by default" and "Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal." If Catalina is the last version with any scripting languages at all, why bother with the second point? Or will python3 still be available in the future despite point 1?
As I understood it, scripting languages will still be available to the user, they just won’t have ancient versions preinstalled. Of course that also means you can’t rely on them being installed at all as a developer.
Which means you should start bundling the stuff you need to run your app, and, they’d like you not to use the same ancient batteries as they have previously made available, because, well they are ancient.
Probably the right call - many of them don’t have abi or api stability guarantees, or in the case of python needlessly broke backwards compatibility that is still causing pain today.
Apple used to ship an incredibly old version of OpenSSL because people used its API which was not ABI stable. Even getting rid of it was a nontrivial amount of work.
The lack of care about API&ABI stability in developer facing open source projects (interpreters, libraries, frameworks, commandline arguments) is still bizarre to me: why make your work hard to use/update? People ship out of date libraries because updating requires changes beyond just pulling a new binary requires more work than the gain will give them.
It’s part of why companies like Apple and Microsoft care so much about backwards compat: they want people running the most recent OS possible, and they don’t want people to avoid updates. Every time an update breaks something for anyone, they hold off updating in future.
On the other side, developers don’t want to invest time and money into a feature that they don’t think will work/cause their app to crash in future.
It’s part of why companies like Apple and Microsoft care so much about backwards compat
Compared to (former) Microsoft, I don't think Apple spends anywhere near the amount of effort MS does on backwards compatibility.
You can create a single .exe that will work on any Windows starting from Windows 95 - nearly 25 years. In that timespan, Apple changed CPU architectures twice, and their OS architecture once. If you're willing to restrict yourself to 32-bit Windows, which can run Win16 and DOS apps too, then it goes back to the early 80s.
If you're referring to the python2->python3 change, this was a pretty important one. Having a string type that isn't required to have valid encoding is an awful idea.
> The lack of care about API&ABI stability in developer facing open source projects (interpreters, libraries, frameworks, commandline arguments) is still bizarre to me: why make your work hard to use/update?
If you're a FOSS developer with limited time and man power (and if you're lucky, limited budget) maintaining backwards compatibility is hard. So hard, that new features and bug fixes might have to take a back seat to it. Also, I'm almost certain that developers would rather be implementing new features, and fixing bugs, ahead of maintaining backward compatibility. It's much easier to show a new feature or a bug fix, than it is to show how backward compatibility was maintained.
Also, the big users of FOSS, projects like Debian (and Ubuntu) and Fedora, will rebuild their entire systems when new versions of software are released/integrated. This reduces the maintainer's requirements to keep ABI compatible.
I don't know if I completely buy into that argument. API's on the bleeding edge are often prone to breakage because the development frontier is in constant flux.
However, software that neglects to update also tends to breakdown as libraries change to reflect new knowledge.
If you're developing software based on someone else's library you are implicitly accepting the demand to modify your software to maintain currency with those underlying requirements. It seems a bit far-fetched to expect that you only have to write the software once without having to maintain it.
Fucking finally! Between this and deprecating Bash [1], I'm glad macOS is dropping all these obsolete packages it's been including (Emacs soon?). Their antiquity mean they're more of a hindrance to proper development than help.
Now, if they'd officially endorse one open-source packaging solution as an alternative, I'd be fully satisfied.
MacPorts has or had semi-official status. It was hosted by macOS Forge, which was an official Apple site that included other projects such as XQuartz. I'm unclear on the current status.
I don't understand why everyone is so excited about this. I don't like using brew. I use a Mac because things just work. It was annoying that the system versions were old, but most of the time they were still workable. To me, this is another (admittedly small) thing I liked about the Mac that's going away.
Does this include AppleScript and the Javascript runtime for AppleScripts? They reference Script Editor in the section above, so I'm assuming they're safe.
Also, what's the best way to install homebrew if you don't have a system-level ruby? The current installer is a ruby script. Is it possible to get some sort of ruby-bootstrap that can install homebrew and a homebrewed ruby?
Good thing, python2.7 is deprecated and no longer receives security updates, and a lot of Linux distributions (Arch and Fedora for example) plans to remove it from the main repositories at the end of this year, so having it installed doesn't make sense.
Even the perl and ruby version installed is old, and nearly nobody uses perl or ruby at this day. Maybe perl is still used by some programs and scripts, for example TexLive relies on perl, or ruby is used for brew. But you better installing more updated version yourself so removing it is not a big deal.
There is no meaning to keep old script interpreters installed, if you want to use them you probably want to install a more modern version, if you don't need them it's better to not have them.
It's interesting to me that this is happening in the same month that Microsoft made installing modern Python as easy as typing Python and then clicking "install". One more piece of evidence that Microsoft cares about developers more than Apple does.
> It's interesting to me that this is happening in the same month that Microsoft made installing modern Python as easy as typing Python and then clicking "install".
You still need admin rights and an internet setup.
Linux is still king.
Most of my Python/Ruby stuff requires additional packages to be installed and so would need to be bundled anyway if I wanted it to be easily transferred to a vanilla machine so I don’t see what the big deal is. I got into programming through wanting to automate something really boring with AppleScript and I got into Ruby (wow that was amazing compared to AppleScript) through wanting to program sketch-up which has a bundled interpreter. When I wanted to use Ruby for other cool stuff, the Ruby website recommended I installed my own so it didn’t mess with the system install. I doubt there are very many people who get into programming by accidentally typing Ruby at the command prompt. Most will come to it via a the getting started page for the language they are interested in or because it’s bundled with the software they use for their job.
Not a big deal. Anyone doing serious development at scale would mirror production anyways (12factors principle). Plus, who uses Apple's obsolete junk anyhow? For a very long time, homebrew and macports has solved Apple macOS not rolling releasing terminal-based packages. Teapot tempest.
Of course; why would they want to maintain this crud and its dependency hell. If the slightest thing is wrong, this or that application breaks. An application should include the correct version of everything it needs to do its job, period.
Only problem is security: with multiple applications including their own dependencies, some of those dependencies will lag behind in their security updates. You can't just get a single fix for your Python run-time and fix it in all applications at once.
I did like being able to distribute an entire app with a download of just a few megabytes, relying on a highly stable system Python (literally worked for 10 years).
And these days with smallish SSDs, I find myself desperately freeing up disk space surprisingly often. I’d rather not have every single app be 100+ MB when I know deep down that the things should be tiny.
I think people are reading more into this than is there. They're just not going to ship their own (outdated) versions of these anymore because they're not needed in the core OS. You can just "brew install" them, which most people who actually use them do anyway because the stock versions are too old.
[+] [-] ken|6 years ago|reply
(As RMS wrote in 1983, "Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.")
Whereas such features as "background tasks" were simply a natural consequence of the architecture of Unix, Apple didn't expose that on iOS. Now they've finally gotten around to designing the background task subsystem they really want, and it's not just an emergent property of the generic Unix way. It's built for protecting battery life and privacy. It happens to be built on Unix processes (right?), but that's just an implementation detail for them.
They've been gradually deprecating Unix for 20 years, and designing the OS they want. iOS and its App Store allowed them to kill off large sections of the old interface at once. I fully expect inside of 5 years for all of Apple's operating systems to drop "UNIX" certification and become almost unrecognizable as "Unix". They've got enough market clout now that people will port Ruby/Python/Perl to a non-Unix macOS, just as they port them to Microsoft Windows.
[+] [-] Gaelan|6 years ago|reply
They may or may not be moving off Unix, but this isn’t evidence of that.
[+] [-] snowoutside|6 years ago|reply
[+] [-] cprayingmantis|6 years ago|reply
[+] [-] fooblitzky_bias|6 years ago|reply
[deleted]
[+] [-] DividableMiddle|6 years ago|reply
[+] [-] Waterluvian|6 years ago|reply
[+] [-] rurban|6 years ago|reply
The problem is doing something simple, like an installer. bash => zsh: fine. You can still install with the old /bin/bash. but for many cases a shell is not enough, and then you have to compile something statically for a trivial dynamic task. Which makes the download 10x larger. Not cool.
[+] [-] erikpukinskis|6 years ago|reply
What do you mean?
[+] [-] new_realist|6 years ago|reply
[+] [-] TimTheTinker|6 years ago|reply
Better yet, offer a “developer setup” app that sets up the command line tools, homebrew, iTerm2, updated bash/zsh, and more.
Apple would do best to pave the cow paths developers have already worn into macOS, especially when it comes to command line utilities. A dev setup app would just make it quicker/simpler and pave the way for newbies to get into development.
[+] [-] Traster|6 years ago|reply
It sounds like what you're really asking for is something like Ninite for mac, which I think frankly is safer to stay as a 3rd party thing, rather than Apple getting super-involved in choices that are going to be very user taste specific.
[+] [-] frou_dh|6 years ago|reply
Apple do a great job with the builtin Terminal.app
[+] [-] pmilla1606|6 years ago|reply
It's a script that installs all kinds of useful stuff and sets some - in my opinion - nice options. I just recently started a new job and I had a brand new Macbook Pro up and running (as in: ready to start working) in less than 30 minutes.
A good tip is to fork it and modify it to your liking. At a new computer you can then just pull down your version and install away.
The only default that's missing is Sublime Text.
[+] [-] Cthulhu_|6 years ago|reply
I think / hope Apple will do their own package system, maybe as part of the app store, for developer tooling like that. If only for improved security.
[+] [-] jarcane|6 years ago|reply
[+] [-] jzl|6 years ago|reply
[+] [-] jaabe|6 years ago|reply
Which means you should start bundling the stuff you need to run your app, and, they’d like you not to use the same ancient batteries as they have previously made available, because, well they are ancient.
[+] [-] dsl|6 years ago|reply
[+] [-] olliej|6 years ago|reply
Apple used to ship an incredibly old version of OpenSSL because people used its API which was not ABI stable. Even getting rid of it was a nontrivial amount of work.
The lack of care about API&ABI stability in developer facing open source projects (interpreters, libraries, frameworks, commandline arguments) is still bizarre to me: why make your work hard to use/update? People ship out of date libraries because updating requires changes beyond just pulling a new binary requires more work than the gain will give them.
It’s part of why companies like Apple and Microsoft care so much about backwards compat: they want people running the most recent OS possible, and they don’t want people to avoid updates. Every time an update breaks something for anyone, they hold off updating in future.
On the other side, developers don’t want to invest time and money into a feature that they don’t think will work/cause their app to crash in future.
[+] [-] userbinator|6 years ago|reply
Compared to (former) Microsoft, I don't think Apple spends anywhere near the amount of effort MS does on backwards compatibility.
You can create a single .exe that will work on any Windows starting from Windows 95 - nearly 25 years. In that timespan, Apple changed CPU architectures twice, and their OS architecture once. If you're willing to restrict yourself to 32-bit Windows, which can run Win16 and DOS apps too, then it goes back to the early 80s.
[+] [-] kpcyrd|6 years ago|reply
[+] [-] maheart|6 years ago|reply
If you're a FOSS developer with limited time and man power (and if you're lucky, limited budget) maintaining backwards compatibility is hard. So hard, that new features and bug fixes might have to take a back seat to it. Also, I'm almost certain that developers would rather be implementing new features, and fixing bugs, ahead of maintaining backward compatibility. It's much easier to show a new feature or a bug fix, than it is to show how backward compatibility was maintained.
Also, the big users of FOSS, projects like Debian (and Ubuntu) and Fedora, will rebuild their entire systems when new versions of software are released/integrated. This reduces the maintainer's requirements to keep ABI compatible.
[+] [-] bshipp|6 years ago|reply
However, software that neglects to update also tends to breakdown as libraries change to reflect new knowledge.
If you're developing software based on someone else's library you are implicitly accepting the demand to modify your software to maintain currency with those underlying requirements. It seems a bit far-fetched to expect that you only have to write the software once without having to maintain it.
[+] [-] Reedx|6 years ago|reply
[+] [-] xmichael999|6 years ago|reply
[+] [-] AceJohnny2|6 years ago|reply
Now, if they'd officially endorse one open-source packaging solution as an alternative, I'd be fully satisfied.
[1] https://news.ycombinator.com/item?id=20090193
[+] [-] rgovostes|6 years ago|reply
[+] [-] bla3|6 years ago|reply
[+] [-] ihuman|6 years ago|reply
Also, what's the best way to install homebrew if you don't have a system-level ruby? The current installer is a ruby script. Is it possible to get some sort of ruby-bootstrap that can install homebrew and a homebrewed ruby?
[+] [-] alerighi|6 years ago|reply
Even the perl and ruby version installed is old, and nearly nobody uses perl or ruby at this day. Maybe perl is still used by some programs and scripts, for example TexLive relies on perl, or ruby is used for brew. But you better installing more updated version yourself so removing it is not a big deal.
There is no meaning to keep old script interpreters installed, if you want to use them you probably want to install a more modern version, if you don't need them it's better to not have them.
[+] [-] toyg|6 years ago|reply
Let's not go overboard - 2.7 will get security updates and patches until the end of December.
> nearly nobody uses perl or ruby at this day.
Well, except for homebrew of course, the Ruby-based package manager nearly "everybody" uses...
[+] [-] exabrial|6 years ago|reply
[+] [-] robin_reala|6 years ago|reply
[+] [-] jeremyjh|6 years ago|reply
[+] [-] sys_64738|6 years ago|reply
[+] [-] mixmastamyk|6 years ago|reply
[+] [-] fooblitzky_bias|6 years ago|reply
[deleted]
[+] [-] Godel_unicode|6 years ago|reply
[+] [-] grumpydba|6 years ago|reply
You still need admin rights and an internet setup. Linux is still king.
[+] [-] pcr910303|6 years ago|reply
[+] [-] willyt|6 years ago|reply
[+] [-] bayareanative|6 years ago|reply
[+] [-] kazinator|6 years ago|reply
Only problem is security: with multiple applications including their own dependencies, some of those dependencies will lag behind in their security updates. You can't just get a single fix for your Python run-time and fix it in all applications at once.
[+] [-] panpanna|6 years ago|reply
(Eralier versions of mbed build system needed python, JavaScript and one more)
[+] [-] markstos|6 years ago|reply
Congratulations, Python 3!
[+] [-] briandear|6 years ago|reply
[+] [-] makecheck|6 years ago|reply
And these days with smallish SSDs, I find myself desperately freeing up disk space surprisingly often. I’d rather not have every single app be 100+ MB when I know deep down that the things should be tiny.
[+] [-] api|6 years ago|reply