4 ms·

Any particular reason why it needs to be on GitHub?

jsjohnst 9y ago
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.
- 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.
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.