Live data from Hacker News

Apple’s Darwin OS and XNU Kernel Deep Dive

tansanrao.com

101–110 of 186 posts

Re: Apple’s Darwin OS and XNU Kernel Deep Dive

#101
post #80

Earlier quoted context omitted.

> As things now stand, FreeBSD represents many of the benefits of Darwin and the open source nature of Linux. No. FreeBSD has committed the original sin of UNIX by deliberately dropping support for all non-Intel architectures, intending to focus on optimising FreeBSD for the Intel ISA and platforms. UNIX portability and support for a diverse range of CPU's and hardware platforms are ingrained in the DNA of UNIX, howe…

I am very skeptical that it's primarily caused by the focus on Intel CPUs. FreeBSD already fell into obscurity way before RISC-V. And even though they missed the ARM router/appliance boat, Linux already overtook FreeBSD when people were primarily using Linux for x86 servers and (hobbyist) desktops. The Netcraft has confirmed: BSD is dying Slashdot meme was from the late 90ies or early 2000s. Also, if this was the mai…

The AT&T lawsuits are a moot point, as they were all settled in the early 1990s. They are the sole reason why FreeBSD and NetBSD even came into existence – by forking the 4.4BSD-Lite codebase after the disputed code had been eliminated or replaced with non-encumbered reimplementations. Otherwise, we would all be running on descendants of 4.4BSD-Lite today.

Linux has been running uninterruptedly on s/390 since October 1999 (31-bit support, Linux v2.2.13) and since January 2001 for 64-bit (Linux v2.4.0). Linux mainlined PPC64 support in August 2002 (Linux v2.4.19), and it has been running on ppc64 happily ever since, whereas FreeBSD dropped ppc64 support around 2008–2010. Both s/390 and ppc64 (as well as many others) are hardly hobbyist platforms, and both remain in active use today. Yes, IBM was behind each port, although the Linux community has been a net $0 beneficiary of the porting efforts.

I am also of the opinion that licensing is a red herring, as BSD/MIT licences are best suited for proprietary, closed-source development. However, the real issue with proprietary development is its siloed nature, and the fact that closed-source design and development very quickly start diverging from the mainline and become prohibitively expensive to maintain in-house long-term. So the big wigs quickly figured out that they could make a sacrifice and embrace the GPL to reduce ongoing costs. Now, with the *BSD core team-led development, new contributors (including commercial entities) would be promptly shown the door, whereas the Linux community would give them the warmest welcome. That was the second major reason for the downfall of all things BSD.

Re: Apple’s Darwin OS and XNU Kernel Deep Dive

#103
post #53

Earlier quoted context omitted.

Making a switch is one thing, but using Linux from the start for OS X would have made more sense. The only reason that didn't happen is because of Jobs' attachment to his other baby. It wasn't a bad choice, but it was a choice made from vanity and ego over technical merit.

You haven’t really expanded on why basing off the Linux kernel would have made more sense, especially at the time. People have responded to you with timelines explaining why it couldn’t have happened but you seem to keep restating this claim without more substance or context to the time. Imho Linux would have been the wrong choice and perhaps even the incorrect assumption. Mac is not really BSD based outside of the u…

Well for starters, it would have better memory management. The XNU kernel's memory manager has poor time complexity. If I create a bunch of sparse memory maps using mmap() then XNU starts to croak once I have 10,000+ of them.

Re: Apple’s Darwin OS and XNU Kernel Deep Dive

#104
post #80

Earlier quoted context omitted.

> As things now stand, FreeBSD represents many of the benefits of Darwin and the open source nature of Linux. No. FreeBSD has committed the original sin of UNIX by deliberately dropping support for all non-Intel architectures, intending to focus on optimising FreeBSD for the Intel ISA and platforms. UNIX portability and support for a diverse range of CPU's and hardware platforms are ingrained in the DNA of UNIX, howe…

Having used continuously both FreeBSD and Linux, wherever they are best suited, since around 1995 until today, I disagree. In my opinion the single factor that has contributed the most to a greater success for Linux than for FreeBSD has been the transition to multithreaded and multicore CPUs even in the cheapest computers, which has started in 2003 with the SMT Intel Pentium 4, followed in 2005 by the dual-core AMD C…

Whilst I do agree with most of your insights and the narrative of historic events, I also believe that BSD core teams were a major contributing factor to the demise of BSD's (however unpopular such an opinion might be).

The first mistake was that all BSD core teams flatly refused to provide native support for the JVM back in its heyday. They eventually partially conceded and made it work using Linux emulation; however, it was riddled with bugs, crashes and other issues for years before it could run Java server apps. Yet, users clamoured to run Java applications, like, now and vociferously.

The second grave mistake was to flatly refuse to support containerisation (Docker) due to not being kosher. Linux based containerisation is what underpins all cloud computing today. Again, the FreeBSD arrived too late, and it was too little.

P.S. I still hold the view that FreeBSD made matters even worse by dropping support for non-Intel platforms early on – at a stage when its bleak future was already all but certain. New CPU architectures are enjoying a renaissance, whilst FreeBSD nervously sucks its thumb by the roadside of history.

Re: Apple’s Darwin OS and XNU Kernel Deep Dive

#105

That's a good history, but it skips over a lot of the nice security work that really distinguishes Apple's operating systems from Linux or Windows. There's a lack of appreciation out there for just how far ahead Apple now is when it comes to security. I sometimes wonder if one day awareness of this will grow and people working in sensitive contexts will be required to use a Mac by their CISO. The keystone is the code…

