On 01/26/2016 05:51 AM, Peter Duffy wrote:
> On Mon, 2016-01-25 at 08:05 -0600, Chris Adams wrote:
>> Once upon a time, Peter Duffy <peter@xxxxxxxxxxxxxx> said:
>>> The thing which always gets me about systemd is not the thing itself,
>>> but the way it was rolled out. When I first installed Red Hat 7, if a
>>> window had appeared telling me about systemd and asking me if I wanted
>>> to use it, or stick with the old init framework, I'd have opted for the
>>> latter (as I was interested primarily in continuity from the previous
>>> version.)
>>
>> That's not really practical for something as core as the init system.
>> Trying to support two init systems in parallel, especially for as long
>> as Red Hat supports a RHEL release, would require a massive amount of
>> work. A distribution is about making choices and implementing them in
>> the best way possible; for "leaf" packages like an editor or a web
>> browser, it is easy to have multiple options (where they don't
>> conflict), but core stuff like the kernel and init system don't leave
>> lots of room for choice.
>>
>
> Ultimately it's all software, and software can be
> written/changed/updated to do anything required - all that's needed is
> the skill and the motivation. If systemd is so "core" that it can't be
> unplugged and plugged easily, and glues together a lot of otherwise
> unrelated components, then it's just bad software - end of story (the
> problems with tightly-coupled components were first identified over 40
> years ago, and modularization has been the watchword ever since.)
>
> In my view, it's high time someone independently analysed systemd down
> to basic code level, and understood why it's so invasive (if it actually
> is.) Then the way forward would be clear - fork it, and produce a new
> version which wasn't so invasive, and which could be swapped in/out. I'm
> not saying it would be easy! ("We do not do these things because they
> are easy - we do them because they are hard!")
>
>> I remember people complaining about SysV-style init too, "what's with
>> all these scripts" and "why can't I just add a line to /etc/rc".
>> systemd is a different way of thinking, but it isn't exactly original
>> (Sun and Mac have similar launchers); practical experience has shown
>> that this can be a better way of managing services.
>
> No one is saying that sysvinit is perfect. What I can't grasp is why
> replace it with something which is no less imperfect, and is almost
> certainly worse in at least some respects - and to make that replacement
> unavoidable and mandatory.
>
> I'm also still trying to figure out in what way systemd is supposed to
> be "better". I've seen the following things claimed for it:
>
> - faster boot time (this was apparently the main motivation behind it.)
> My experience with systemd-managed systems has been limited - but so
> far, I've not noticed faster boot times with systemd (maybe because the
> boxes booted fast enough previously.)
>
> - parallel startup of services. Not sure that I'd want that anyway - too
> much risk of two services trying to grab the same resource at the same
> time - I'm absolutely happy with the sysvinit approach of one service
> startup completing/failing before the next one happens. That way, things
> are nice and orderly.
>
> - better handling of hot-plug devices. I've not yet seen that in action,
> but that is the one thing which makes me inclined to investigate systemd
> in more detail.
>
>> Nobody is forcing you to run systemd; you can continue to run CentOS 6
>> and earlier for years. But if you are a system administrator, your job
>> is about learning and adapting, not trying to keep a static setup for
>> life. systemd is different (just like SELinux was years ago), but I
>> suggest you learn it. It can make your admin life easier. Is it
>> perfect? No, nothing ever is; I do think it is a big improvement
>> though.
>>
>
> My job as a system administrator is to serve the users who use the
> servers I manage and administer, and to keep those servers and services
> in suitable condition for the users to do their work and earn their
> daily bread.
>
> As we all know (don't we just?) sysadmin work and responsibilities are
> heavy, and frequently eat into evenings, nights, weekends and
> (so-called) holidays. Anything which increases the sysadmin workload -
> e.g. suddenly faced with a vertical learning curve just to do the tasks
> they did yesterday, or a GUI which leaves them unable to find anything
> on their screens - is a major issue, and prejudicial not only to the
> sysadmin's own work, but also to that of the users to whom he/she is
> responsible. And when you're talking about systems used by hundreds and
> thousands of users, that's a big problem.
So don't use it then .. EL6 has support until 30 Nov 2020.
SystemD is not better, the 3.x and 4.x Linux kernels are not better,
Gnome 3.x is not better, KDE 4.x is not better. Blah, Blah, Blah.
Red Hat Linux 3.0.3 with the 1.2.13 kernel .. now there was an operating
system.
I have been doing this stuff since 1981/82 time frame, starting with
AT&T Unix on an 3B system
(https://en.wikipedia.org/wiki/3B_series_computers) that had floppy
disks, 10 MB hard drives, real-to-real tapes for backups, and used a
brand new UNIX System V (https://en.wikipedia.org/wiki/UNIX_System_V).
Now, your cell phone has hundreds of times the computing power and
storage and it literally fits in your front pocket.
So tell me about long nights doing sysadmin. Tell me about change in
the way the OS or the Desktop or the hardware works. Been there, done that.
If you don't like it, every bit of the source code is available. You
and everyone else who doesn't like can take that and build 'something
else'. And before you accuse me of being an ass .. that is EXACTLY what
I (and the rest of the CentOS team) did 12-13 years ago. That's why you
have CentOS today, and that's why it's free. If you think you can do it
better, then show us. Maybe you can.
Thanks,
Johnny Hughes
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx https://lists.centos.org/mailman/listinfo/centos
