6 ms·

Tiger was the apex of developer-friendly FOSS-friendly Apple. You can find the last official guide to modifying and compiling the xnu kernel from that time. D

Tiger was the apex of developer-friendly FOSS-friendly Apple. You can find the last official guide to modifying and compiling the xnu kernel from that time. Documentation was fabulous. I miss those times.

easton 5y ago
It’s kind of sad when you find a great Apple doc that there’s a 90% chance the top of the page says “Documentation Archive”.
azalemeth 5y ago
Also, the GUI for building GUIs was great. Nothing really made you appreciate why they wanted objects so much as dragging buttons around and instantiating the class. It made sense internally to me as a university student at the time. Objective C was a "relatively simple" set of extensions (which I never really understood) over C (which I claimed to understand at the time) and the language made you aware of both "the magic" of what you were doing and, at the same time, how it related to the bare metal. I learnt a lot from it. I'd love to know what this looks like to a straight-out-of-university developer of an Electron app, though.
- zarzavat 5y ago
  Making GUIs was easy as long as you stayed on the happy path, but the moment you needed to do something different you were back to writing reams of code, there was a cottage industry of custom NSSplitView classes. Even just making a button a different color involved reinventing the wheel a substantial amount. The current Electron/React approach has no happy path - everything uniformly requires some amount of boilerplate code. But when you need to deviate you are less likely to have to write a novella.
  - Wowfunhappy 5y ago
    > Making GUIs was easy as long as you stayed on the happy path, but the moment you needed to do something different you were back to writing reams of code I'm making this up, but perhaps this was beneficial for UI consistency across apps anyway?
    - zarzavat 5y ago
      Yes it was. But such consistency is double edged sword because it also leads to “if all you have is a hammer” UIs where UI elements are abused for roles that they shouldn’t be used for, because the alternative custom UI costs so much development time. In general I’d say UIs are much better these days functionally, at the cost of much less consistent look and feel (UX) across apps.
- nottorp 5y ago
  Hmm Delphi 1 (RIP) was released in 1995. When did Cocoa/Interface Builder show up?
  - WoodenChair 5y ago
    > Hmm Delphi 1 (RIP) was released in 1995. When did Cocoa/Interface Builder show up? 1988 [0] [0] https://en.wikipedia.org/wiki/Interface_Builder https://en.wikipedia.org/wiki/Interface_Builder
    - marcodiego 5y ago
      And it came from an older (1986) project from expertelligence. There is a video about it: https://vimeo.com/62618532 https://vimeo.com/62618532
      - hokumguru 5y ago
        This is a beautiful video.
  - tambourine_man 5y ago
    NeXTStep and Project Builder (which XCode was based on) was realease in 1989 edit: WoodenChair beat me to it with the right date
    - nottorp 5y ago
      Ahh NextStep. For some reason I was only thinking of Mac OS. Possibly because in 1988 i was a kid with an 8 bit spectrum clone who only saw NeXT machines in magazines ;) Still, RIP both Interface Builder and Delphi.
  - deleted 5y ago
    [deleted]
- yoz-y 5y ago
  Having implemented multiple programs in GUIs for GUIs (with GtK, UIKit and dabbling with AppKit)... I must say that I have my past self every time I want to go back and look how something works. At least with SwiftUI / reactive things the code can be searched and navigated and doesn't take ages to load.
