Apple’s Darwin OS and XNU Kernel Deep Dive
161–170 of 186 posts
Re: Apple’s Darwin OS and XNU Kernel Deep Dive
#162Earlier quoted context omitted.
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, Appl…
> Even in the default out-of-the-box configuration, Apple isn't exercising editorial control over what apps you can run Perhaps not in the strictest sense, but Apple continues to ramp up the editorial friction for the end user to run un-notarized applications. I feel/felt A level between "disable all security" and what macOS 15 introduces would be appreciated.
Re: Apple’s Darwin OS and XNU Kernel Deep Dive
#163I'm a bit disappointed at the lack of interest Apple seems to have on Rust, given their focus on performance, UX and security.
Re: Apple’s Darwin OS and XNU Kernel Deep Dive
#164Earlier quoted context omitted.
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; howeve…
Docker was created in 2013, long after BSDs had lost all their popularity. And, fwiw, FreeBSD pioneered containers long before Linux: https://en.m.wikipedia.org/wiki/FreeBSD_jail
Re: Apple’s Darwin OS and XNU Kernel Deep Dive
#165Earlier quoted context omitted.
1) We are talking about the late 90s, well before Ubuntu, where Desktop Linux was pretty poor in terms of features and polish. 2) Apple had no money or time to invest in rewriting NeXTStep for a completely new kernel they had no experience in. Especially when so many of the dev team was involved in sorting out Apple's engineering and tech strategy as well as all the features needed to make it more Mac like. 3) Apple…
>1) We are talking about the late 90s, well before Ubuntu, where Desktop Linux was pretty poor in terms of features and polish. I think it's hard to understate how much traction Linux had in the late 90's/ early 2000's. It felt like ground breaking stuff was happening pretty much all the time, major things were changing rapidly every release and it felt exciting and genuinely revolutionary to download updates and try…
Re: Apple’s Darwin OS and XNU Kernel Deep Dive
#166I'm a bit disappointed at the lack of interest Apple seems to have on Rust, given their focus on performance, UX and security.
Even Google on Android and ChromeOS is not exposing Rust to userspace, Java, Kotlin, C, C++, Javascript, Typescript, remain the official userspace languages.
Re: Apple’s Darwin OS and XNU Kernel Deep Dive
#167Earlier quoted context omitted.
> 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 lit…
Re: Apple’s Darwin OS and XNU Kernel Deep Dive
#168I'm a bit disappointed at the lack of interest Apple seems to have on Rust, given their focus on performance, UX and security.
They created Swift as replacement for C, C++ and Objective-C, why should they bother with Rust? Even Google on Android and ChromeOS is not exposing Rust to userspace, Java, Kotlin, C, C++, Javascript, Typescript, remain the official userspace languages.
Swift is not a replacemente for C and C++, but rather for Objective-C.
Do you have any sources for those claims?
Re: Apple’s Darwin OS and XNU Kernel Deep Dive
#169Earlier quoted context omitted.
> Has anyone found effective tools for maintaining this synchronization between documented architecture and implemented code? Yes, it's called structure, discipline, and iterative improvement. Keep the documentation alongside the code. Think in BSD terms: the OS is delivered as a whole; if I modify /bin/ls to support a new flag, then I update the ls.1 man page accordingly, preferably in the same commit/PR. The man pa…
> Has anyone found effective tools for... Managing management? Code comments and documentation make no money, only features make money. Bitter experience...
Software development is just one piece of the bigger picture that your manager is concerned with, same way as adding features is just one among your many responsibilities.
Managers understand risk. Communicate the risk of disregarding bugfixes, documentation, technical debt, even if it takes a lot of handholding. Expect no less from your manger: if they can communicate client expectations, budget constraints, and most importantly: long-term strategy, together you may be able to devise a better plan to address your own concerns.
In other words, empathy can go both ways.
And yeah, there are bad managers, just like there are bad coders. Sometimes it's an interpersonal problem. It's called life.
Re: Apple’s Darwin OS and XNU Kernel Deep Dive
#170Earlier quoted context omitted.
>xnu could alert it when it was low on swap; dynamic_pager would create swap files, and pass them back into the kernel What's the benefit of this indirection through userspace for swap file creation? Can't the kernel create the swap file itself?
Today the kernel does create the swap file itself. I don't know why it behaved differently in the past, given that the version of dynamic_pager I linked is only 355 lines of code, not obviously complex enough to be worth offloading to userspace. But this was written back in 1999 and maybe there was more enthusiasm for being microkernel-y (even if they had already backed away from full Mach paging).