Apple makes zsh default shell on macOS(support.apple.com) |
Apple makes zsh default shell on macOS(support.apple.com) |
Bash is the least worst language for bootstrapping since the alternative is POSIX shell which is even more difficult to get right.
The biggest issue is that Bash 3.x arrays don't work well with `set -u`.
What is wrong with GPLv3 for Apple and why is it okay in Linux?
I think if one only ever uses their own computers fish is better, but having to switch contexts, having to have different configurations and so on is a pain and not very productive.
https://anisse.astier.eu/bash-to-fish.html
One thing I haven't touched in my article: globbing behaves differently than the default, which means you have to quote your '*.ext' arguments when using find for example. This is fairly well documented: https://fishshell.com/docs/current/index.html#expand
I very rarely move back to bash, so I consider this migration a success :-) If you haven't yet, should try it !
Now I use Fish Shell on Linux and it's fine for what I usually do.
Works out-of-the-box for me on most machines (i.e. I don't maintain shell settings besides downloadding GRML zsh regularly) and it is not as big as oh-my-zsh.
If you're looking to replace oh-my-zsh with something sane and fast, zprezto has been my go-to choice.
Source: https://developer.apple.com/documentation/macos_release_note...
A pity they didn't make a structured output shell rather than traditional regex scraping but their main concern is compatibility, and zsh fits nicely.
Apple's lawyers probably think different.
You can install all the GPLv3 software you want on your Mac (Macports and homebrew make it easy). But Apple made it clear that they are not going to ship anything GPLv3 licensed.
Wrong
> I'd rather use an OS that's willing to ship essential software.
Ok, there's Linux in that case.
> The OS is there to serve the user, not make their lives more difficult because of petty licensing concerns.
"Petty licensing concerns" are an issue for big companies.
$results = @{}
ls -recurse -filter "eslint-scope" | foreach {
$file = "${PSItem}\package.json"
$version = cat $file | convertfrom-json | select -ExpandProperty version
$results.Add($file,$version) }
echo $results | format-list
EDIT: Linux is GPLv2 only and does not accept GPLv3 submissions. It is likely that your question can be restated as “Why are GPLv3 programs able to use syscalls in Linux without infecting the kernel with GPLv3 compliance requirements?”, and this is likely due to the clearly declared syscall exception as noted in their licensing docs:
https://github.com/torvalds/linux/blob/master/Documentation/...
And, Torvalds commented on never-GPLv3 in 2006:
As far as I understand it, if the GPLv3 clauses would apply, Apple would have to allow anyone to run their own, modified version of macOS on their computer, meaning Apple would need to provide a way for people to circumvent / disable all the secure boot architecture.
Also, things like "Activation Lock", where Apple requires your Apple ID password to re-install the OS (a theft protection feature) doesn't sound like it would be easy to reconcile with GPLv3.
"Activation Lock" is an iOS thing. On Macs you can set a firmware password [2], but I don't see how that would conflict with GPLv3.
[0] https://developer.apple.com/library/archive/documentation/Se...
This seems dubious, since the FSF themselves make the statement that aggregates of differently licensed software are fine, as long as you comply with GPL for the GPL-licensed parts: https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation
All of macOS, since 10.0, is built on ever-more-interlocking systems of ‘intimate’ communication. As upthread points out, there’s a hardware chip that uses IPC to interlock with SIP to protect system files. The depth of IPC used to deliver a Macintosh appears to qualify the entire shipping OS for the “larger program” clause.
Setting IPC aside, it’s still easy to construct a case against GPLv3: If bash is included in an operating system release that can be downloaded like any other program on the Mac App Store, then it’s absolutely plausible to a layperson that the inclusion of GPLv3 in that program would - like any other program - infect it in its entirety with GPLv3’s copyleft requirements. macOS isn’t an aggregate software repository to its users, and a judge could easily be convinced to agree.
I’m not Apple’s lawyer, but I hope this helps convey what I imagine is part of their reasoning against it.
At least we get diversity in our shells. I quite like that, it reminds me of the UNIX days when every OS was slightly different at the shell level, with different command line options for simple commands in Solaris/IRIX/HP-UX and those myriad of different IBM systems.
Can't have it too easy, can we? Or else anyone would be able to do our programmer jobs!
Shouldn't this be the other way around? The concern would be with non-GPL programs making syscalls and getting infected with a GPLed kernel. The kernel isn't at risk of being infected.
While we can armchair legal this in either direction on how likely that judgement would be, they appear instead to have decided to never permit that risk to occur at all. I approve, too: if you don’t want to share every bit of source code in your product, don’t use GPLv3 in your product. It’s explicitly meant to be annoying like that, and any plausible effort to have your cake and eat it too risks being overturned by a court of law.
I think that a more likely reason is that Apple have plans for macOS that wouldn't play well with GPLv3's anti-Tivoisation measures.