Hey, this is Cliff aka InSaneDarwin from PureDarwin Project we have a vm that is coming along nicely if anyone has seen our home page(http://www.puredarwin.org). We are looking for some help with our own ACPI/Platform Expert and so I/OKit Drivers if you guys are looking for some fun come join us.
If I understand correctly, this should be able to run on any Intel platform, so it's not bound to Apple-labelled hardware, right?
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).
There are various companies online that give you remote access to a macOS VM running on Apple hardware, reasonably inexpensively. I use one for Mac & iOS builds. The one I use says in the contract that I am actually buying fractional ownership of the computer, along with hosting. I guess this gets around some Apple terms somehow.
This is not macOS. According to the screenshot of the latest build, it doesn't look like it even boots all the way to a shell. It is unlikely to ever help you with mobile app publishing.
A really great niche that would play to your strengths is as a build environment for Mac software. The existing macs are terrible for this purpose, and really sometimes you want a rack mounted build server somewhere.
I don't follow Apple open source, so I have a lot of questions: What parts of MacOS are open source, and which are not? How is it licensed? Why is this on their website rather than GitHub?
As Apple is not developing this software in the public, it would not make sense to put it on GitHub or any other code hosting site. The usual approach is that Apple throws bits over the wall where you can pick them up months after the end-user release. And even these code drops will be thoroughly cleaned before, so that for example kernel sources do not contain any trace of support for ARM or anything else related to the iPhone – all of that is strictly closed source.
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.
> As Apple is not developing this software in the public, it would not make sense to put it on GitHub or any other code hosting site
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.
> Apple avoids the GPLv3 for legal reasons due to its patent clause.
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).
There's too much cargo cult information getting repeated in this thread and going unquestioned. Apple doesn't care about the patent grant parts of GPLv3. The Apple Public Source License was an early pioneer in granting patent rights. Most modern commentary FOSS licenses are modeled after the grant from the APSL, starting with Apache 2.0, and including MPL2 and GPLv3. There's nothing in the GPLv3 for Apple to quibble about wrt patents; it has everything to do with the GPL's Tivoization stance.
Much of the kernel (XNU), forks of BSD utilities, WebKit, LLVM/Clang, and various other projects are hosted there. This site predates GitHub, but folks have mirrors hosted there of most projects. Apple’s newer open source projects (Swift, ResearchKit, etc) are on GitHub.
You had many questions, but source code doesn't need to be on Github to be open source, especially when it's being maintained and developed purely by people hired on the core os team inside apple.
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.
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.
Some of their stuff is on Github, but must of their stuff is on the linked website. The stuff that is open sourced here is mainly stuff like the Mach kernel, the BSD base system utilities, etc. For the most part, I didn't find the stuff here very useful, with the exception of an issue with 802.11x back in OS X 10.5 days. Was nice being able to reference the exact line in the code in the Radar I filed that was causing the issue.
Having it hosted on some kind of revision control system would be very useful and GitHub is the most prominent public place to do that, but otherwise no real reason.
As long as my memory is still working, the closed parts were mostly the GUI (Aqua), the network stack, and (of course) all the utilities like mail client, iTunes, etc.
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.
Apple announced many years ago now that they were not going to update the version of OpenSSL, and that the reason they were not going to do that was because of binary (and source) incompatibilities that OpenSSL routinely causes in major updates.
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.
Because they patched it and they don't use it themselves, it's only for backwards compatibility. On top of that, it is not 'supported' by Apple, all programs for macOS use Objective-C and Swift libraries that abstract crypto to the point where it doesn't matter if under water some OpenSSL/LibreSSl/BoringSSL call is made.
A little disappointed to see that they're still shipping Ruby 2.0; a version shipped 4 years ago. I would hope that they would update this soon to keep up to date with the language and security patches
Never expect Apple to ship anything recent. Anything outside of their own "core system" that depends on 3rd party packages is likely to be 2, 3, 8 years out of date. Software like brew and macports aren't only popular for "extra" software; they're popular for replacing bundled software that is severely out-of-date. Last time I started from scratch, that included updating git and php from versions so old that it was laughable. Let us be thankful that these alternatives exist.
Just to be clear, though, this isn't because Apple isn't interested in updating things. It's specifically because much of that software moved to GPLv3, and Apple won't include any software with that license. (The internal documentation is very clear about that haha.)
What I would like to see is for them to ditch all the GNU/GPL stuff and go with BSD for userland. Shipping old stuff is unacceptable and it's not like we can't install it if we want it.
> What I would like to see is for them to ditch all the GNU/GPL stuff and go with BSD for userland.
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.
At this point it could well be about keeping backwards compatibility. There are some obscure cases where the bash on mac behaves differently to a modern one. And there are going to be scripts relying on it.
Personally, this is why I would prefer that UNIX vendors/distributions not include advanced languages like Python, Perl, Lua, and Ruby. It seems like it ends up causing more issues than it solves.
Readit News
>>"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).
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.
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.
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).
https://webkit.org/getting-the-code/
The same is true for LLVM / Clang:
http://llvm.org/docs/GettingStarted.html#checkout
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.
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.
[0] https://github.com/apple/swift
Deleted Comment
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.
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.
The version difference?
That's quite easy to work around. Just name your python 3 binary "python3".