I do not think that "security" is the appropriate name for such features.

In my opinion "security" should always refer to the security of the computer owners or users.

These Apple features may be used for enhancing security, but the main purpose for which they have been designed is to provide enhanced control of the computer vendor on how the computer that they have sold, and which is supposed to no longer belong to them, is used by its theoretical owner, i.e. by allowing Apple to decide which programs are run by the end user.

Re: Apple’s Darwin OS and XNU Kernel Deep Dive

#106

That's a good history, but it skips over a lot of the nice security work that really distinguishes Apple's operating systems from Linux or Windows. There's a lack of appreciation out there for just how far ahead Apple now is when it comes to security. I sometimes wonder if one day awareness of this will grow and people working in sensitive contexts will be required to use a Mac by their CISO. The keystone is the code…

I do not think that "security" is the appropriate name for such features. In my opinion "security" should always refer to the security of the computer owners or users. These Apple features may be used for enhancing security, but the main purpose for which they have been designed is to provide enhanced control of the computer vendor on how the computer that they have sold, and which is supposed to no longer belong to…

I think you went for a lazy reply rather than actually reading the comment through. Most of the things mentioned here directly improve security for the computer's owner.

Re: Apple’s Darwin OS and XNU Kernel Deep Dive

#107

Earlier quoted context omitted.

WSL2 is just a Linux VM, and the POSIX subsystem is just a kluge I never heard of an OS/2 subsystem for NT, for which Cutler would take extreme umbridge in. I have three charts on my wall( now 4): the Unix timeline, the windows timeline, and the Linux distribution tree,and now a very decent MacOS X timeline. The personalities became containers which is just the windows version of common subsystem virtualization. Cont…

> I never heard of an OS/2 subsystem for NT, It was there from NT 3.1 until Windows 2000; it was removed in Windows XP onwards. It was very limited – it only supported character mode 16-bit OS/2 1.x applications. 32-bit apps, which IBM introduced with OS/2 2.0, were never supported. Microsoft offered an extra cost add-on called "Microsoft OS/2 Presentation Manager For Windows NT" aka "Windows NT Add-On Subsystem for…

> 32-bit apps, which IBM introduced with OS/2 2.0, were never supported.

This was obviously due to the divorce, but also that the Cruiser API wasn't finalized.

> Our initial OS/2 API set centers around the evolving 32-bit Cruiser, or OS/2 2.0 API set. (The design of Cruiser APIs is being done in parallel with the NT OS/2 design.)

...

> Given the nature of OS/2 design (the joint development agreement), we have had little success in influencing the design of the 2.0 APIs so that they are portable and reasonable to implement on non-x86 systems.

Re: Apple’s Darwin OS and XNU Kernel Deep Dive

#108

Earlier quoted context omitted.

I do not think that "security" is the appropriate name for such features. In my opinion "security" should always refer to the security of the computer owners or users. These Apple features may be used for enhancing security, but the main purpose for which they have been designed is to provide enhanced control of the computer vendor on how the computer that they have sold, and which is supposed to no longer belong to…

I think you went for a lazy reply rather than actually reading the comment through. Most of the things mentioned here directly improve security for the computer's owner.

> I think you went for a lazy reply rather than actually reading the comment through.

https://news.ycombinator.com/newsguidelines.html

Your reply could have omitted the first sentence.

Many years ago, at Macworld San Francisco, I met "Perry the Cynic", the Apple engineer who added code signing to Mac OS X. Nice person, but I also kind of hate him and wish I could travel back in time to stop this all from happening.

Re: Apple’s Darwin OS and XNU Kernel Deep Dive

#109

That's a good history, but it skips over a lot of the nice security work that really distinguishes Apple's operating systems from Linux or Windows. There's a lack of appreciation out there for just how far ahead Apple now is when it comes to security. I sometimes wonder if one day awareness of this will grow and people working in sensitive contexts will be required to use a Mac by their CISO. The keystone is the code…

I do not think that "security" is the appropriate name for such features. In my opinion "security" should always refer to the security of the computer owners or users. These Apple features may be used for enhancing security, but the main purpose for which they have been designed is to provide enhanced control of the computer vendor on how the computer that they have sold, and which is supposed to no longer belong to…

On macOS the security system is open even though the codebase is closed. You can disable SIP and get full root access. Gatekeeper can be configured to trust some authority other than Apple, or disabled completely. You can write and load your own sandbox policies. These things aren't well known and require reading obscure man pages, but the capabilities are there.

Even in the default out-of-the-box configuration, Apple isn't exercising editorial control over what apps you can run. Out of store distribution requires only a verified identity and a notarization pass, but notarization is a fully automated malware scan. There's no human in the loop. The App Store is different, of course.

Could Apple close up the Mac? Yes. The tech is there to do so and they do it on iOS. But... people have been predicting they'd do this from the first day the unfortunately named Gatekeeper was introduced. Yet they never have.

I totally get the concern and in the beginning I shared it, but at some point you have to just stop speculating give them credit for what they've actually done. It's much easier to distribute an app Apple executives don't like to a Mac than it is to distribute an app Linux distributors don't like to Linux users, because Linux app distribution barely works if you go "out of store" (distro repositories). In theory it should be the other way around, but it's not.

Post reply on HN