The "code was touched" in order to bring some new features in. Here is the commit for that branch to /dev/random r 273872

This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random.

This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources.

The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people.

The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway.

Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to.

My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise.

My Nomex pants are on. Let the feedback commence!

You can see the list of those who reviewed and commited the code in the link. They are all longtime contributors.

The problem was:

When the new random adaptor code was brought it in r273872, a call to
randomdev_init_reader to change read_random over to the newly installed
adaptor was missed. This means both read_random and arc4random (seeded
from read_random) were not returning very random data. This also
effects userland arc4random as it is seeded from kernel arc4random.

So there was a problem was that the new adaptor was not 'retro-fitted' to the existing code. A simple thing to miss - I've done this many times in refactoring code. The generated was getting new seeds from the old function and not the new one.

Yes, he joined them in 2013. He is their CTO I believe now. But PC-BSD is quite a bit older than that.

(By the way, why all the bash love? Only an idiot would write init scripts in bash. Anyone worried about security would use a POSIX shell like dash).

I think on that we can agree 100%. POSIX for the win.

I simply gave the link to show that Android does not use systemd, and actually has a "mess of scripts" in order to do its business.

You can see who works on PC-BSD by checking out the commit history on the official github repo Kris Moore is one of the main contributors and is a really nice guy. He works for iXsystems.

FreeNAS is a different beastie. Here is the github. As you can see there is actually very little overlap, but a lot of cross pollination between the various BSDs.

YES

THERE

ARE

I am by no means an expert in those databases, but I am fairly certain they can be run with very little difficulties on FreeBSD.

Here is an install of Oracle in a Debian jail on FreeBSD. I do not know if Oracle would support such an installation however.

The DB/2 client certainly works.

Sybase ASE for FreeBSD is available on this download page.

Whether it would be advantageous to you or not is a different question.

The answer is yes.

Actually the fellows who work on PC-BSD, or most of them, work for a company called iX Systems that provides servers and storage.

Well, if you really want to "get some work done" you could always run Windows or the operating system that came installed on your computer. And I might ask - what work are you doing that doesn't need to adjust some settings on your computer?

Sorry that link was eaten by slashdot. Here is a shortened one: http://goo.gl/VsOSS7

The first thing you need to insure is that there is a MBR compatibility mode for your motherboard, which for your machine should be IPISB-CU (Carmel2), so this is possible. Once you have that, you can probably figure the rest out in the wiki, or better to ask in the forums. I could give you some help but maybe slashdot is not the place for that. I hang out often in #freebsd so you might catch me there, and in general there are many helpful people there.

You will notice that I put the links for FreeBSD for the PC-BSD. The only real difference between the two is the software repositories. In fact you can easily convert a standard FreeBSD to PC-BSD simply by changing a few configs. You might try that route if you want a quick desktop install. I prefer to 'roll my own' but the PC-BSD guys have really done a lot of good work putting in good defaults.

Systemd doesn't even have a stable feature set yet, and yet you say the world has moved on? Maybe you are on a different world?

It also has a bug list that is huge, and the number of critical bugs embarrassing.

So I'm not sure POSIX should exist and if does exist then I think Linux and OSX should be at the center of it with AIX, Solaris, other BSD... being peripheral. Things like support for Digital Unix and Xenix features can be dropped.

These kinds of statements are completely idiotic, and I dare say typical of the systemd fanclub.

Please read on what POSIX is first. It is what guarantees that your software will be portable, which is a foundation upon which UNIX is built. In fact it is the portability of software that made UNIX possible and popular to begin with. It is the equivalent of the w3 standards committee for web design.

You hate it when your web browser doesn't adhere to standards. Why should your software not adhere to standards? How do you think you can actually USE open source software on different operating systems? Making any key component of your operating system, especially something fundamental as an init system, against POSIX is completely insane. It will be the death of linux. It is equivalent to saying that your website 'works best with IE6' in the application realm. THIS IS A BAD THING, independently of the technical merits of systemd.

For instance, to compile gnome now on OpenBSD you need to add an emulation layer for the systemd parts because systemd CANNOT BE PORTED to BSD. So now in order to compile any gnome application onto OpenBSD you need a whole emulation layer just because they broke POSIX by having systemd as a dependence.

What you see in the browser area, where each webpage now needs to load a special javascript file in order to insure compatibility to all browsers, which is a nightmare for developers, is now being forced upon Linux.

The thing is these problems were solved so many years ago, and now thanks to Red Hat and their incompetent engineers everything is going to be broke and incompatible. It is basically Red Hat making Linux theirs - not by stealing the code, but by making it useless to others.

That is complete bullshit. Have you even looked at the source code of launchd and systemd?

Launchd actually is POSIX compatible which is why it has already been ported to FreeBSD. Systemd does not even consider POSIX compatability something to be desired.

If anything, porting GNOME will be a royal pain in the ass now. In fact many opensource projects like OpenBSD are writing shim layers to insure "systemd comptability" in order to facility cross compilation of Gnome Desktop.

When open source projects have to provide an emulation layer for an init system in order to port open source software there is something terribly wrong.

just 300k lines of code.

Actually, that is wrong. Systemd is well over 550k lines of code, and close to 1500 files.

There are operating systems with lower counts of lines of code. Even the entire Space Shuttle was run on less than that, and Minix is 3 orders of magnitude smaller for the entire operating system. Here is a nice graphic

The other init systems are much more modest. Even upstart is only around 40k lines of code. The source code of launchd for instance is very compact.

Furthermore, systemd is not only huge, it is entirely unportable. All the other init systems have been ported to other unix systems because they actually preserve POSIX. Even Apple, who has a tendancy to do proprietary things, has made their launchd portable to other systems. Systemd doesn't even care about POSIX compatibility in the slightest, and even detests this standard.

All those complaints about Windows being bloated are actually nothing compared to Red Hat Linux now, which has more code in its INIT system than the original WIndows 3.1 release.

In short it is a bloated project that will probably die under its own weight.