toyg 5y ago
It's not just Apple. Microsoft also stopped producing first-party documentation on low-level technology, just because they wanted to stop people from using certain things even though they were still very much a fundamental part of Windows.
kzrdude 5y ago
I do too. It was around this time I left my kiddie days as OS X dev behind and became an adolescent Linux dev. :) It's actually true, been using Linux since then, it was just a much better hacker environment.
sbuk 5y ago
The decline of 'FOSS-friendly' Apple coincides with the re-licensing of many projects under the GPLv3, which is decidedly enterprise-hostile by design. I concur that the developer documentation need improvement.
- smichel17 5y ago
  Can you elaborate on how GPLv3 is enterprise-hostile? My impression was that the main change was fixing the tivo loophole.
  - sbuk 5y ago
    GPLv3 addresses definitions (such as what constitutes source-code), software license compatibility, software patents as well as tivotization. The clauses around software patents are what I was referring to. By design, they are hostile towards software patents. Hence for instance Apple not updating BASH for so long (macOS still ships with BASH 3.2.57, the last version that was GPLv2) and the switch to (the MIT licensed) Z shell. Not commenting on the legitimacy of software patents, Apple's take on using GPLv3 licensed software - merely stating cause and effect.
  - kitsunesoba 5y ago
    I believe that most corporate legal departments (who are the ones controlling what licenses can/can’t be used, not the engineers) received GPLv3 as an end to simple ways to guarantee that GPL had no possibility of bringing legal trouble. Even if it’s technically possible to comply with GPLv3 without open sourcing proprietary code, there’s enough caveats/hoop jumps involved that it was seen as too risky to even try. They don’t want, “no legal issues as long as”, they want a flat, unconditional “no legal issues ever”.
  - kmeisthax 5y ago
    Well, GPLv3's installation instructions requirement more or less is targeted squarely at consumer electronics companies and that includes Apple. If Apple were to include GPLv3 software in iOS, the only way to comply with the license would be to significantly alter their security model to include an owner override. While there are ways that Apple could still use GPLv3 software, not change their security model, and remain in compliance[0]; I imagine they decided it would be easier to just ban new GPL software in their OS entirely rather than deal with the compliance headaches. Apple in particular never shipped any GPLv3 software in their OS and stopped updating even v2 software. They used to be very heavy GCC users, but wrote their own permissively-licensed compiler that outdoes it in almost every way. In their defense, they actually wanted LLVM to be an upstream FSF project; but RMS famously lost the e-mail because he daily-drives barely functional ancient laptops. In a sense, that too is enterprise-hostility; albeit not owing to choice of license. I imagine that if the FSF had agreed to refactor GCC the way Apple wanted, Apple would have gone through the time and effort of GPLv3 compliance. I'd also argue that GPLv3 didn't actually fix the TiVo loophole. It can't - not unless we're going to pull an SSPL and start writing copylefts that trip on software that merely runs alongside Linux. The way TiVo got around the GPLv2 installation instructions requirement was to make their own proprietary app enforce the kernel lockout rather than the bootloader, and prohibiting that would be very draconian. That being said, you also should take into account the historical context of GPLv3's announcement and development. The FSF had some pretty crazy ideas, like rolling the Affero clause into GPLv3, that probably scared people into dropping their upgrade clauses even if it never actually made it into an actual FSF license document. The end document we actually got is relatively tame, but the message the FSF sent was that they were willing to ship whatever license language they felt met their personal definition of software freedom. If you didn't like any new restrictions they added to your own code, tough. [0] Stuff that runs in a sandbox container and doesn't use private entitlements probably isn't violating GPLv3, because Apple hands out free dev accounts that let you compile and run whatever, albeit with some annoying requirements to renew the app's signature every week.
gilgoomesh 5y ago
The recent (6 months ago) XNU kernel can still be compiled. Instructions are part of the GitHub repo: https://github.com/apple/darwin-xnu https://github.com/apple/darwin-xnu
- saagarjha 5y ago
  Those instructions are for Apple employees. If you want to build XNU, follow this: https://kernelshaman.blogspot.com/ https://kernelshaman.blogspot.com/

easton 5y ago

It’s kind of sad when you find a great Apple doc that there’s a 90% chance the top of the page says “Documentation Archive”.

azalemeth 5y ago

Also, the GUI for building GUIs was great. Nothing really made you appreciate why they wanted objects so much as dragging buttons around and instantiating the class. It made sense internally to me as a university student at the time. Objective C was a "relatively simple" set of extensions (which I never really understood) over C (which I claimed to understand at the time) and the language made you aware of both "the magic" of what you were doing and, at the same time, how it related to the bare metal. I learnt a lot from it. I'd love to know what this looks like to a straight-out-of-university developer of an Electron app, though.

zarzavat 5y ago
Making GUIs was easy as long as you stayed on the happy path, but the moment you needed to do something different you were back to writing reams of code, there was a cottage industry of custom NSSplitView classes. Even just making a button a different color involved reinventing the wheel a substantial amount. The current Electron/React approach has no happy path - everything uniformly requires some amount of boilerplate code. But when you need to deviate you are less likely to have to write a novella.
- Wowfunhappy 5y ago
  > Making GUIs was easy as long as you stayed on the happy path, but the moment you needed to do something different you were back to writing reams of code I'm making this up, but perhaps this was beneficial for UI consistency across apps anyway?
  - zarzavat 5y ago
    Yes it was. But such consistency is double edged sword because it also leads to “if all you have is a hammer” UIs where UI elements are abused for roles that they shouldn’t be used for, because the alternative custom UI costs so much development time. In general I’d say UIs are much better these days functionally, at the cost of much less consistent look and feel (UX) across apps.
nottorp 5y ago
Hmm Delphi 1 (RIP) was released in 1995. When did Cocoa/Interface Builder show up?
- WoodenChair 5y ago
  > Hmm Delphi 1 (RIP) was released in 1995. When did Cocoa/Interface Builder show up? 1988 [0] [0] https://en.wikipedia.org/wiki/Interface_Builder https://en.wikipedia.org/wiki/Interface_Builder
  - marcodiego 5y ago
    And it came from an older (1986) project from expertelligence. There is a video about it: https://vimeo.com/62618532 https://vimeo.com/62618532
    - hokumguru 5y ago
      This is a beautiful video.
