Nor is it research. It very much appears to be commercial, since it's undertaken by iXsystems. They're integrating it into FreeNAS and I think PC-BSD will follow suit. End goal appears to be get upstream FreeBSD in it, too.
There's nothing of research value here. It's Mach. It's practically an anachronism to do such a thing deliberately.
I actually have quite a lot to say on this topic, so I think I'll write an in-depth blog post on it.
And this is why I won't use any of the "FreeBSD made easy!" distros: FreeNAS, PC-BSD, pfSense, etc. Better to learn how to configure the official release to your intended use case.
> CTO is Jordan Hubbard
I swear, every last OS always has to have one of those "let's replace all this stuff that's worked for 40 years and go with all this brand-new, much more complicated stuff because old = bad, new = good!" types.
People just don't like the idea of incremental improvements, nor find beauty in simplicity anymore.
one of the main people behind pfSense here...
You're not the target audience.
Are they planning to rebase FreeNAS on this? Why not just stay on a normal FreeBSD base? Or will there not be much noticeable difference feature wise from the user's perspective?
I can appreciate the idea of integrating launchd as a new init system and I know people have been working on that for a while, but this seems like it's much more than just that to me. Or am I misunderstanding?
I'm not sure if they're going to wholly rebase FreeNAS on top of NextBSD, but the launchd integration has been there in feature branches for a while now.
I'd be completely onboard with SMF replacing the init system on all my fbsd boxes though (I have many on bare metal with linux under bhyve for various things that need it).
I don't think that's an easy port though with the contract system etc solaris had for process accounting.
Ahhh. I miss solaris. FreeBSD is almost where we were feature wise before oracle killed it (zfs, dtrace, jails(iocage) etc).
The illumos, SmartOS, and Joyent folks are doing a fantastic job moving Solaris forward. That's where all the action is these days.
FreeBSD is doing great stuff too, with their more conservative approach, and drastically fewer resources.
With FreeBSD, the userland is pretty capable (I run all my DBs, some node apps, reverse proxies etc under it) so jails kinda made sense again. With SmartOS I had to run most of my stuff under KVM, so what was the point?
Interesting to see what direction the linux abi stuff joyent are working on goes though.
That said, I feel rather uneasy about the base FreeBSD going such a verbatim OS X route. I can understand doing it for FreeNAS, PC-BSD and derivatives, but it's quite invasive for upstream. Especially considering this requires running a parallel Mach kernel in the same address space.
Also, using Mach IPC deliberately in 2015 is like shooting yourself in the foot in my mind, but it's probably better than kdbus.
Mach was mostly VM and IPC - so of course it looks like it's a lot of Mach code. But there's no separate mach kernel running - it's just the IPC instances and they only exist as FD bits. It's not a complete kernel and FreeBSD isn't running "on" mach.
They also ported tasks (as processes), threads (kthreads) and some clock/timer stuff, as well. No memory objects because there's no external pager they can be backed from.
That's my understanding from the presentation!
In case you are wondering: I don't think that Microsoft Windows uses a microkernel.
Some versions of Mach are micro, other versions are not. OS X doesn't use a microkernel, neither does Darwin. They use XNU kernel. XNU has code from Mach and it also uses code from FreeBSD.
People call it a 'hybrid kernel', but I think that is a misnomer and only really exists through the effectiveness of Apple's marketing. XNU is a monolithic kernel with message passing capabilities inspired from microkernels. Makes it so they can isolate certain features and drivers better then, say, Linux can.
Unlike Apple, Microsoft actually did release a version of NT that was a true microkernel, but they quickly realized that it is not a practical approach to creating a OS that was competitive with Unix.
This seems pretty much Darwin grafted with FreeBSD.
For a commercial network appliance device it's probably a good approach. They get all the benefits from using source code from Apple, FreeBSD, and ZFS without having to actually provide much source code in the way of real improvements that could be used to enhance a competitor's product.
You mean Windows NT 3.1 and 3.5, right? I used those intensively, and it worked really well.
> but they quickly realized that it is not a practical approach..
With Windows NT 4.0 they left the original design and moved everything including the graphics into the kernel. But that was not because the original approach was not practical or did not work. It was because Windows 95. The wanted Win32 to be API compatible with that crap (desktop 'gadgets' and such) and that's why they did it. I remember hating NT 4.0 because it was so much less stable than the original versions.
API compatibility can be reached through other means than moving stuff into the kernel.
I'm horribly disappointed in the way that Apple seems to give back barely anything to the community. Google and Facebook's github is populated with dozens of projects. Granted, some are in a state of disrepair, others are incredibly useful. E.g., the state of open source static analysis is on par with Coverity at this point for our 300k line C++ project. I'm a bit of a tinfoil privacy nut, but thanks Google and Facebook, you guys rule!
.. they're just not fanboys about it.
xnu (the kernel), Libsystem (C/C++ core libs), CommonCrypto/Security, CF (CoreFoundation), IOKit et al, hfs, Apple SMB and more.
It doesn't include a number of other Apple projects that are hosted elsewhere like launchd, libdispatch, clang/llvm.
* XNU is based on existing open source software. You're right that Apple had no obligation to release the source of XNU given the permissive licences of the parent code. But equally it feels a little disingenuous to congratulate a company for releasing their code to a project that was open source to begin with anyway.
* Apple SMB referenced from Samba code and only created because Samba changed licence to GPLv3.
* Clang/LLVM isn't an Apple owned project. Though I will granted you that they are major contributors to it.
I cannot blame Apple for wanting to keep their proprietary inventions closed. They are a business after all so I'd expect them to put their business interests ahead of "good will".
Also, would you trust an implementation that thinks this is an OK implementation of arc4random()? (even if it was fixed later?) - https://github.com/Microsoft/WinObjC/blob/59a63e42a9d10da8aa...
In any case, there's already gnustep to get you pretty damn close.
Not sure if useful, but would be cool (in a weird, nerdy way) anyway.
In fact, if you look at Mach support code on glibc's code, you'll see build time conditionals for supporting non-GNU Mach versions.
The bootstrap server is not a problem either, but the lack of memory object would indeed break all libpager based translators, among other stuff.
As a PoC, I wrote a filesystem translator (https://github.com/slp/anonfs) which doesn't rely on memory objects, implementing conventional read/write semantics (no mmap() support, though).
Porting the NextBSD work to the Linux kernel API is certainly something on my list in case rump integration for Hurd doesn't pan out, in any event.
Or apt-get'ing Gnustep on any modern Linux. Any OpenStep compatible app should compile and run. Modern Cocoa apps won't necessarily work because Gnustep doesn't support all the new stuff that Apple developed over the years, but the basics are all there.
1 - https://en.wikipedia.org/wiki/Xinetd
2 - http://launchd.info/
(Just to be clear, I never liked the Unix philosophy so I enjoy seeing experiments in postunixism.)
Yeah -- Unix completely dominated essentially every market niche, utterly annihilating all competing philosophies so hard you'd think it was drilling for oil.