From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S96Ga-0006oT-Qt for garchives@archives.gentoo.org; Sun, 18 Mar 2012 02:54:45 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 51622E059C; Sun, 18 Mar 2012 02:54:26 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 55270E08C7 for ; Sun, 18 Mar 2012 02:52:32 +0000 (UTC) Received: from mail-vx0-f181.google.com ([209.85.220.181]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1S96ES-0033Iz-Uy for gentoo-user@lists.gentoo.org; Sun, 18 Mar 2012 09:52:33 +0700 Received: by vcge1 with SMTP id e1so6532518vcg.40 for ; Sat, 17 Mar 2012 19:52:29 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.52.88.103 with SMTP id bf7mr3470291vdb.72.1332039149481; Sat, 17 Mar 2012 19:52:29 -0700 (PDT) Received: by 10.220.58.200 with HTTP; Sat, 17 Mar 2012 19:52:29 -0700 (PDT) Received: by 10.220.58.200 with HTTP; Sat, 17 Mar 2012 19:52:29 -0700 (PDT) In-Reply-To: References: <709768995.843751.1331957483491.JavaMail.open-xchange@email.1and1.com> <20120317115300.GB3615@acm.acm> Date: Sun, 18 Mar 2012 09:52:29 +0700 Message-ID: Subject: Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ] From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=20cf307f3c0454ecf204bb7b885b X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: 0e837e62-d252-4eb8-960b-e06fdb9c081c X-Archives-Hash: 3c4f87b3047c7f3e7b4d63ade77faa02 --20cf307f3c0454ecf204bb7b885b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mar 18, 2012 9:44 AM, "Joshua Murphy" wrote: > > On Sat, Mar 17, 2012 at 10:12 PM, Nikos Chantziaras wrote: > > On 18/03/12 03:45, Canek Pel=C3=A1ez Vald=C3=A9s wrote: > >> > > >> [...] > >> > >> * It tries to unify Linux behaviour among distros (some can argue that > >> this is a bad thing): Using systemd, the same > >> configurations/techniques work the same in every distribution. No more > >> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by > >> different distros. > > > > > > Out of the things you listed, this strikes me as the most important. Linux > > really needs standards. When I install software on Windows, it knows how to > > add its startup services. On Linux, this is all manual work if your distro > > isn't supported, especially on Gentoo. If there's no ebuild for it, yo= u > > spend your whole day trying to make it work. > > > > > > My day job's on the windows side of things... and as true as it is > that the application developer knows the approach they're going to use > today to get their piece of software to start when windows does (as > often as not, doing so without the knowledge of the user), there's a > *massive* range of ways to do just that, and they *do* vary as you > move from one version of windows to the next... and tracking down > what's actually starting at boot (and why) without tools explicitly > created to give that information is an incredible amount of work on > the side of the user and even the usual admin. I'm not sure I'd cite > that as a positive benefit on the windows side of things... > True, that. Case in point : a couple of months back, I had great trouble trying to start the server service *after* the iSCSI service. Finally have to resort on a script starting using Windows Scheduler (post-boot event) On Linux, I *know* where services are started. The locations might be different from one distro to another, but within one distro, there's (usually) only 2 ways a service get started. Plus, as a server guy, I don't really care if the boot up process is faster; I need deterministic boot process, with as succinct instrumentation as possible. Rgds, --20cf307f3c0454ecf204bb7b885b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 18, 2012 9:44 AM, "Joshua Murphy" <poisonbl@gmail.com> wrote:
>
> On Sat, Mar 17, 2012 at 10:12 PM, Nikos Chantziaras <realnc@gmail.com> wrote:
> > On 18/03/12 03:45, Canek Pel=C3=A1ez Vald=C3=A9s wrote:
> >>
> <snip>
> >> [...]
> >>
> >> * It tries to unify Linux behaviour among distros (some can a= rgue that
> >> this is a bad thing): Using systemd, the same
> >> configurations/techniques work the same in every distribution= . No more
> >> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks= by
> >> different distros.
> >
> >
> > Out of the things you listed, this strikes me as the most importa= nt. Linux
> > really needs standards. =C2=A0When I install software on Windows,= it knows how to
> > add its startup services. =C2=A0On Linux, this is all manual work= if your distro
> > isn't supported, especially on Gentoo. =C2=A0If there's n= o ebuild for it, you
> > spend your whole day trying to make it work.
> >
> >
>
> My day job's on the windows side of things... and as true as it is=
> that the application developer knows the approach they're going to= use
> today to get their piece of software to start when windows does (as > often as not, doing so without the knowledge of the user), there's= a
> *massive* range of ways to do just that, and they *do* vary as you
> move from one version of windows to the next... and tracking down
> what's actually starting at boot (and why) without tools explicitl= y
> created to give that information is an incredible amount of work on > the side of the user and even the usual admin. I'm not sure I'= d cite
> that as a positive benefit on the windows side of things...
>

True, that.

Case in point : a couple of months back, I had great trouble trying to s= tart the server service *after* the iSCSI service. Finally have to resort o= n a script starting using Windows Scheduler (post-boot event)

On Linux, I *know* where services are started. The locations might be di= fferent from one distro to another, but within one distro, there's (usu= ally) only 2 ways a service get started.

Plus, as a server guy, I don't really care if the boot up process is= faster; I need deterministic boot process, with as succinct instrumentatio= n as possible.

Rgds,

--20cf307f3c0454ecf204bb7b885b--