SCIENTIFIC-LINUX-USERS Archives

August 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Robert Arkiletian <[log in to unmask]>
Reply To:
Robert Arkiletian <[log in to unmask]>
Date:
Sun, 18 Aug 2013 18:03:17 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (75 lines)
On Sun, Aug 18, 2013 at 4:44 PM, Paul Robert Marino <[log in to unmask]> wrote:
> I somewhat agree however I still think systemd needs an other year or two to
> bake before its enterprise ready.
>
> 1) the scripts are still too new and most of them haven't been thoroughly
> thought out yet. There are a lot of things that change when you switch from
> simple start and stop scripts to using an active process manager which take
> time for the developers and system administrators to wrap their heads
> around. Frankly they haven't had enough time to do it well and I will have
> issues all over the place with 3rd party applications when RHEL 7 is
> released because of it.
>
> 2) systemd isn't the first of its kind on Linux in fact Gentoo Linux has
> been doing something similar for years with its startup scripts.
>
> 3) in many ways the design of systemd is very desktop centric which is great
> for a desktop or laptop but horrible in an enterprise. Frankly I'm horrified

+1 and I don't care if my servers take a few seconds longer to boot.
Also, one of the first things I do when configuring a server is remove
NM. When running Fedora 19 the new gnome is also too foreign to me. I
much prefer xfce instead. I wish they had made that the default for
rhel7. The trend towards binary log files is also a little
uncomfortable. I'm so used to using simple tools to parse log files.

> by the idea that if a inexperienced sysadmin does a default install instead
> of our standard nobase install that someone my come along and stick a WiFi
> dongle in a box and create a loop or security hole because it was
> immediately detected and the services to auto configure it were
> automatically started without a authorized sysadmins intervention. By the
> way that is a scenario that I've seen users attempt before because they
> needed access from their desktop and didn't want to wait for or were just
> too lazy to request a firewall change. For that matter I had a consultant
> just this past week accidentally create a loop on my network because he had
> made a mistake in the network configuration and NetworkManager decided to
> bridge several interfaces ( I never thought I'd hear my self say this but
> thank god for spanning tree). So auto starting and restarting services based
> on things like hardware event are scary to me for good reasons. Additionally
> if I have a service that occasionally crashes due to a bug or
> misconfiguration but systems keeps relaunching it I may never know I have a
> problem I'd rather the process crash and get a one time complaint or trouble
> ticket from the user and fix it than have users grumbling how my systems
> suck because they keep having problems but the guy in the NOC sees all green
> on his screen when the user calls and keeps dismissing their complaints
> without further investigation.
>
>
> -- Sent from my HP Pre3
>
> ________________________________
> On Aug 18, 2013 9:29, Tom H <[log in to unmask]> wrote:
>
> On Tue, Aug 13, 2013 at 12:30 AM, zxq9 <[log in to unmask]> wrote:
>
>
>> * The old init system was complicated (in that the defaults aren't
>> uniform).
>> Familiarity with the system triumphed over lack of clear implementation
>> and
>> lack of documentation.
>
> All Linux users and developers were victims of laziness and inertia
> when we stuck with the mess that sysvinit scripts are for as long as
> we did, especially after Solaris and OS X showed the way with SMF and
> launchd. We should've at least moved to declarative init files with
> one bash/dash/sh script to start and stop daemons; we didn't and we've
> fortunately gone beyond that with systemd.
>
>
>> * systemd is a huge effort that isn't doing anything to remedy the
>> situation.
>
> One or two years after the release of EL-7, everyone'll wonder what
> all the anti-systemd fuss was about...

ATOM RSS1 RSS2