I confirms my thoughts Linux looks more like MS-Windows and *BSD* is getting even more better than ever.

The title is funny: "Do You Hear That Linux, Windows?"

The longest compile I have is 25 minutes and that's Qt-5.9.0, well GCC & Clang may take a little longer, but that's due to the unit testing. But, I can build the LFS base console system in about 12 hours and that's with several long breaks while tests run. Once the base is done, I really only test libs and most of them are built, tested and installed in 2 minutes or less. Even boost takes little more than 6 minutes, and that's with testing.

The advantage of compiling yourself is that your entire system is optimized, including the toolchain itself. When I build from a some sloppily optimized distro, what is immediately noticeable is the time difference between building the two initial passes on GCC. Pass one is to break dependencies from the host toolchain, pass two is built with the compiler from pass one. Pass two is a totally independent cross compiler from the host, used in chroot. To sum that all up, the host's GCC builds pass1 compiler, pass1 gcc builds pass2 gcc. Pass2 usually takes half as long as pass 1, which says a lot about the distro compilers. Finally, my flags are not aggressive, I've seen maybe one or two optimization related bugs in the last decade. Yet, the performance increase is significant, just on these:

So no, I don't use -Ofast, -O3, -funroll_loops or -fomit_frame_pointer. In my experience, those lead to bugs too frequently. I do remove -g and/or -ggdb when I see them though.

That's a silly basis for your "confirmation". Linux can actually load a kernel to replace itself without rebooting, BSD and Windows still have to reboot. Guess that means BSD and Windows are getting closer together then. Half-Life 3 confirmed!

Looking at the present poll. Visibly abut 60-70% aren't in favor of SystemD.

It looks amazing, right?, that most distros will bring it for user happiness ;)

More reading: http://suckless.org/sucks/systemd

I've already read that Xeratul, and yes, I agree Systemd has issues. It needs focus a well defined scope and the main developers need to learn the meaning of the phrase "feature complete." Right now, it's going on like a carpenter's house and that can't lead anywhere good in the long term.

All that said, Systemd has done some good things too. To my knowledge it is the only init system in the Unix world that consistently and reliably executes the startup process in parallel. It has also removed the need for boilerplate startup scripts. They can still be used, but only need to be, where it's really necessary. Now, the startup process mostly involves directories and small config files.

Is that a bad thing? Well, considering that one oft touted Unix philosophies is that everything, from devices, to process lists should be represented by files and folders. Systemd has moved startup configuration from scripts, to a files and folders structure. And then it's detractors come along and call it a "registry". The Windows registry does not store configuration data in the form of files and folders, it uses a database.

Well, unless I can change my mouse configuration on a Windows machine by doing this:

And that changes the config without using a text editor, nor does it erase the default configuration. This does not seem like a bad way to go about things.

Was it necessary? Find an old Unix disk and look at the sizes of programs like grep, awk and cat and compare them to what's on your system today. If you've never looked before, you're in for quite a shock. Reducing the use of those programs during the boot process leads to faster boot times and less battery usage. As to why they're so much larger today, search for "Linux binary size" and youtube. I watched a video there a couple of years ago of a presentation explaining why those programs have exploded in size. The presenter goes into great detail about why, but most of it is related to security.