Any idea what the purpose is to this? I'm not putting it down, I'm just looking for context. The annotations say this work is being done at iXsystems, best known for being the stewards of FreeNAS, but this project seems to be separate.
This has a feeling very much of a research project to see how well an init framework like launchd would work in FreeBSD. There's been talk amongst a lot of developers that the current init needs to be replaced by /something/, but that something is still up in the air.
It's not just launchd, it's the entire low-level OS X userspace.
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.
Not necessarily anachronstic, considering the iXsysems CTO is Jordan Hubbard, who was previously at Apple as director of UNIX technology. Out with the old in with the less old?
They're providing enough of a Mach-style interface that would allow them to use launchd. Basically, they're creating a compatibility layer in the kernel that allows it to pretend to be Mach.
> They're integrating it into FreeNAS and I think PC-BSD will follow suit.
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.
> They're integrating it into FreeNAS and I think PC-BSD will follow suit
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?
It's more than that, yes. It's the entire low-level OS X system libraries like libSystem, libasl, libdispatch, libnotify and so forth.
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.
Disappointing really, but I think it's unlikely to make it upstream. Perhaps I've missed some of the advantages to taking this approach though.. Or .. any of them?
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).
I used SXCE, OpenSolaris and finally SmartOS for a while after the death, and unfortunately the benefits just werent' really there any more. I also hit some pretty nasty performance issues storage wise on my OVH gear (some interrupt related issue, unsure if fixed, but it was well above my head to grok, and I' not terribly new to this) which were instantly solved by converting to BSD.
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.
Correct. There's an OSF Mach shim running as a FreeBSD kernel module which is then used to drive XPC and everything above.
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.
It's a kernel module implementation of much of OSF Mach verbatim copied and shimmed from MkLinux, not just IPC. See sys/compat/mach in the NextBSD source tree.
Yeah I looked; it's the IPC from Mach with some shimmed bits to do VM-y things for mapped message passing.
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.
I never made such a claim that FreeBSD is running on Mach. I said it integrated a Mach kernel interface as a module running in kernel space.
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.
The base FreeBSD isn't going this route, this is something that is being worked on at iXsystems that may or may not eventually find it's way to FreeBSD itself.
It's just a FreeBSD kernel. Kip's implemented Mach facilities on FreeBSD, but it's not remotely like Darwin. Darwin is a Mach (micro-)kernel that implements BSD APIs on top of Mach.
If Darwin uses a Microkernel then so does Microsoft Windows. They are very similar designs.
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.
Regardless...
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.
> Microsoft actually did release a version of NT that was a true microkernel,
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.
I wish they would outline their plans to integrate these technologies with FreeBSD. It is time for Apple (by way of their innovations) to feed the base which they used to build Mac OS X. How willing is the FreeBSD upstream to integrate these?
Very. The core committers have a direction in which they'll take FreeBSD, but compared to say OpenBSD, it's a very open community. Colin who posts here frequently is pretty influential in the community as I recall.
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!
That appears to be open source software that Apple is using (and is required to publish the source for, under that software's license) -- not software Apple has written and is releasing.
You're right that Apple gets a lot of criticism for not supporting open source yet host a lot of open source projects. But I think a lot of the criticism comes about because Apple's commitment to open source often comes with caveats. To use a few examples from your list:
* 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".
That message was posted by Bill Sorenson, so not sure if it's the message you were intending to link to. However it's still a good read even if it wasn't the intended mail.
As a FreeBSD user, developer, and fan, I'm excited that they are digging into some of this stuff. My amateur question is just wonder if adding a ton of new KPIs is really necessary, or could be done in a more holistic thinking way.
GNUStep is a cool idea (I’d love love love to be able to develop cross-platform desktop apps with Cocoa), but its problem is that it’s lagging so far behind that it’s practically unusable. If you’re targeting Apple Cocoa/OS X too (why wouldn’t you be) you’re going to be restricted to AppKit as it was back in OS X 10.5 or 10.6, and that sucks. Unfortunately, unless the project has a sudden windfall of cash and/or developers, I doubt this will change any time soon.
A curious (and probably unintended) side effect, is that if its implementation of the Mach API is complete enough, this should allow to run Hurd user space server/translators on FreeBSD.
Not sure if useful, but would be cool (in a weird, nerdy way) anyway.
It isn't. For one thing, it's a port of an old OSF Mach kernel. Hurd uses GNU Mach, which is descended from CMU Mach 3.0. They don't support memory objects, their threading is bare bones, they assume a bootstrap server and there would be no way to actually get glibc and Hurd RPC working.
The OSF vs GNU Mach thing is not a problem. It was years ago, but I managed to run a Hurd translator statically linked against a slightly modified glibc on OSF Mach (the one bundled with MkLinux, you can see its code on my repo https://github.com/slp/mkunity).
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).
The option of using MkLinux as a host has been raised as a hypothetical since many years ago, but was never tried. I don't have spare PPC hardware in mind, but that's interesting to hear it works.
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.
Not an expert in either so I may be mistaken, but to the best of my knowledge launchd doesn’t have anywhere near the scope of responsibilities or functionality that systemd is capable of/given. It definitely encompasses more than a bare bones init system, but it’s not quite the beast that systemd is.
If by "similar to systemd" you are referencing launchd, not really. The intent of launchd is more along the lines of xinetd[1] than systemd. Here[2] is more info on what launchd is intended to address.
It's similar in the sense of throwing out the Unix philosophy and replacing it with a different one while keeping 99% of the code. It's not obvious why NeXTBSD would be better than Lennartux though.
(Just to be clear, I never liked the Unix philosophy so I enjoy seeing experiments in postunixism.)
"launchd clubs UNIX's 'keep it simple' philosophy like a baby harp seal'...Hint: the world has changed!"
Yeah -- Unix completely dominated essentially every market niche, utterly annihilating all competing philosophies so hard you'd think it was drilling for oil.