NeXTBSD aka FreeBSD X(slideshare.net)
slideshare.net
NeXTBSD aka FreeBSD X
http://www.slideshare.net/iXsystems/nextbsd-aka-freebsd-x
71 comments
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.
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?
Adopting Mach fresh in 2015 is certainly anachronistic.
It would be, except they're not adopting Mach.
How are you interpreting slides 5-7 then?
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.
Yep, it isn't that different than the linux sys call interface for running linux binaries.
> 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.
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.
> And this is why I won't use any of the "FreeBSD made easy!" distros: FreeNAS, PC-BSD, pfSense, etc.
one of the main people behind pfSense here...
You're not the target audience.
one of the main people behind pfSense here...
You're not the target audience.
I guess that is why many use their modern GNU/Linux, *BSD boxes as if they had a UNIX SYSTEM V with a VT 100 in the basement.
> 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?
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.
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'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).
> Ahhh. I miss solaris.
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.
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.
Try OmniOS for a great Solarish server OS.
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.
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.
FreeBSD + Mach kernel, libdispatch, and launchd? How does this differ from Darwin?
I may be misunderstanding, but as far as I know it simply layers Mach kernel services onto the FreeBSD kernel rather than actually using Mach.
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.
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.
There's no parallel Mach kernel running. It's just Mach IPC shimmed as an FD type.
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.
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.
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.
That's my understanding from the presentation!
That's my understanding from the presentation!
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.
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.
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.
At least for the graphics, performance was an important factor.
API compatibility can be reached through other means than moving stuff into the kernel.
API compatibility can be reached through other means than moving stuff into the kernel.
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!
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!
Apple publish and give back heaps to the open source community.
http://opensource.apple.com/release/os-x-10103/
.. they're just not fanboys about it.
http://opensource.apple.com/release/os-x-10103/
.. they're just not fanboys about it.
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.
Read the list again. Most of Apple's major packages are there.
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 (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.
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".
* 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".
I don't think all of them have a license that requires publishing the source code of derived work.
.. have you seen http://opensource.apple.com/source/xnu/xnu-2782.20.48/ ?
Jordan Hubbard mentions some of his reasoning behind going back to what he did at Apple (among other things) in this thread: https://lists.freebsd.org/pipermail/freebsd-hackers/2015-Aug...
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.
See later in the thread:
https://lists.freebsd.org/pipermail/freebsd-hackers/2015-Aug...
https://lists.freebsd.org/pipermail/freebsd-hackers/2015-Aug...
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.
I wonder if you could glue microsoft's ios emulation layer on top of this and get the basis of an open source ios/os x?
No because microsoft's implementation calls to win32 and XAML for everything.
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...
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...
But if you throw in wine... I say this in jest, but it does make me wonder.
First Wine needs to understand WinRT application model.
I would bet the ios emulation layer isn't going to be much use off windows.
In any case, there's already gnustep to get you pretty damn close.
In any case, there's already gnustep to get you pretty damn close.
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.
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).
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.
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.
where / when was this presented?
Bay Area FreeBSD User Group (BAFUG) August 2015 meeting. There's a video recording available at http://www.nextbsd.org/jordan-hubbard-visits-bafug/
just found it, thank you.
Dumb question: Could this give me a NeXT desktop in VMware? And could it run old NeXTstep software?
You can already have that by installing a Gnustep based disto like Etoile.
http://etoileos.com/etoile/
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.
http://etoileos.com/etoile/
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.
Thank you!
Freebsd X will have ioKit drivers? (source compatibility)
Is this similar to systemd?
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.
1 - https://en.wikipedia.org/wiki/Xinetd
2 - http://launchd.info/
1 - https://en.wikipedia.org/wiki/Xinetd
2 - http://launchd.info/
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.)
(Just to be clear, I never liked the Unix philosophy so I enjoy seeing experiments in postunixism.)
Only part that may be relevant to compare is launchd, and even that stops at systemd-pid1, not the wider systemd project.
"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.
Yeah -- Unix completely dominated essentially every market niche, utterly annihilating all competing philosophies so hard you'd think it was drilling for oil.
Windows says hi.
Every phone, tv, appliance and internet device says hi back. Also, bye.