You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

]I've tried really hard to tell you why everthing that you said since the begginning of this thread is FALSE and TOTALLY WRONG with actual proof that support my statement.

I've read this entire thread, and you got some things wrong about how systemd works. Sorry. You do not have convincing proof.

Quote:

Originally Posted by Martinus2u

Then do it and start contributing. So far all you have done is defaming a developer as drug dealer and calling for grievous bodily harm against him using a baseball bat.

What makes you think he is not doing something? That he has not done research? Why does he need to be a contributor, if something he has already works?

I've been at the point of doing something some time. I've studied systemd code. I've tried coding to test the userspace concepts. This, and other discussions don't interest me because they don't go anywhere. I'm interested in preventing the userspace from turning to crap. So I will be willing to engage people technically to solve problems. Reaper has provided some good information that I didn't know about. That shows he really is doing homework on this.

Why do you want to defend Poettering? He defamed BSD for no good reason when questioned why he doesn't support it. His attitude is childish, but we are supposed to just give in to him; we have no choice and can't do anything? You severely underestimate what a maintainer with a bad attitude can cause people to do. I never have used BSD, but Poettering showed himself very poorly to the whole community. The BSD people don't deserve that. Reaper may be mad too, but please don't provoke him by saying "you aren't doing anything". You do not know that.

On one hand, almost every major distribution is switching to it, udev will be inextricably entangled in it, and udev has provided the best support for device management.

On the other hand, partially due to backlash against systemd, several alternatives to udev have warmed up and switched into high gear. Also, Patrick himself is wary of systemd (for the obvious reasons):

On the gripping hand, Slackware is ultimately a practical distribution, and Patrick is pragmatic about its development. If past behavior is any guide to the future, he will adopt whatever system serves users' needs without crippling the system or imposing an undue maintenance burden on the Slackware development team.

If I had to predict anything, it's that he will hold off on adopting a systemd-dependent udev for as long as possible while kicking the tires on some udev alternatives (and perhaps assessing prospects for assisting in their development) and keeping an eye on systemd to see if it shapes up. "As long as possible" may be years -- udev-182 isn't intolerably bad. Eventually he will choose udev/systemd or one of the udev alternatives, based on what his investigations teach him.

I hope Slackware comes out of the process unburdened by systemd, but trust that Patrick will make his decision rationally. If that means holding our noses and learning to live with systemd, so be it.

I've read this entire thread, and you got some things wrong about how systemd works. Sorry. You do not have convincing proof.

What makes you think he is not doing something? That he has not done research? Why does he need to be a contributor, if something he has already works?

I've been at the point of doing something some time. I've studied systemd code. I've tried coding to test the userspace concepts. This, and other discussions don't interest me because they don't go anywhere. I'm interested in preventing the userspace from turning to crap. So I will be willing to engage people technically to solve problems. Reaper has provided some good information that I didn't know about. That shows he really is doing homework on this.

Why do you want to defend Poettering? He defamed BSD for no good reason when questioned why he doesn't support it. His attitude is childish, but we are supposed to just give in to him; we have no choice and can't do anything? You severely underestimate what a maintainer with a bad attitude can cause people to do. I never have used BSD, but Poettering showed himself very poorly to the whole community. The BSD people don't deserve that. Reaper may be mad too, but please don't provoke him by saying "you aren't doing anything". You do not know that.

I do not have convincing proof?
Man pages and articles from one of the main systemd developper aren't convincing?
ReaperX7 did his homework?

If he's claiming that systemd is one single bloated binary that try to do everything, he clearly did not inspect a systemd source tarball and therefore he didn't do his homework.

Linux systems could benefit from an optimized loader system similar to the one in Windows. What I'm referring to are the features that track the files and disk blocks that are loaded. The next time that the system is started or a particular program is loaded, the required modules and files are preloaded. That has the effect of turning a lot of dis-contiguous disk I/O into contiguous I/O and loading information before it is needed by programs. It greatly speeds up launching applications and system initialization.

Some operating systems achieve this anticipatory loading by saving a snapshot of a booted system and then loading the entire snapshot prior to initializing the OS. The normal drivers, modules and tasks are all loaded from a contiguous disk snapshot that was saved. If a system administrator wants to add things, they simply boot the system, start the additional programs and save a new snapshot. Some operating systems also provide a "virtual shell" that allows administrators to directly load or unload tasks, modules and drivers in the snapshot.

