MacOS 10.12.6 Source
opensource.apple.com
opensource.apple.com
>>"Why spend time on Darwin?
>>
>>For learning and fun."
I'm asking because publishing cross-platform mobile apps is currently a hassle, as the iOS one can only be done from MacOS, which itself only runs on Apple hardware. As a consequence, I have an old Macbook lying around and dust it off everytime I make a release. A VM running anywhere would come a long way.
Also, I'm aware of hackintosh VMs, but it's a hassle to set up (and yeah, borderline legal, but I'm on borderline patience with all that inconvenience by now).
"PureDarwin can run on VMware as well as real Intel-based hardware. We are successfully running a web server, have built hundreds of software packages with MacPorts running on PureDarwin, including ssh, apache2, tightvnc, Xfce, and others."
I personally haven't run it, but I think it's pretty usable if it can do the things mentioned above.
https://webkit.org/getting-the-code/
The same is true for LLVM / Clang:
Those thoughts prompted me to create https://github.com/epipping/xnu-kernel-sources-x86 (and its cousin https://github.com/epipping/xnu-kernel-sources-ppc). Maybe you find it help (please take a look at the wiki)
Now that I think of it, Google seems to take this approach with a lot of features. I guess that's why everything based on Blink forks or embeds Chromium instead of using bare Blink.
- My understanding is that the Blink fork happened because Google was the primary contributor to WebKit prior to the fork, and Google engineers were spending a significant amount of time trying to make Apple engineers happy. Additionally, there was a lot of code needed to support both Apple's and Google's JavaScript engines and multi-process implementations, which was no longer needed after the fork. WebKit2 and the Chromium multi-process architecture did exist for some time before the fork.
- WebKit2 is a layer on top of WebCore, which is the part Blink forked. So both WebKit and Chrome implement multi-process in another layer on top of the renderer. I'm not familiar with WebKit2, but in Chrome, this is done in the content layer, which provides most of the core rendering code (including the multi-process stuff), but without all the browser-specific features (e.g. autofill, extensions, spell check, etc.). I believe Opera is currently built on top of the Chromium content layer.
Opera is indeed built on the Chromium content API (v. the Chromium Embedded Framework, which provides a stable API but was less power), and that was a design choice made prior to the Blink fork and hence why Opera followed Google to Blink.
It could be workflow related. The OS team has been around for decades and pivoting to a new RCS for a whole OS is not easy.
2-3mb JS files brought it to a crawl, and I didn’t have many plugins btw.
https://opensource.apple.com/source/Chess/Chess-318/Styles/G...
For comparison, the source of the older Chess is also available, in https://opensource.apple.com/release/mac-os-x-1015.html though some parts might no longer compile.
Software they take in from BSD, other open source projects, or some common Linux tools might also get patched. However, such patches are never actively submitted back to the projects, but only published on this website.
The sources published for macOS on this website are mostly licensed any variant of the BSD/MIT licenses, or the Apple Public Source License, or the GPLv2. Apple avoids the GPLv3 for legal reasons due to its patent clause. That is why they often ship only the most recent GPLv2 release and ignore all later updates, for example GNU make 3.81 or bash 3.2. There might also be some other licenses in the mix, such as the Artistic License for Perl and related software.
The patent clause is bad, but the anti-TiVoization clause is actually worse. According to that, if Apple accidentally ships any GPLv3 on iOS then they'll have to release their root signing keys to the world, which would be disastrous (it would destroy the security model of the OS).
Edit: Well, I guess the secure enclave can be trusted. But nothing else can be.
It bothers me that you are confusing Apple's policy choices, which are not inevitabilities nor are they without dissenting opinions, with security, suggesting there is no possibility to satisfy the latter without making the same choices as the former.
Now, I might be lazy or busy and delegate that responsibility to Apple or some other third party. There may be mismatches between my preferred policy and what is enforced by my proxy, but it might still work reasonably well overall. We humans do it all the time. No reason the CEO has to make every single decision themselves.
When the stakes are high and I don't want to risk that nuances of my set policy get lost in translation or when it's about things that are totally outside my proxy's area of expertise, I'd prefer to make the decision myself.
With iDevices, I can't. There's only the delegate model and the only available proxy to choose from is Apple.
PS: Releasing secret signing keys to the whole world is an obviously bogus suggestion. Please stop beating up this strawman.
Don't confuse having secret keys as "security by obscurity".
That's not what the phrase means. Else SSH private keys are "security by obscurity" too...
There are some complexities here (and for Apple's goals with iOS, I totally understand them not wanting to work through those complexities), but for a team that has built the most secure general-purpose computing platform in the world, this isn't an unsolvable problem.
Compared to destroying the security model of iOS in general this is pretty tame, but it is still a non-trivial downside.
I think this design still works if you only allow generating a signing keypair if Activation Lock is disabled? I think that still satisfies the requirements of GPLv3 sect. 6, although we're probably in territory extremely far from settled caselaw.
> “Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
The "method"/"procedure" is signing out of iCloud, doing a factory reset, and holding down the button. It doesn't interfere with the continued functioning of the modified object code, i.e., of the OS itself, just with any user data present before you started the procedure.
(Sorry if this question is really misguided, I'm not super familiar with the area).
Were I an iOS device owner, I would want the ability to replace the root signing keys on any device I'd own. It'd be my device: why should Apple have the unique privilege of determining what software may run on it?
It's fair to say that the GPLv3, which predates the iPhone, did not anticipate the nuances of people storing all their secrets on a tiny little computer that they keep with them at all times, including when they pass through international borders.
(As others have said, there's ways to make GPLv3 work with the iphone's security model, mainly along the lines of requiring a factory reset whenever you want to add an allowed signing key to the device.)
How does the ability to wipe the phone (and thus the data, and the code compiled and signed by Apple) and replace its signing keys with your own allow an attacker to surreptitiously install a rootkit?
The dangers of physical access to one's devices existed before mobile computing, let alone before GPLv3 or the iPhone.
Nobody could be certain if they were running a trusted version of iOS.
This problem has been solved outside of Apple's garden.
Unlike other mobile operating systems, iOS prioritizes protecting the user's privacy. The real user, not just any household member or employer who might have physical access to the device.
In your described solution, what prevents an abusive/sneaky household member from posing as the user and supplying those "user-configurable" keys without the knowledge of the real user? Nothing? That answer wouldn't be good enough for the Apple "garden" as you call it.
The function "replace keys" can have any other programmable feature attached to it. Wiping out all preexisting data, reseting the phone to factory settings, and sending a message to the original owner is all possible and would make any sneaky behavior very un-sneaky. They could even require some form of 2auth or other technique that people use to authorize themselves to banks in order to get the unit-unique key to make the TPM memory rewritable. GPLv3 don't require that installing new keys are easy, but the real owner must have a method to do it.
Apple sees the iPhone as a hardware security device. Apple wants users to be confident enough in its security that they can use their phones to authenticate financial transactions.
It's great that some phones are modifyable by their users, but I would never ever link my Android phone with my bank account.
Personally I prefer that my hardware security device are controlled and owned by me, not the company that sold the device. Devices not owned by me have an undeniable history of being abused by people who sell such devices, like the case of Lenovo.
If you want to use the history of open devices which their owners can own and control as a case against it, the opposite of company approved software has also a history of abuse. How are all those nice lock down car computers that have been acting creatively during emissions tests. How much trust have they earned, and should people trust them with their bank account for say automatic payment at gas stations?
Because that's not how security works. If you can just add your keys, an attacker could too...
Err, security is about preventing attacks -- not about having evidence that they've happened.
Besides, select "foil", right click "Look up": (OS X Dictionary): prevent
So, not a native speaker, and there might still be some nuance of preventing from even being considered (avert?) in "foil", and you could be technically correct.
http://static.damnlol.com/media/5c5c06b2d9e1d4e9b66725f86dab...
The former is trivially defeated (just breaking the phone, for example, is much quicker and less involved than forcing a factory reset), and not what we were talking about.
Then the attacker installs some apps including some special ones designed to spy on the user.
Then they remove the screen lock, or set the password to something guessable or that turns up as a suggestion when Googling for "I can't get into my phone" and return the device to where the user had it last.
The naive user finds their device, gets in, and notices their data is gone. This is real harm.
Now they start using the device, and they are spied on, on an ongoing basis. This is more harm.
I'd have to say your system as described isn't working.
That's only slightly better than losing the phone itself.
> Now they start using the device, and they are spied on, on an ongoing basis. This is more harm.
This is more substantial. But if you are talking of the naive user who would not take notice of their Apple account suddenly vanishing from their device, there are easier ways for breaking in to their device without having to wipe it.
Apple's system doesn't work to secure naive users against dedicated attackers. If Apple's system has any design for security (and I agree it does), it's for users who'd notice when their data is wiped.
When you say it doesn't work against dedicated attackers, maybe you are thinking of an iPhone 6 hacked by an Israeli security company paid by the FBI? For one thing, most people don't have the resources of the FBI. And I think Apple has raised the bar significantly in the three or more generations since that device.
If you were to own an iPhone and also apply some conscious awareness to noticing what it does on your behalf to protect your security, I think you would agree it has a lot of very effective measures to protect users.
Social engineering, for one, is much easier against naive unsuspecting users than wiping their phone and hoping they wouldn't bother.
For those who truly care about their own data security though, a wiped phone is an instant siren.
----
I have used an iPhone, though only for a short while, and not long enough to get used to it. I agree it goes a great, great distance to protect users against everyone not blessed by Apple.
But then I have greater data security on my laptop and far greater freedom too, so Apple's offering doesn't seem like a good enough deal to me.
Also with a laptop the use cases generally can tolerate a bit more delay in the login process, with a few seconds being tolerable, whereas with mobile devices a login process over a second starts to get intolerable very quickly as the length of the process increases. Again this may be obvious and yet you seem oblivious to it as a consideration, as you expect a better offer, as though there are no constraints and tradeoffs, or you are unaware of them.
Mobile device designers and mobile system designers deal with this stuff every day for years on end. They know a lot about it, and have thought stuff through way more than some of us. It's super easy for you to criticize from a position of relative ignorance (not even a current iOS user...) but I'm pretty sure they are still following the mantra of trying to make stuff insanely great.
Still, you can dream of even better devices. I'm sure the bar will keep being raised. Let's hope we get there to a place where we do have both freedom and security.
> Again this may be obvious and yet you seem oblivious to it as a consideration, as you expect a better offer, as though there are no constraints and tradeoffs, or you are unaware of them.
I'm not oblivious to the tradeoffs of security. I know that if I set a long password it only makes every login that much more tedious. And that's my problem to deal with. But to have no choice, no freedom, no chance of owing your device, in the name of "security", is either unmindful or wilfully ignorant of a manufacturer.
----
You keep saying I'm not a current iOS user so I couldn't possibly see the great things iOS does. I merely doubt it could do anything beyond generally security focused OSes. For example, my current mobile OS has a separate decryption password at boot, scrambles the lock screen numeric layout, compartmentalizes my data, hooks into every way apps can request private data and lets me allow/disallow/fake it, hooks into every way apps can even run and lets me choose which to allow/disallow, and still provides me the freedom to run whatever I want and share whatever data I want with whichever app I want.
I'm not dreaming of much more, largely because I already have quite a lot.
I said no such thing. And yet you put it in quotes. This kind of behavior is for reddit, not here.
Apple does give you security; it just has to happen in a different way.
I don't trust Apple to be good from now until I replace my phone. I don't trust Google to be good from now until I replace my phone. It's my phone, not Apple's and not Google's.
Now, I don't know if there is any provision in US law that makes you automatically enter a binding contract if you use code that is accompanied by a license file. It is certainly possible, as you demonstrate intent to enter the agreement. But OTOH, this would be too easy to abuse. Just sneakily replace the LICENSE.txt and add "you agree to pay 50% of your income and your firstborn child"... I don't think many would catch that.
We say "this code is under this license", but actually beneath the hood this means "this code is available for license under these terms".
(In Germany at least the hurdle to enter a contract is rather high. For a time, you were able to get on a bus without paying, and if caught argue that you never agreed to the terms of the bus company... so they had to make a special law against fraudently leeching services.)
Probably.
> Just sneakily replace the LICENSE.txt and add "you agree to pay 50% of your income and your firstborn child"... I don't think many would catch that.
A clause like that is completely unenforceable in the US. Any judge would throw it out.
Stop spreading this FUD. They would not need to release their root singing keys in this case, just provide a mechanism to allow for other keys to be used (there are various ways to go about doing this without compromising security). The main requirement is that the compiled software can be run on the device.
The most plausible approach is one outlined in another comment in this thread wherein you get a new key when factory-resetting the device and if you don't write it down it's gone forever, but even that approach will likely cause problems with Activation Lock. And in general it's risky to introduce stuff like this because the potential for unforeseen security compromises is very high, and the upside is very low (the number of people who'd actually take advantage of this is extremely low relative to the number of iPhone users).
Not if a physical modification to the hardware, a set of button presses, a hardware token or a fuse is needed to set said keys.
> And in general it's risky to introduce stuff like this because the potential for unforeseen security compromises is very high
There is little to no risk if physical interaction with the hardware is required for setting keys. If you have physical access and enough time, all bets are off anyway.
> ...and the upside is very low (the number of people who'd actually take advantage of this is extremely low relative to the number of iPhone users).
There are many people who dream of having the freedom to roll their own firmware on a particular device and it can be done without compromising the security of said device. This was not just about iThing users (who might/not take advantage of this), this was about people spreading FUD about the tivoization part of the GPLv3. Root signing keys don't need to be shared and the only requirement is that the user can take the sources, compile them and then run the result on the target device. As long as the OEM distributing the GPLv3'ed program gives a clear path for running the compiled code on the target device, then it is not a problem.
So much so that in your attempt to find any toehold to criticize it, your comment had to resort to coming up with scenarios that go outside of the system and rely on human vulnerabilities.
The reason nobody mentions this is because the solution is so trivial there's really no point in repeating it each time.
That's only because we live in a world where phones aren't treated like the general use computers they are. MS+OEMs and Apple fought hard for decades to create an appliance mindset around what used to be a user-replaceable component, the OS.
We can just as easily imagine and try to build a world where it's just as easy to mix and match phones with phone OSes as it was to choose DR-DOS instead of MS-DOS.
Hog-wash. Me not allowed to be in control of my own device is the ultimate compromise of my security.
The author of a license is not the person with the legal authority to interpret its meaning.
That is just as absurd.
The opinion of the writer of a legal document carries only tangential weight next to the actual written words of this document.
Also, there's nothing stopping an opinion from a lawyer from being FUD. Apple Legal isn't your lawyer, they don't have a responsibility to tell you the whole truth or give you information that is in your best interest.
Also, it's not like Apple Legal is telling anyone outside the company about this. Apple's not releasing any public statements asking people not to use GPLv3. So how exactly are they supposed to be discouraging its use when the people using it don't know what Apple Legal thinks about it?
Yes there is. Apple doesn't want to use GPLv3 for other reasons (they don't want users to have full control over their machines -- which they've proven time and time again with the iThings). But rather than saying "sorry, we don't want you to be able to control your machines" (which would be bad PR) they spread rumors about "GPLv3 means your software cannot be secure against certain attacks".
> Also, it's not like Apple Legal is telling anyone outside the company about this.
Hence this whole comment thread is a discussion about theoretical views of Apple Legal. My whole point is predicated on "someone actually knows for sure that this is the opinion of legal".
Oh come on. You sound like a caricature now. "Not having control over their machines" is not a goal and it makes you sound like a crazy conspiracy theorist to claim it is. Security is a goal, and unfortunately security often conflicts with having complete control over the device. But that's different than saying Apple actively wants to prevent users from having control over their devices.
> they spread rumors
No they aren't. Apple doesn't make any public statements about GPLv3, period. Apple can't possibly be spreading rumors if they're not talking to people.
> My whole point is predicated on "someone actually knows for sure that this is the opinion of legal".
I do. I know for sure this is the position of Apple Legal. Which is why I said this was their position in the first place.
I agree that security is a primary goal of Apple. And many of the restrictions have a mostly valid security justification. But "ability to have full control of your machine and be able to replace components" is clearly not part of Apple's goals. So they don't spend any time thinking about solving the problem with that constraint.
What security do you get from not being able to replace the window manager? Because if you want to claim that "Apple prioritises users being able to control all parts of their machines, and security prevents this from being possible" then you have to give a security justification for every un-configurable restriction.
> Apple doesn't make any public statements about GPLv3, period. Apple can't possibly be spreading rumors if they're not talking to people.
Well, we're talking about it right now aren't we? I'm aware they didn't make any public statements, but this whole discussion is pointless if we are just going to say "I know this is their true opinion and they have no reason to lie to me because they didn't say it publicly, therefore [contentious statement about GPLv3] is effectively correct and there's no point in discussing this further".
> I know for sure this is the position of Apple Legal.
You know that this is what Apple Legal told you, or someone who knows someone at Apple Legal told you. Unless you're part of Apple Legal in which case you've now made a public statement about GPLv3.
This is the very definition of a rumor.
> What security do you get from not being able to replace the window manager?
Well, you could argue that a third-party window manager could be snooping on all of the content visible on your screen (that otherwise isn't available to third-party apps) and could be doing whatever they want with that potentially-sensitive info. But that doesn't even matter, because the real answer here is "it's a massive amount of work to support third-party window managers, since the window manager is such a crucial and low-level and highly-integrated part of the system, and there's no motivation for Apple to expend that tremendous amount of work, especially because they'd likely end up with a far-less-stable system as a result".
> Well, we're talking about it right now aren't we?
We are, yes. Apple isn't. No matter what I say on the subject, that doesn't mean Apple is spreading rumors. I don't work for Apple.
> This is the very definition of a rumor.
You're free to accuse me of spreading rumors if you want. And I can't very well deny that because I can't provide any verification, but this interpretation of GPLv3 is a fairly common interpretation so I don't see that there's any reason to doubt it.
But you can't accuse Apple of spreading rumors because people like me are making statements about this.
And Apple's APIs let you snoop on those events anyway (that's how the semi-third party window manager-managers work), this is not an argument...
> because the real answer here is "it's a massive amount of work to support third-party window managers, since the window manager is such a crucial and low-level and highly-integrated part of the system, and there's no motivation for Apple to expend that tremendous amount of work,
...so what you're saying is "they don't want to put the effort into being able to replace core components of the system"? Because that's what I'm saying. I'm just saying it in a less charitable way than that.
> but this interpretation of GPLv3 is a fairly common interpretation so I don't see that there's any reason to doubt it.
It's only a common interpretation if you believe the rumors about Apple's view (and you're not the only person spreading them). FSF does not make that claim. Effectively everyone who uses GPLv3 doesn't make that claim (as far as I know). The only people that I've seen make that claim are people who say "this is the justification that Apple told me off-the-record but since they said it off-the-record we can't discuss it's merits". Do you see why I would suspect that this rumor spreading is co-ordinated?
We went through this bullshit back with UEFI and GRUB in the Linux community. The agreement was that GPLv3 is fine so long as it is possible to replace the keys (and wiping the machine on key replacement is what you want to happen anyway, so that's fine and it solves the security issues). If you want to start claiming that it's a "common interpretation" you need to show that there is a larger community than the Linux community that uses the GPLv3. And you won't find one. Because it's not a common interpretation in the community that uses that license.
Why do you keep talking about rumors? And why do you keep talking as if this is somehow unique to Apple? I'm pretty sure Apple's not the only company that believes this. In fact, I have no idea why the FSF would even claim otherwise; Apple's interpretation seems to be perfectly in line with the entire point of the anti-TiVoization clause.
If Apple were to accidentally ship GPLv3 software on iOS 11, under whatever interpretation you subscribe to, how is Apple supposed to remain in compliance with GPLv3 without releasing their root signing keys? Remember, we're talking about shipping this on existing devices, not on some hypothetical future device where they can add extra user-swappable keys to the bootloader.
You keep insisting that Apple's interpretation is wrong, but you haven't provided any alternative interpretation.
> If you want to start claiming that it's a "common interpretation" you need to show that there is a larger community than the Linux community that uses the GPLv3
That's a catch-22. There isn't a larger community because GPLv3 is toxic to companies. Nobody else is going to create a larger ecosystem of GPLv3 code because doing so basically means turning into Linux.
Apple's interpretation of "we cannot design a system where you can have signed binaries [where you can replace the root signing keys] that complies with the GPLv3"? That's not what the GPLv3 changes meant.
Please just read the GPLv3 and make up your own mind, this is getting ridiculous. No reasonable interpretation of that section means that it is not possible to design a system that has binary signing and complies with the GPLv3. Apple's current system could not comply without releasing the root signing keys, but that's because they decided to design their system that way.
> If Apple were to accidentally ship GPLv3 software on iOS 11 ...
We're not talking about them accidentally shipping it. We're talking about them deciding to not update to GPLv3, and the justification being "security". Obviously accidentally shipping it would cause them issues, but that's
> Remember, we're talking about shipping this on existing devices, not on some hypothetical future device where they can add extra user-swappable keys to the bootloader.
You might be talking about that. That's not what I was talking about. I was talking about them designing products that explicitly don't allow user-swapping is the problem, and that there is no fundamental reason why you cannot have a secure system that allows user-swapping keys.
Of course a current device would be insecure if the root signing keys were released, because their threat model doesn't take that into account.
> There isn't a larger community because GPLv3 is toxic to companies.
I work for a company that releases GPLv3 software all the time. I've started projects that are GPLv3 as an employee. It's only toxic to companies that don't want to comply with free software licenses.
This is all just more FUD.
> This is all just more FUD.
Please stop calling things FUD just because you don't like it.
I guess you were in a different thread than me. The discussion started with saying that "they don't use GPLv3 purely because of security concerns as they cannot have a secure system". I outlined that yes you can, you said that "currently Apple's system doesn't work that way" and now you're saying that discussing whether or not it is possible to create such a system is off-topic.
Maybe I just misunderstood what you meant, but if that's the case then it still doesn't justify you broadly making incorrect claims about the GPLv3. You should say something like "Because Apple doesn't have the ability to replace the keys by the user, they cannot use GPLv3 as that would make their system insecure". You cannot omit the first part as it makes the statement incorrect.
> Please stop calling things FUD just because you don't like it.
"GPLv3 is toxic to companies" is FUD. It promotes fear through the use of the word "toxic", it promotes uncertainty by challenging a well-established license with vague concerns, and it seeds doubt in whether the license will be toxic to their company. As many companies do use and ship GPLv3 software and aren't being killed by this hypothetical toxicity, this is FUD.
It just so happens that I don't like that you said it, but that's because I don't like people spreading FUD. ;)
No, the reason they don't put it on GitHub is that they have no intention of participating in the community that made the software they are using.
All of these tools already have sites, communities, repositiories, etc. Apple could easily participate as many other companies do who also have proprietary patches. Apple actively chooses this over being a member of the software community it takes so much from.
Are you even sure Apple is using libstdc++ at all and not libc++ as on macOS?
The source for libgit2 itself is not present on their opensource site, though they use it in Xcode. (Git itself is present, but is sometimes out of date compared to what they're actually shipping.)
I've emailed them about this and they offered to provide me the source they used. This feels like they're trying to do the bare minimum of compliance - and making even that nonobvious (since they have an obvious distribution mechanism.)
This complaint is not a claim that they're violating our license, but it's definitely not an ideal situation, and I'm sympathetic to your frustration.
> In addition to the permissions in the GNU General Public License, the authors give you unlimited permission to link the compiled version of this library into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. [...]
It allows people to link it in their non-free, proprietary software without any vitality on that proprietary software. It still requires them to make the source for the version of libgit2 that they are using available upon request.
Just to note that Swift is on GitHub[0] and has a very inclusive community.
The impression I get is that Apple isn't really interested in soliciting outside contributions for their OS/kernel code, which is why they're just code dumps.
You could ask why it's not on a private github repo, and the answer is that Apple's code predates Github by probably up to a decade, and depending on workflow and privacy reasons being on github is probably useless and/or veto'ed by their legal department.
There are so many ways to work on open source. Github is just one tool.
sigh
What do we have to do to get Apple to actually update OpenSSL? It's beyond ridiculous. They're shipping the OS with a version of OpenSSL that is completely unsupported, and doesn't support newer security features.
This is very old news, and has been hashed out many times. The thing I don't understand is why no-one has created a shim on top of Apple's SecurityFramework to mimic OpenSSL, so things could be compiled against it. While it would be near-impossible to do this for all of OpenSSL's many features/modes (most people hate this), my bet is that it would not take much to completely cover what 90+% of projects need.
I previously thought zsh fit the Apple ethos and aesthetic the best with its nice completions and clean(er) syntax.
Now I wish they’d start shipping fish as it provides such a nice experience out of the box, and is gplv2
I would not care either way since I just use ohmyzsh, their github page has a shell oneliner to install it, good enough for me
Edit: to clarify, any shell script that is executed will define its own shell to execute with (the #! line).
There may be some issues if scripts have declared their shell as /bin/sh but they use bashisms, and then /bin/sh isn't provided by bash anymore, but honestly that's not necessarily related.
The discussion here is about changing the default login shell for interactive user accounts to fish.
If they did this though, it would be nice if they would use dash for /bin/sh, but I'm not sure how that's licenced - possibly gpl3 too?
Ironically, the primary developer of fish is an Apple employee. This is probably a significant reason why it's GPLv2 and not v3!
Also, I had no idea the fish dev worked at Apple. I have no hopes of them going with that as a default, but I could certainly see them shipping it as part of the os...
Source code: https://github.com/fish-shell/fish-shell
I remember the days where each login into an UNIX system would give me a totally different shell.
But all relevant ones were installed, so it was only a matter of having the right shebang paths.
So if Apple has a deal with a patent troll which has a an obvious broken patent that covers all and every program (but which would fall apart if challenged), then apple could in theory get into trouble with the troll if they distributed GPLv3 software.
There is precedent for the latter. When Red Hat paid off the Firestar troll, it negotiated a patent license for all recipients of the software, including upstream and derivative versions.
Discouraging individual patent deals with a troll while leaving the rest of the community (from whose software you benefit) vulnerable doesn't seem like a bad thing to me.
That sounds like an odd thing to wish for in software where you are the user. That's asking for less freedom.
So why would you do that?
> Shipping old stuff is unacceptable and it's not like we can't install it if we want it.
I can't see how 1. this is related and 2. how Apple would bother putting in the effort to replacing its full toolchain with completely different implementations when they can't even bother updating the one they already have.
Basically... This is all on Apple's hand.
But if you want a modern, updated toolset which you know will be kept up to date, I know there are lots of Linux distros out there which can deliver what Apple seemingly can not.
First, the BSD license offers more total freedom than the GPL does. I say this despite liking both the FSF and the GPL.
Second, I would rather have up to date version of good BSD software than an old versions of good GPL software.
That's objectively false. GPL provides more end-user freedom. BSD provides more developer freedom.
There's not a single license which objectively and universally offers more freedom.
> I would rather have up to date version of good BSD software than an old versions of good GPL software.
False dichtohomy. That's comparing rotten apples to ripe oranges.
You either have to compare old GPL to old BSD or new GPL to new BSD.
And as an end-user I would prefer both new and GPL.
I disagree. Forcing people to do things is not "more freedom", although the GPL's goals are laudable.
"False dichtohomy. That's comparing rotten apples to ripe oranges. You either have to compare old GPL to old BSD or new GPL to new BSD. And as an end-user I would prefer both new and GPL."
Unfortunately, new and GPL is not an option. But this result is what the FSF wanted when they created the GPL3.
This debate has been had a million times.
Every time reasonable people agree you have to choose one or the other.
You can't have both.
I see no reason to re-iterate that debate though. I'd just like to point out that your view is not the prevalent nor accepted one.
The version difference?
That's quite easy to work around. Just name your python 3 binary "python3".
I remember when Darwin was binary ISOs, and then it just became source code and you had to hunt all over the Internet for ISOs as Apple didn't make them anymore and then anyone that did you suspect of putting a trojan in the binary.
I assume this MacOS Source is the parts of MacOS that go back into BSD Unix that Apple promises to share with the free and open source communities?
Anyone tried compiling the source code yet to see if it works and can be made into a binary ISO file?
Also how hard it is to use it with CMake?
Would be nice to get a base docker image going instead of using VM though...might add this to the side project list!