121–130 of 186 posts
Whenever I see the Darwin kernel brought into the discussion I can't help but wonder how different things could have been if Apple had just forked Linux and ran their OS services on top of that. Especially when I think about how committed they are to Darwin it really paints a poor image in my mind. The loss that open source suffers from that, and the time and money Apple has to dedicate to this with a disproportionat…
Earlier quoted context omitted.
This presumes that Apple brought in Jobs as a decision maker, and NeXTSTEP was attached baggage. At the time, the reverse was true - Apple purchased NeXTSTEP as their future OS, and Jobs came along for the ride. Given the disaster that was Apple's OS initiatives in the 90s, I doubt the Apple board would have bought into a Linux adventure.
Why wouldn't Apple have been interested in a Linux option? They bought NeXTSTEP because of Jobs. Linux was already useable as a desktop OS in 2000, and they could have added in the UX stuff and drivers for their particular macs on top of it. There wouldn't have been any downsides for them, and it would have strengthened something that was hurting their biggest rival.
If by biggest rival you mean Microsoft, it was Microsoft who saved Apple from bancrupcy in 1997.
What impresses me most about technical documentation like this is how it structures knowledge into comprehensible layers. This article manages to explain an extremely complex system by establishing clear relationships between components. I've been experimenting with similar approaches for documentation in open source projects, using knowledge graphs to link concepts and architectural decisions. The biggest challenge…
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 pages are a good reference if you already have familiarity with the employed concepts, so it's good to have an intro/overview document that walks you through those basics. This core design rarely sees radical changes, it tends to evolve - so adapt the overview as you make strategic decisions. The best benchmark is always a new hire. Find out what is it that they didn't understand, and task them with improving the document.
Earlier quoted context omitted.
I've also wanted to understand Windows NT at this depth for a while. Skip the Win32 stuff, and discuss what's underneath it. As I understand Win32 is just one personality; there was also Windows Services for UNIX in the Windows XP days and Subsystem for UNIX-based Applications in Windows Vista. The underlying NT kernel is flexible enough to allow POSIX compliance. That would be an interesting read.
Windows Internals is the book you want. Or Inside Windows NT, if you want "version 1" of the Internals series. Or read the Windows NT OS/2 Design Workbook - https://computernewb.com/~lily/files/Documents/NTDesignWorkb... . Yes, Win32 is just one personality, but a required one. OpenNT, Interix, SFU, SUA will ride alongside Win32. And of course there was the official OS/2 personality.
Does this give us any indication on when Apple will be ditching x86 support?
I have a hunch we'll get one more MacOS version with Intel support since they were still making Mac Minis and Pros with Intel chips in the first half of 2023.
Earlier quoted context omitted.
This presumes that Apple brought in Jobs as a decision maker, and NeXTSTEP was attached baggage. At the time, the reverse was true - Apple purchased NeXTSTEP as their future OS, and Jobs came along for the ride. Given the disaster that was Apple's OS initiatives in the 90s, I doubt the Apple board would have bought into a Linux adventure.
Why wouldn't Apple have been interested in a Linux option? They bought NeXTSTEP because of Jobs. Linux was already useable as a desktop OS in 2000, and they could have added in the UX stuff and drivers for their particular macs on top of it. There wouldn't have been any downsides for them, and it would have strengthened something that was hurting their biggest rival.
>There wouldn't have been any downsides for them
Really? NO downsides???
- throwing away a decade and a half of work and engineering experience (Avie Tevanian helped write Mach, this is like having Linus being your chief of software development and saying "just switch to Hurd!")
- uncertain licensing (Apple still ships ancient bash 3.2 because of GPL)
- increased development time to a shipping, modern OS (it already took them 5 years to ship 10.0, and it was rough)
That's just off the top of my head. I believe you think there wouldn't have been any downsides because you didn't stop to think of any, or are ideaologically disposed to present the Linux kernel in 1996 as being better or safer than XNU.
Earlier quoted context omitted.
"At the same time, NT (up to and including Windows 2000) shipped with an OS/2 subsystem which ran character-mode 16-bit OS/2 applications." From OS/2 museum.
Turns out this is not true. Confirmed that os/2 2.0 was a skinning and compatibility layer for NT it came out for OS/2, not with windows and not from Microsoft. It came with OS/2 and from IBM. No idea whether it supported HPFS+ but it was not a subsystem.
No, what you quoted in your comment you are replying to is accurate. What you are saying in this comment isn’t.
> Confirmed that os/2 2.0 was a skinning and compatibility layer for NT it came out for OS/2,
This is confused. OS/2 was not a “skinning and compatibility layer for NT” it was a completely separate operating system.
I think at one point NT was going to be OS/2 2.0, and then it was going to be OS/2 3.0 - but the OS/2 2.0 which eventually ended up shipping had nothing to do with NT, it was IBM’s independent work, in which Microsoft was uninvolved (except maybe in its early stages).
That makes me wonder: how hard would it be to run the XNU kernel in something like a “Mach mode”, where you take the same kernel and drivers but run them separately as the Mach microkernel was intended?
I feel like from a security standpoint, a lot of situations would gladly call for giving up a little bit of performance for the process isolation security benefits that come from running a microkernel.
Is anybody here familiar enough with XNU to opine on this?
It seems like the XNU kernel is architecturally super close to the Mach kernel, and XNU drivers architecturally work like Mach drivers, but just that they are compiled into the kernel instead of running in userspace as a separate process. And it seems like the only reason for doing so is performance. That makes me wonder: how hard would it be to run the XNU kernel in something like a “Mach mode”, where you take the s…