Not sure if I should be happy
One the one hand, if I'm forced to use Azure, I'll know what to roll out for network facing servers.
On the other, I'm not sure if I like the idea of Microshaft screwing with an otherwise excellent Operating System.
Microsoft has created its own cut of FreeBSD 10.3 in order to make the OS available and supported in Azure. Jason Anderson, principal PM manager at Microsoft's Open Source Technology Center says Redmond “took on the work of building, testing, releasing and maintaining the image” so it could “ensure our customers have an …
@DougS - While Apple OSX and iOS use some parts of FreeBSD, the kernel they use is from Mach, not FreeBSD. It's quite likely that none of what Microsoft has done with FreeBSD (probably mainly just special drivers for running on Hyper-V) will have any relevance to Apple's OS or even be compatible with it.
there is more to the Mac OSX kernel (XNU) than Mach, there is BSD code in there too for POSIX API, security including id and permissions, some of the BSD locking primitives, the virtual file system layer, crypto framework, the bsd flavor of System V IPC, and mandatory access control for kernel objects
"I'm fairly sure we can rely on the FreeBSD community to vet MS's contributions. And it sounds like MS are playing nicely anyway (for now at any rate). Amazing!"
I think this is yet another example of Satya Nadella's pragmatism and his acceptance (at last) that outside of the desktop environment, it is a multi-polar operating system world out there and that Microsoft has to adapt to that situation in order to survive as a corporate entity.
Interestingly, and I'm willing to be corrected on this one, this appears to be the first time that Microsoft has ever given back anything significant and meaningful to the open source operating system community - more of the same, please, Microsoft.
This post has been deleted by its author
FreeBSD is currently still seen as a saner alternative to "modern" GNU/Linux where you don't have that FreeDesktop/systemd stuff. A system that potentially just works.
I think the arguments at MS HQ lie more in the direction of not being under GPL and possibly start to acquire enough knowledge to yet again try to copy Apple. Let's not forget, they're rubbish at innovating, but .. no, wait. They're rubbish at copying too. Never mind.
start to acquire enough knowledge to yet again try to copy Apple
They already have it and they have done it in the past. If you plot Windows development build TCP stack fingerprints going as far back as Windows 2000 they go through a "this looks exactly like BSD" moment every few years early in their release cycle. This is also the moment when the stack actually starts working too (this was the case with Win2K).
So what you are suggesting is nothing new, it is however mostly at low levels.
Actually I think a BSD-derived TCP/IP stack first appeared in NT 3.5.
Correct. Then it slowly MSFT-bit-rotted to be refreshed again in the early Win2K development cycle. And a again a few times later. TCP fingerprinting knows no mercy - it shows exactly what you are doing and whose stack did you cut-n-paste when yours was not delivering.
In the case of BSD it is permitted by license and Windows has always complied with it - if you dig around you can find the relevant "copyrights" and mentioning of BSD in their licensing info.
Microsoft Xenix had BSD compounds 30 years ago. For the first 10 years, that Microsoft was doing Hotmail it ran on Freebsd. Microsoft.net was the Built on freebsd and distributed in the Rotar shared source version.
Suggesting it's about E.E.E, is lazy nonsense.
"Suggesting it's about E.E.E, is lazy nonsense."
Agreed. It's not as if the FreeBSD team are going to accept kernel code that's licence encumbered. If MS tried that, FreeBSD would just wish them luck with their project and leave them to get on with it by themselves. Anyone is free to fork FreeBSD. You just need to acknowledge any licence holders where relevant. There's no constraints on "giving back" or enforced source code distribution as demonstrated many years ago when MS took the BSD TCP stack and built it into Windows.
This post has been deleted by its author
This post has been deleted by its author
You could try Devuan. http://devuan.org/ They made a point of never supporting systemd.
I switched to them when a Debian upgrade on my laptop installed systemd and promptly broke the system (systemd would hang indefinitely at boot) forcing a reinstall.
Reading about systemd and its design philosophy had already put me off, as it reminded me too much of the mistakes Windows did. Sure it makes it easy for clueless "admins" to manage a machine, but kills the power and flexibility of Unix, and you can't delve down easily when debugging a misbehaving machine (the systemd shell is not a real alternative). All reasons why I left Windows for Linux/Unix in the first place.
I started the transition with my test VMs, with no problems at all. Now am transitioning my physical Debian machines across to it as upgrade time rolls round. Then I will move over my web/email hosting servers and that will be it.
I moved my server over to FreeBSD though, ZFS is awesome!
Between those two operating systems, I will never have to touch systemd, so RedHat and their cheerleaders/minions can have Pottering's latest turd for all I care.
You could try Devuan. http://devuan.org/ They made a point of never supporting systemd.
Agreed. I have a VB set up at the moment running Devuan. It seems fine compared with my last openSUSE install pre-systemd (11.4) and all the hype about systemd's abilities to open faster and perform better seems to be belied by Devuan.
Of course, as I found out on Twitter recently, there are any number of users out there that refuse to accept that just because RedHat have successfully rammed it down the throats of the more mainstream distros and its users, and they are happily dealing with its complexities and breakages, it doesn't necessarily mean that it is right.
Ah well.
It's probably mainly just para-virtualization drivers to cut down the virtualization overhead when running on that VM. That's what they did when they added Hyper-V support to Linux. They're just drivers which know they're talking to a VM instead of directly on actual hardware. If you're not running on MS Hyper-V, then you're not using their drivers.