Or switch to a pass phrase, which can be of any length.
The pass code is limited to four numbers, but you can switch it to a longer pass phrase which may include any number of alphanumerical characters.
I know some people who actually used to call it GNU/OpenSolaris. In the end I think it's up to each community respectively to decide what to call it.
Mac OS X is moving away from the GNU userland, using either outdated versions or switching to equivalent BSD tools.
That's why you can continue to use syslog if that's what you want.
Some of us like the new features.
I'm not talking about the kernel, I'm talking about the operating system often referred to as GNU/Linux. Systemd has nothing to do with the kernel, except that it uses its functionality.
You don't have to. If you really want your old way then just have journald pass everything along to syslog and it's back to normal.
That's not the complaint. The complaint is that the process at PID 1 should be simple. You people running around screaming about a bunch of different processes are only compounding the proof that you do not understand Unix. It's not a problem to have many processes.
We all stopped using UNIX long ago, it's GNU/Linux now and it's only somewhat inspired by UNIX. What the UNIX people did 30 years ago is interesting from a historical perspective, but is not in any way the only right way to do things. I say did because that's now even how modern unices work. Solaris has for example been running on SMF since 2005 and they are doing just fine.
Are you suggesting that Systemd is prone to crash?
Not really. His argument lost some credibility when he compared a system level utility to a graphical application.
What's the difference? Both are complex systems.
I use both, actually I use a couple of others as well. I often find interesting edge cases and bugs just by running my code through as many compilers as possible.
I don't see anything about demand there.
Unfortunately Systemd is not available on Minix so that's a downgrade.
They stopped using gcc for various reasons, the project was stagnant, ridden by core developers that could not agree on a road map, it forked a few times I believe and it was always not only buggy but years behind modern C++ standards. Not to mention gcc is slow and the code it produces was not really fast or small in the recent years.
No idea how it is faring right now.
You should really take a look at gcc 4.9 because your viewpoint is seriously out of date.