Parallelism in initialization sounds like a good idea until one realizes that the disk access is a major bottleneck. In reality, most of the advantage to "parallelism" is by having the disk I/O occur in parallel with other initialization tasks. That can mostly be achieved by anticipatory loading without the need for excessive parallelism.

I would really be interested in some benchmarks of "systemd" versus other initialization systems to see how much (if any) speed up "systemd" provides. Also, if there are any Linux extensions to provide anticipatory loading, how much benefit do those provide versus "systemd". Does "systemd" provide anticipatory loading, and does it provide that for loading normal applications as well as system initialization?

Whether one likes "systemd" or not, the key question is whether "systemd" provides significant benefits over other initialization systems. Complexity by itself isn't a bad thing if that produces enough benefits to justify the complexity. Some problems require complex solutions. Sometimes the complexity can become a worse problem than the ones it tries to solve.

On Arch Linux my total boot time is exactly 3.782 seconds (kernel + userspace), on a ssd of course.

How long did it take with a non-systemd distro?

Regular desktop and laptop computers use between 5 an 15 seconds for POST, which brings the total boot time down to between 9 and 19 seconds, which is not bad at all. Servers, on the other hand, typically have a POST process that takes between 2 and 5 minutes. Saving 30 seconds on boot time becomes a lot less relevant in those cases.

Is your system fully usable after 4 seconds? On Windows, a typical server can take as little as 30 seconds from completed POST to the desktop appears (provided you can type your password quickly enough), but you can't actually do much until another 60-90 seconds have passed, as a number of important services are still starting in the background. Actually, you can save a quite few seconds by NOT logging in immediately, but instead wait until the drive activity light settles down a bit.

Regular desktop and laptop computers use between 5 an 15 seconds for POST, which brings the total boot time down to between 9 and 19 seconds, which is not bad at all. Servers, on the other hand, typically have a POST process that takes between 2 and 5 minutes. Saving 30 seconds on boot time becomes a lot less relevant in those cases.

Is your system fully usable after 4 seconds? On Windows, a typical server can take as little as 30 seconds from completed POST to the desktop appears (provided you can type your password quickly enough), but you can't actually do much until another 60-90 seconds have passed, as a number of important services are still starting in the background. Actually, you can save a quite few seconds by NOT logging in immediately, but instead wait until the drive activity light settles down a bit.

Yes, my system is fully usuable after ~4 seconds since it is the time for the kernel and all the userspace to boot up.
Actually, userspace alone boot in 1.021 second.

I didn't check exactly the time that it took to boot on Slackware for instance, but it was at least 2x slower for sure.
The boot time on Gentoo are quite nice too.
OpenRC is the fastest thing i know next to systemd actually but it doesn't have service supervision unfortunately.

Yes, my system is fully usuable after ~4 seconds since it is the time for the kernel and all the userspace to boot up.
Actually, userspace alone boot in 1.021 second.

I didn't check exactly the time that it took to boot on Slackware for instance, but it was at least 2x slower for sure.
The boot time on Gentoo are quite nice too.
OpenRC is the fastest thing i know next to systemd actually but it doesn't have service supervision unfortunately.

I have been reading and trying to not comment any more on this thread, but it has become too strange...

And following earlier posts, you would probably ignore it anyway, accuse me of not contributing anything useful and then post another useless number to demonstrate how smart you are... like I said, this thread has become very strange.

Yes, my system is fully usuable after ~4 seconds since it is the time for the kernel and all the userspace to boot up.
Actually, userspace alone boot in 1.021 second.

Well, that just can't be done with servers, I'm afraid. A number of processes takes longer to initialize than 2 seconds, and some depend on other services which also take a few seconds to start. For instance, I've found that I need to wait at least 2 seconds after starting libvirtd before I can start a VM.

But then again, systemd is supposedly not really about reducing boot time. I have to admit that after reading some of the documentation, I still don't know what it's supposed to do. It certainly makes Linux look a lot more like Windows, binary logfiles and all, but surely that's not exactly an improvement?

And following earlier posts, you would probably ignore it anyway, accuse me of not contributing anything useful and then post another useless number to demonstrate how smart you are... like I said, this thread has become very strange.

Well number are really useful to compare the boot speed against sysvinit since this thread turned in a "Let's say total crap about systemd without any proof".
I won't speak for sysvinit, but all i can say is that systemd is capable of booting an entier userspace in 1s. Do you want to know this statement is based on what? It's based on a nice utility that comes with systemd called systemd-analyze.
It analyze and save how much time the last bootup took.