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:
Konstantin Olchanski <[log in to unmask]>
Reply To:
Konstantin Olchanski <[log in to unmask]>
Date:
Mon, 12 Aug 2013 08:40:33 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (97 lines)
On Mon, Aug 12, 2013 at 10:24:42AM -0400, Paul Robert Marino wrote:
> well thats mostly due to the fact that its new and far more complex.
> there was a mad rush for every one to rewrite there statup scripts and
> quite a few of them weren't done very well and others weren't fully
> thought out.

My prediction is that it is going to be like the HAL/UDEV story. Before,
if you wanted to automatically "chmod a+wr /dev/ttyUSB*", you just put it
in /etc/rc.local. Now you have to write some arcane udev rules that have to
be adjusted for every new os update. Documentation and examples are absent.

Also same as the NetworkManager introduction. Something that was described
in many books is replaced with something described by a few paragraphs
in some obscure malformatted wiki. For example the fact that on SL
the NM settings are stored in /etc/sysconfig/network-scripts/ifcfg-eth* files
is documented (I was able to find the obscure wiki that mentions
this in passing), but documentation for the exact format and meaning
of the different entries is absent.

K.O.


> 
> what I find worse is they did a ground up rewrite and didn't touch the
> network configuration portion wasn't rewritten.
> 
> The network scripts are limited and problematic if you want to do any
> thing advanced. for example its a long story why but on one device a
> bridge I have to add a static arp entry. iproute2 has been able to do
> this for as long as i can remember but there was no clean way to get
> it to work was to hack the network scripts in order to add the
> functionality.
> Really the scripts network scripts need to have hooks added so user
> defined scripts can be called at various points of the startup and
> shutdown of an interface. but more than that they mostly date back to
> the 2.0 Kernel and Linux's Network capabilities have change
> significantly since then but for the most part these scripts keep
> people stuck in the 90's.
> 
> On Wed, Jul 31, 2013 at 10:21 PM, zxq9 <[log in to unmask]> wrote:
> > On 07/31/2013 11:57 PM, Tom H wrote:
> >>
> >> On Tue, Jul 30, 2013 at 5:12 PM, zxq9<[log in to unmask]>  wrote:
> >>>
> >>> On 07/30/2013 10:26 PM, Tom H wrote:
> >>>>
> >>>> On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcia<[log in to unmask]>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> On Tue, Jul 30, 2013 at 8:18 AM, Tom H<[log in to unmask]>   wrote:
> >>>>> Thanks, good link. I'm just concerned it's going to cause build
> >>>>> problems for *every single open source daemon* as their SRPM's or
> >>>>> .spec files need to have two sets of options, one for the older SysV
> >>>>> init scripts and one for systemd, or need to be split to two different
> >>>>> .spec files. This is going to be so much fun!
> >>>>
> >>>>
> >>>> You're welcome.
> >>>>
> >>>> Very true. Similar to some current Fedora spec files:
> >>>>
> >>>> %if 0%{?rhel}
> >>>> ...
> >>>> %endif
> >>>> %if 0%{?fedora}
> >>>> ...
> >>>> %endif
> >>>>
> >>>> An eyesore and a mess; until December 2020...
> >>>
> >>>
> >>> tl;dr, Relevant Fedora thread first:
> >>>
> >>> http://lists.fedoraproject.org/pipermail/devel/2012-October/thread.html#172159
> >>>
> >>> Reminds me of a dismal post from October:
> >>> http://zxq9.com/archives/711
> >>
> >>
> >> I was only commenting on the more complex and unreadable spec files.
> >> Otherwise I'm happy about systemd and journald. In short, the kernel
> >> has evolved, the applications have evolved, why not the init system?
> >
> >
> > Its not that the init system can't do with some modernization, its that the
> > new system has a severe case of featuritis that is spawning little eddies of
> > nonlocalized complexity all over the place. Modernizing a system and tossing
> > everything that's come before in the interest of a deliberately incompatible
> > rewrite are different things. Remember HAL?

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

ATOM RSS1 RSS2