Sounds like a UNIX way, but really no.
On 2011年07月17日 11:32, Sergey wrote:
Hello.
I was thinking about it for some time, and got a few ideas I wanted to
share. Sorry for the long email, I'm just trying to explain in details
what the ideas are about, what benefit they bring and why I've chosen
that way, i.e. why these ideas cannot be done using existing tools.
If you don't want to read the entire email, just scroll down to words
systemd packages.
What's the problem?
=
There's such thing as Linux. I often tell people how great it is - it's so
flexible, you can always modify it the way you want.
But what makes it great? Programs? Features? Price? No, it's Unix philosophy
behind it. The best part of it is:
Write programs that do one thing and do it well
What's so good in it?
The matter is that there's no ideal program. Of course every program has
bugs, but that's not the main reason. The main reason is that people don't
like when program does not do what they expect AND different people expect
different things. This is where the philosophy hits.
On the windows-like systems, when something does not work like you want,
it's still a single highly integrated system, you can't do much about it.
But in Linux, where the system is a number of separated components, you
can replace any part of it and everything else will still work. You don't
like KDE - there's GNOME. You like KDE apps, but don't like KDE WM - easy,
replace it with compiz and use the rest of KDE apps as usual. You need some
light WM to save memory - IceWM is for you, all the browsers and office
programs will still work there. You're setting up a server and don't want
Xorg to eat your resources - no problem, just remove it. If you need, you
can replace every part of the system, DM (KDM, GDM, XDM, SLIM), glibc
(uclibc, eglibc), init-daemon (sysvinit, initng, upstart), even kernel...
It's so cool, not many systems in the world give you such a great flexibility.
All this works because in Linux all programs do one thing and do it well.
And there comes systemd, which aims to do every thing in the world and a
few more. The question one can think when he sees it - is it really a
linux program?
Bla-bla-bla, what do you suggest?
===
You can split it up! Make it the Unix way. Instead of a large and highly
integrated bunch of programs make it a number of small separated components
with weak dependencies between each other.
That would give many benefits to the project. For developers it will make
the structure a lot cleaner, easy to understand, easy to extend and support.
Developers usually don't like bloated software that nobody-knows-how-it-works.
For users it will give the ability to make it look like they want it to be.
Any program is perfect for user if it does exactly what he wants. But it's
impossible to write the program that suits everybody out of the box, so in
the end the most flexible programs win.
Trying to add too many features into a single program (Let's write a builtin
tetris game, that shows up when user presses C-A-D! Why? Why not?!) you may
end up with none of them implemented good enough. It's rather pointless to
make the change just to change something. I.e. you can fight with bash
scripts, but what for? For speed? Bash can spawn ~700 scripts per second and
can parse about 5 megabytes of code during the second. How much can you
possibly win for 20 scripts a few kilobytes each? Instead of guessing what
features can be implemented let's look at real tasks that should be solved,
and implement each task in a separate application.
What are those tasks? What exactly are those problems that should be fixed
with new init system, that could not be fixed before? If the main goal -
a faster boot process (I'm actually following a video presentation of
systemd here), then let's look at the usual boot process:
[udev] - [filesystems] - [iptables] - [network] - [syslog] -
[avahi] - ...
and see what we can do here.
First task - start services in parallel. The key idea is to create all the
sockets and then start all the services... well, you already know that. :)
Let's remember this task.
Second task - check and mount filesystems in parallel with starting services.
Let's remember this task too.
[do I miss anything else related to faster boot?]
So, to get the first task done we need a single daemon, let's call it
`sysunixd`, that does one simple thing - creates a lot of unix sockets and
then starts a lot of applications. That's all. :)
Can we do it using existing applications, like `inetd`? Well, not really. The
key difference between `inetd` and `sysunixd` is that every inets service is
either started on-demand (when someone accesses the socket) or is not started
at all. But services in `sysunixd` should be either started always or not
started at all. On-demand startup in `sysunixd` may be a
