They may or may not be moving off Unix, but this isn’t evidence of that.
You should check out what they’ve been doing for years with Swift Playgrounds on the iPad
https://swiftreviewer.com/2018/12/21/swift-programming-on-ra...
Maybe not the best language for someone new but its widely available.
You can run almost any language from a web browser these days:
A lot of educational sites offer embedded interpreters like this.
It has never been easier to start to learn programming. The real challenge nowadays is maintaining attention...
It could just as well still remain a one-liner. Every system Homebrew is installed on has Bash installed (not the latest, but still).
Instead of
> /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in...
It could become
> curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in... | bash
With the install script containing a payload containing the current Ruby script plus a Ruby interpreter. Still a "one liner".
Ironically, they are also moving from bash to zsh for default shell. Again not an unsurmontable challenge (just make sure the bang is correct in your scripts, bash will likely still be around somewhere in macOS for the foreseeable future) but another little hurdle to mind.
Personally I try to use #!/bin/sh as much as possible, and Fish as my default shell.
On the up side though, clang has made the C/C++/ObjC world a much better place.
(OK, I learned Logo in school when I was 7, but programming became way more interesting when I discovered AppleScript's APIs to control all the programs on my Mac).
And you think a one-click download and install of Ruby would have prevented that?
Not to mention Apple also has Swift, and Swift Playgrounds and so on for kids these days.
So I get what you are saying but I think we are in a new world here.
For Python folks, just install pyenv/pipenv and you can easily maintain `system` (Python), Python2.7x, Python3.7.3, &c as separate environments. For Ruby people it's rbenv.
What will be left? Will it still be "Unix" in any meaningful sense just for having a C compiler and running an old version of Bash? Microsoft Windows did that, too.
You don't have to be anti-unix to do that though, any reasonable organization would have done the same. I agree with the rest though.
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.
Ruby on Windows is a nightmare.To be specific, Ruby itself (the core language and core libraries) are pretty good on Windows. Great choice for a scripting language, or whatever else you want to do.
But libraries like ActiveRecord, Rails and their myriad dependencies are very very hit or miss on Windows and there's not a lot of support when things go badly.
A lot of the issues are simple - like dead simple. Lot of gem authors don't bother to make things like file paths (forward slash vs. backslash) system agnostic. Or the gems depend on compiled binary stuff like Nokogiri or ImageMagick and those are always a bit of an adventure on Windows.
If MacOS drifts farther away from Unix they will cease to be the platform of choice for many developers currently using it today.
Windows file APIs have always supported forward slashes in file paths, even before there was Windows. This goes all the way back to MS-DOS 2.0.
People complain about doing Rails on Windows, and, while there's definitely extra friction, and I hate Windows in general, I have really good luck with RubyInstaller. I used to have a hard time with ExecJS, but now I just install Node (on either Mac or Windows), and I'm usually off and running.
Running 'Pengwin' (Debian) Linux via WSL, RVM using Ruby 2.4.1 + Rails 5.1.7 and Ruby 2.6.2 + Rails 6.0.0.beta3
Today, everything works just as expected, right out of the box with no effort. This includes ActiveRecord (to SQLite, MariaDB, and PostgreSQL), including Node.js / Asset Pipeline, Prawn PDF and ImageMagick integrations, uploads to AWS, email integrations, capistrano-based deployments, Heroku Gem + integration, and so on.
It's gotten to the point where we spend more time helping OSX folks figure out occasional Homebrew weirdness, than we do helping Windows folks with WSL. Especially since WSL people can almost always just re-use any Ubuntu instructions verbatim.
Hell, not only VSC supports WSL. RubyMine can manage rbenv/rvm on WSL and more https://confluence.jetbrains.com/display/RUBYDEV/How+to+add+...
But none of this is surprising considering where RoR is coming from, I'm not sad or upset about it either :)
I haven't done Rails for a while, but when I did Rails (including ActiveRecord and all its other components) Just Worked o bWibdows (lots of the peripheral ecosystem of Rails and Ruby more generally was a nightmare, but Rails itself was great), and overall the Ruby (outside of Rails) experience on Windows has gotten better with Ruby installer + DevKit, which hasn't closed all the gaps but does mean that even libraries with C extensions frequently just gem install and work on Windows; I'd be surprised if Rails itself had gotten worse in this area.
Apple isn't changing things just for the sake of change. They're removing 1970's-isms where they hold back the platform. Languages like Ruby/Python/Perl also clean house, from time to time, to remove old cruft. I can't imagine any legacy feature of macOS that Apple would want to deprecate which would make it more difficult to maintain a good port of Ruby/Python/Perl. These are regular general-purpose programming languages now, not just Unix scripting languages.
Yes, Unix has been one of the developer systems of choice for the past couple decades, but it wasn't always so, and it hasn't been the only one. I hear more developers than ever using and enjoying other systems like Windows (Powershell) today. Even Linux today is pretty far from traditional Unix. I just don't see perfect Unix compatibility as a necessary component like it was in 2001.
Depends on what level of the UI you're dealing with.
IIRC, HFS actually uses a ':'.
Mac OS X, initially released on 24 March 2001, uses '/', like other Unix-derived systems.
Also, like other unices, OS X uses '\n' as the line ending. Prior Mac OSs used '\r' as the line ending. Windows uses '\r\n'.
The same stuff with Node.
(sourceforge is the main link, probably best to visit with ublock origin enabled)
It's pretty easy these days.
The experience isn't as nice as macOS, but it's not terrible by any stretch.
Have the same stuff working on Linux and deploy anything without VM/WSL/telemetry/etc. Guess similar situation with macOS.
Nightmare? No. Suboptimal? Yes.
We're running some legacy rails 3.2 against oracle db on windows, and it works well enough. It sure is a lot more pleasant on linux, though.
Biggest challenge on windows is to get a c compiler working/get binary dependencies working. Other than that, you need a version manager (same for other platforms really, unless you're aiming to shoot yourself in the foot).
Ruby on windows is definitely not great, but "nightmare" is a bit much.
But that's my idea of a nightmare - when things are suboptimal and you're often scrambling for solutions on a second-class platform. When I say "often" I don't mean "every day", but in my experience it happened enough to make me swear off Rails on Windows forever.
Of course maybe 5.x is different. My experience was in the late 3.x and early 4.x days
It hurts when I do this ... [punches self in face] ...
They have a problem deprecating python2.7 as it is, the smartest deprecation is not to release a python3+ version at all.
You see a similar issue with python on Debian. Python 2.7 is still the system python for all of the Debian tree, and it is very challenging to migrate to a new version because of the huge impact it has.
That's not to say MacOS won't be a place where python is happy to run - just that Apple don't want to dictate a specific version of it in their releases (i.e. developers/users/applications should install one.)
You might be right about OSX and it's derivatives moving away from being so unix-like, but by itself this is just sensible housekeeping they would have to do at some point anyway. It's just not reasonable to expect them to include and maintain deprecated language runtimes indefinitely.
[1]https://developers.redhat.com/blog/2019/05/07/what-no-python...
(This discussion, of course, has nothing to do with whether or not macOS adheres to Unix principles or compatibility.)
Getting your products into Universities is a great way to maintain market share. This is true for software like Matlab and even for banks where most students will keep banking with the same bank for decades.
I can have an Unix workstation while still being able to run Outlook, Excel and Powerpoint.
I don't want to use Windows and I don't want to use that pile of crap that LibreOffice is... The mac was a good compromise for me.
I have a historical question and I wonder if anyone in this thread has the answer: why did RMS (and, presumably, by then his cycle) had to wait around for Linus Torwalds to write a kernel so they could have one for GNU? RMS in particular has a reputation as a legendary hacker. Was he not able to write his own kernel?
"Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. (...)"
GNU couldn't use MINIX due to the license (unlike minix 3), and as I recall, the bsd's were also in somewhat unclear license terms.
Gnu made the libc, compiler and various userland tools - but no-one did a" simple get it working"-kind of kernel, and then Linux came along.
I suppose part of this might be because in early gnu days, most gnu hackers used university Unix machines - not personal 80x86 for development.
If you bough sun hw you got Solaris. Only if you bought a pc clone would you be wanting a "real" os...
Do you see that changing as macOS gets away from UNIX? That would probably be a bad hit on apple if Linux becomes then the de facto programming OS when Apple drops UNIX
It is already. Deployed any production service on macOS, of late? Windows and MacOS both, are now forced to run Linux compatibility layers (Docker, WSL...); the Mac one just happens to be thinner because of the choices made at NeXT back in the day.
> They've been gradually deprecating Unix for 20 years, and designing the OS they want.
That was never a real consideration where distros/vendors are concerned (UNIX or Linux). Just a nice-to-have goal for the command line userland (and even that, more back in the day).
Just as they ported them to MacOS Classic back in the day.
If I'm not mistaken, current best practice is to somewhat isolate third-party developer software anyway, using homebrew, a VM or other solutions (not sure about Docker - don't use it).
I can see where it would be an issue with developing for MacOS or iOS, but third-party web development doesn't really need anything that is installed on the system, and in my experience, it's actually better not to base it on the MacOS default packages.
Maybe I'm old-fashioned (feels weird to say that as a 25-year-old, but here we are), but I quite like not having everything be in a container all the time.
Correction: Homebrew usually installs its binaries in a way that doesn't interfere with the ones provided with the system. It will occasionally override or shadow them and things will break.
That's extremely rare, these days. When a conflict is possible, they just drop the new version in the cellar and tell you what to do if you really want to risk shooting yourself in the foot.
Just like WSL 2.0 (https://devblogs.microsoft.com/commandline/announcing-wsl-2/)?
(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.