3 ms·

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 re

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.

feld 9y ago
I don't think they've ever released code with version history, so it would provide little benefit other than a famliar UX.
- jsjohnst 9y ago
  To my knowledge, they haven't either (outside what is on Github already). The point being it would be great if they did.
- turdnagel 9y ago
  Apple's Swift programming language is on GitHub -- the full history AFAIK. https://github.com/apple/swift https://github.com/apple/swift
- epipping 9y ago
  That depends. You don’t have any helpful commit logs or even changelogs. But if you arrange e.g. the XNU releases in the form of a reasonable graph and import them into git that way, you can get some telling diffs, on the command line at least. GitHub is not being very helpful here because it does not allow you to diff arbitrary tags and revisions from a repository. But GitHub is still a place where people find and look for code. Those thoughts prompted me to create https://github.com/epipping/xnu-kernel-sources-x86 https://github.com/epipping/xnu-kernel-sources-x86 (and its cousin https://github.com/epipping/xnu-kernel-sources-ppc https://github.com/epipping/xnu-kernel-sources-ppc). Maybe you find it help (please take a look at the wiki)
dfox 9y ago
Over last 10 or so years there were various conflicts between open source projects and Apple that were caused by absence of publicly accessible version history for open source code shipped by Apple as part of OS X. Probably most significant such conflict was around KHTML/WebKit (and I somewhat believe that Chrome was at least partially Google's reaction to that)
- michel-slm 9y ago
  Google forked WebKit and called it Blink, which Chrome uses. It might be partly this but I guess also that Google prioritized implementing a multi-process architecture.
  - kitsunesoba 9y ago
    As I understand, the fork was more about architectural disagreements between Google and the WebKit team. For instance, in Chrome the multiprocess system is part of Chrome whereas WebKit does multiprocess within WebKit itself. This means that anything embedding WebKit2 automatically gets multiprocess, where to get the same with Blink you've gotta fork Chromium. 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.
    - rlanday 9y ago
      A couple clarifications: - 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.
      - gsnedders 9y ago
        This is more or less my memory of the fork. Google were a major contributor, wanted to make some different decisions in various places to Apple and spent lots of time trying to make Apple happy, and concluded the quickest way to make progress was to fork and not have to convince other contributors (even with the resultant loss of contributions from others). 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.
astrodust 9y ago
Apple is a big fan of GitHub, you can see evidence of that with the Swift project (https://github.com/apple/swift https://github.com/apple/swift), but not everything is suitable for that sort of treatment. 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.

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.

feld 9y ago

I don't think they've ever released code with version history, so it would provide little benefit other than a famliar UX.

jsjohnst 9y ago
To my knowledge, they haven't either (outside what is on Github already). The point being it would be great if they did.
turdnagel 9y ago
Apple's Swift programming language is on GitHub -- the full history AFAIK. https://github.com/apple/swift https://github.com/apple/swift
epipping 9y ago
That depends. You don’t have any helpful commit logs or even changelogs. But if you arrange e.g. the XNU releases in the form of a reasonable graph and import them into git that way, you can get some telling diffs, on the command line at least. GitHub is not being very helpful here because it does not allow you to diff arbitrary tags and revisions from a repository. But GitHub is still a place where people find and look for code. Those thoughts prompted me to create https://github.com/epipping/xnu-kernel-sources-x86 https://github.com/epipping/xnu-kernel-sources-x86 (and its cousin https://github.com/epipping/xnu-kernel-sources-ppc https://github.com/epipping/xnu-kernel-sources-ppc). Maybe you find it help (please take a look at the wiki)

dfox 9y ago

Over last 10 or so years there were various conflicts between open source projects and Apple that were caused by absence of publicly accessible version history for open source code shipped by Apple as part of OS X. Probably most significant such conflict was around KHTML/WebKit (and I somewhat believe that Chrome was at least partially Google's reaction to that)

michel-slm 9y ago
Google forked WebKit and called it Blink, which Chrome uses. It might be partly this but I guess also that Google prioritized implementing a multi-process architecture.
- kitsunesoba 9y ago
  As I understand, the fork was more about architectural disagreements between Google and the WebKit team. For instance, in Chrome the multiprocess system is part of Chrome whereas WebKit does multiprocess within WebKit itself. This means that anything embedding WebKit2 automatically gets multiprocess, where to get the same with Blink you've gotta fork Chromium. 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.
  - rlanday 9y ago
    A couple clarifications: - 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.
    - gsnedders 9y ago
      This is more or less my memory of the fork. Google were a major contributor, wanted to make some different decisions in various places to Apple and spent lots of time trying to make Apple happy, and concluded the quickest way to make progress was to fork and not have to convince other contributors (even with the resultant loss of contributions from others). 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.

astrodust 9y ago

Apple is a big fan of GitHub, you can see evidence of that with the Swift project (https://github.com/apple/swift https://github.com/apple/swift), but not everything is suitable for that sort of treatment. 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.