- tambourine_man 5y ago
  NeXTStep and Project Builder (which XCode was based on) was realease in 1989 edit: WoodenChair beat me to it with the right date
  - nottorp 5y ago
    Ahh NextStep. For some reason I was only thinking of Mac OS. Possibly because in 1988 i was a kid with an 8 bit spectrum clone who only saw NeXT machines in magazines ;) Still, RIP both Interface Builder and Delphi.
- deleted 5y ago
  [deleted]
yoz-y 5y ago
Having implemented multiple programs in GUIs for GUIs (with GtK, UIKit and dabbling with AppKit)... I must say that I have my past self every time I want to go back and look how something works. At least with SwiftUI / reactive things the code can be searched and navigated and doesn't take ages to load.

toyg 5y ago

It's not just Apple. Microsoft also stopped producing first-party documentation on low-level technology, just because they wanted to stop people from using certain things even though they were still very much a fundamental part of Windows.

kzrdude 5y ago

I do too. It was around this time I left my kiddie days as OS X dev behind and became an adolescent Linux dev. :) It's actually true, been using Linux since then, it was just a much better hacker environment.

sbuk 5y ago

The decline of 'FOSS-friendly' Apple coincides with the re-licensing of many projects under the GPLv3, which is decidedly enterprise-hostile by design. I concur that the developer documentation need improvement.

smichel17 5y ago
Can you elaborate on how GPLv3 is enterprise-hostile? My impression was that the main change was fixing the tivo loophole.
- sbuk 5y ago
  GPLv3 addresses definitions (such as what constitutes source-code), software license compatibility, software patents as well as tivotization. The clauses around software patents are what I was referring to. By design, they are hostile towards software patents. Hence for instance Apple not updating BASH for so long (macOS still ships with BASH 3.2.57, the last version that was GPLv2) and the switch to (the MIT licensed) Z shell. Not commenting on the legitimacy of software patents, Apple's take on using GPLv3 licensed software - merely stating cause and effect.
- kitsunesoba 5y ago
  I believe that most corporate legal departments (who are the ones controlling what licenses can/can’t be used, not the engineers) received GPLv3 as an end to simple ways to guarantee that GPL had no possibility of bringing legal trouble. Even if it’s technically possible to comply with GPLv3 without open sourcing proprietary code, there’s enough caveats/hoop jumps involved that it was seen as too risky to even try. They don’t want, “no legal issues as long as”, they want a flat, unconditional “no legal issues ever”.
- kmeisthax 5y ago
  Well, GPLv3's installation instructions requirement more or less is targeted squarely at consumer electronics companies and that includes Apple. If Apple were to include GPLv3 software in iOS, the only way to comply with the license would be to significantly alter their security model to include an owner override. While there are ways that Apple could still use GPLv3 software, not change their security model, and remain in compliance[0]; I imagine they decided it would be easier to just ban new GPL software in their OS entirely rather than deal with the compliance headaches. Apple in particular never shipped any GPLv3 software in their OS and stopped updating even v2 software. They used to be very heavy GCC users, but wrote their own permissively-licensed compiler that outdoes it in almost every way. In their defense, they actually wanted LLVM to be an upstream FSF project; but RMS famously lost the e-mail because he daily-drives barely functional ancient laptops. In a sense, that too is enterprise-hostility; albeit not owing to choice of license. I imagine that if the FSF had agreed to refactor GCC the way Apple wanted, Apple would have gone through the time and effort of GPLv3 compliance. I'd also argue that GPLv3 didn't actually fix the TiVo loophole. It can't - not unless we're going to pull an SSPL and start writing copylefts that trip on software that merely runs alongside Linux. The way TiVo got around the GPLv2 installation instructions requirement was to make their own proprietary app enforce the kernel lockout rather than the bootloader, and prohibiting that would be very draconian. That being said, you also should take into account the historical context of GPLv3's announcement and development. The FSF had some pretty crazy ideas, like rolling the Affero clause into GPLv3, that probably scared people into dropping their upgrade clauses even if it never actually made it into an actual FSF license document. The end document we actually got is relatively tame, but the message the FSF sent was that they were willing to ship whatever license language they felt met their personal definition of software freedom. If you didn't like any new restrictions they added to your own code, tough. [0] Stuff that runs in a sandbox container and doesn't use private entitlements probably isn't violating GPLv3, because Apple hands out free dev accounts that let you compile and run whatever, albeit with some annoying requirements to renew the app's signature every week.

gilgoomesh 5y ago

The recent (6 months ago) XNU kernel can still be compiled. Instructions are part of the GitHub repo: https://github.com/apple/darwin-xnu https://github.com/apple/darwin-xnu

saagarjha 5y ago
Those instructions are for Apple employees. If you want to build XNU, follow this: https://kernelshaman.blogspot.com/ https://kernelshaman.blogspot.com/