FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 08-15-2012, 09:21 AM
Kevin Chadwick
 
Default Migration to systemd

> I'd love to see the overall advantages and disadvantages of each of
> those fleshed out on a page where I can read them

Here's one part

A good design would make the init process which is always running and
everyone must run.

1./ Be a small simple binary

2./ Have no dependencies

3./ Be easy to follow, fix and lockdown, best fit being interpreted
languages.

4./ be as fast as possible

systemd meets 4. Sysvinit meets 1-3 well but OpenBSDs init meets 1-3
better


--
__________________________________________________ _____________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
__________________________________________________ _____________________
 
Old 08-15-2012, 10:27 AM
Felipe Contreras
 
Default Migration to systemd

On Wed, Aug 15, 2012 at 11:21 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> I'd love to see the overall advantages and disadvantages of each of
>> those fleshed out on a page where I can read them
>
> Here's one part
>
> A good design would make the init process which is always running and
> everyone must run.
>
> 1./ Be a small simple binary
>
> 2./ Have no dependencies
>
> 3./ Be easy to follow, fix and lockdown, best fit being interpreted
> languages.
>
> 4./ be as fast as possible
>
> systemd meets 4. Sysvinit meets 1-3 well but OpenBSDs init meets 1-3
> better

I agree in general, but systemd doesn't meet #4; we are supposed to
believe that's the case, but does it really?

--
Felipe Contreras
 
Old 08-15-2012, 11:01 AM
Gaetan Bisson
 
Default Migration to systemd

[2012-08-15 12:27:33 +0200] Felipe Contreras:
> On Wed, Aug 15, 2012 at 11:21 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> > 4./ be as fast as possible
> >
> > systemd meets 4.
>
> I agree in general, but systemd doesn't meet #4; we are supposed to
> believe that's the case, but does it really?

Are you trying to play smart by ass throwing random rhetorical questions
around, or just plain stupid not having the slightest beginning of sound
technical evidence to back up your claims?

--
Gaetan
 
Old 08-15-2012, 11:06 AM
Ionut Biru
 
Default Migration to systemd

On 08/14/2012 05:57 PM, Stéphane Gaudreault wrote:
> Systemd has a overall better design than SysV, lots of useful
> administrative features and provide quicker boot up. Considering that it
> has been around in our repositories for some time and that it could be
> considered stable enough for production use, I would suggest to replace
> iniscript by systemd once the 'Missing systemd units' is over. Thus we
> will avoid duplicating our efforts on two init systems.
>
> Any objections to start the migration process ?
>
> Cheers,
>
> Stéphane
>
>

I wonder if we manage to do the switch before gnome 3.6 comes out. I'm
sick and tired of supporting ck and seats and become harder to do so.

I plan to drop consolekit support from gnome and compile it with systemd
full support.

--
Ionuț
 
Old 08-15-2012, 11:15 AM
Thomas Bchler
 
Default Migration to systemd

Am 15.08.2012 11:21, schrieb Kevin Chadwick:
>> I'd love to see the overall advantages and disadvantages of each of
>> those fleshed out on a page where I can read them
>
> Here's one part
>
> A good design would make the init process which is always running and
> everyone must run.
>
> 1./ Be a small simple binary

The systemd main binary is not very large (larger than sysvinit's
/sbin/init, but not by much).

> 2./ Have no dependencies

That is pure BS. If something has no dependencies, it has to do
everything in the binary itself. You either end up with no features, or
potential for tons of bugs.

Having NO dependencies also means you have to bypass the C library and
implement everything from scratch - that is the worst idea ever.

> 3./ Be easy to follow, fix and lockdown, best fit being interpreted
> languages.

So, init should be a small binary in an interpreted language? Am I the
only one who notices you are contradicting yourself.

> 4./ be as fast as possible
>
> systemd meets 4. Sysvinit meets 1-3 well but OpenBSDs init meets 1-3
> better

Where are your AUR packages that provide OpenBSD's init? I haven't seen
them.
 
Old 08-15-2012, 11:31 AM
Felipe Contreras
 
Default Migration to systemd

On Wed, Aug 15, 2012 at 1:01 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
> [2012-08-15 12:27:33 +0200] Felipe Contreras:
>> On Wed, Aug 15, 2012 at 11:21 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> > 4./ be as fast as possible
>> >
>> > systemd meets 4.
>>
>> I agree in general, but systemd doesn't meet #4; we are supposed to
>> believe that's the case, but does it really?
>
> Are you trying to play smart by ass throwing random rhetorical questions
> around, or just plain stupid not having the slightest beginning of sound
> technical evidence to back up your claims?

How is that rhetorical? If you are making the claim that systemd is
faster, you should have clear undeniable evidence at hand, where is
it?

If you are not making that claim, then you agree with me that #4 is not proven.

I'm afraid you will be asking me for evidence (even though I'm not
making a claim, so I shouldn't need it; it's the one making the claim
that has the burden of proof), but here evidence for the contrary in
my case (systemd is slower):

http://people.freedesktop.org/~felipec/systemd/bootchart_sysd.png
http://people.freedesktop.org/~felipec/systemd/bootchart_sysv.png

Cheers.

--
Felipe Contreras
 
Old 08-15-2012, 11:34 AM
Felipe Contreras
 
Default Migration to systemd

On Wed, Aug 15, 2012 at 1:15 PM, Thomas Bchler <thomas@archlinux.org> wrote:
> Am 15.08.2012 11:21, schrieb Kevin Chadwick:
>>> I'd love to see the overall advantages and disadvantages of each of
>>> those fleshed out on a page where I can read them
>>
>> Here's one part
>>
>> A good design would make the init process which is always running and
>> everyone must run.
>>
>> 1./ Be a small simple binary
>
> The systemd main binary is not very large (larger than sysvinit's
> /sbin/init, but not by much).

But that binary alone is useless, and certainly not *simple*.

>> 2./ Have no dependencies
>
> That is pure BS. If something has no dependencies, it has to do
> everything in the binary itself. You either end up with no features, or
> potential for tons of bugs.
>
> Having NO dependencies also means you have to bypass the C library and
> implement everything from scratch - that is the worst idea ever.

No need to overreact, the meaning is clear:

2. Have as few dependencies as possible, preferably dependencies that
are used widely in most systems and that have few dependencies
themselves, and are simple themselves

>> 3./ Be easy to follow, fix and lockdown, best fit being interpreted
>> languages.
>
> So, init should be a small binary in an interpreted language? Am I the
> only one who notices you are contradicting yourself.

No. The "services" (in systemd lingo) should be in an interpreted
language: e.g. shell.

--
Felipe Contreras
 
Old 08-15-2012, 11:55 AM
Thomas Bchler
 
Default Migration to systemd

Am 15.08.2012 13:34, schrieb Felipe Contreras:
>>> 1./ Be a small simple binary
>>
>> The systemd main binary is not very large (larger than sysvinit's
>> /sbin/init, but not by much).
>
> But that binary alone is useless, and certainly not *simple*.

/sbin/init from sysvinit alone is useless. What is your point?

>>> 2./ Have no dependencies
>>
>> That is pure BS. If something has no dependencies, it has to do
>> everything in the binary itself. You either end up with no features, or
>> potential for tons of bugs.
>>
>> Having NO dependencies also means you have to bypass the C library and
>> implement everything from scratch - that is the worst idea ever.
>
> No need to overreact, the meaning is clear:
>
> 2. Have as few dependencies as possible, preferably dependencies that
> are used widely in most systems and that have few dependencies
> themselves, and are simple themselves

Okay, where exactly does systemd violate that?

>>> 3./ Be easy to follow, fix and lockdown, best fit being interpreted
>>> languages.
>>
>> So, init should be a small binary in an interpreted language? Am I the
>> only one who notices you are contradicting yourself.
>
> No. The "services" (in systemd lingo) should be in an interpreted
> language: e.g. shell.

Why should they be? As far as I understand, they're human-readable text
files. One might say this is an "interpreted language".
 
Old 08-15-2012, 12:01 PM
Felipe Contreras
 
Default Migration to systemd

On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bchler <thomas@archlinux.org> wrote:
> Am 15.08.2012 13:34, schrieb Felipe Contreras:
>>>> 1./ Be a small simple binary
>>>
>>> The systemd main binary is not very large (larger than sysvinit's
>>> /sbin/init, but not by much).
>>
>> But that binary alone is useless, and certainly not *simple*.
>
> /sbin/init from sysvinit alone is useless. What is your point?

The rest are rather simple scripts (in the case of Arch Linux).

And you are still ignoring the fact that systemd is anything but
*simple*. How convenient to ignore that argument.

>>>> 2./ Have no dependencies
>>>
>>> That is pure BS. If something has no dependencies, it has to do
>>> everything in the binary itself. You either end up with no features, or
>>> potential for tons of bugs.
>>>
>>> Having NO dependencies also means you have to bypass the C library and
>>> implement everything from scratch - that is the worst idea ever.
>>
>> No need to overreact, the meaning is clear:
>>
>> 2. Have as few dependencies as possible, preferably dependencies that
>> are used widely in most systems and that have few dependencies
>> themselves, and are simple themselves
>
> Okay, where exactly does systemd violate that?

d-bus, for starters.

>>>> 3./ Be easy to follow, fix and lockdown, best fit being interpreted
>>>> languages.
>>>
>>> So, init should be a small binary in an interpreted language? Am I the
>>> only one who notices you are contradicting yourself.
>>
>> No. The "services" (in systemd lingo) should be in an interpreted
>> language: e.g. shell.
>
> Why should they be? As far as I understand, they're human-readable text
> files. One might say this is an "interpreted language".

No, they are compiled binaries. The code is in C (not interpreted).

--
Felipe Contreras
 
Old 08-15-2012, 12:16 PM
Thomas Bchler
 
Default Migration to systemd

Am 15.08.2012 14:01, schrieb Felipe Contreras:
> On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bchler <thomas@archlinux.org> wrote:
>> Am 15.08.2012 13:34, schrieb Felipe Contreras:
>>>>> 1./ Be a small simple binary
>>>>
>>>> The systemd main binary is not very large (larger than sysvinit's
>>>> /sbin/init, but not by much).
>>>
>>> But that binary alone is useless, and certainly not *simple*.
>>
>> /sbin/init from sysvinit alone is useless. What is your point?
>
> The rest are rather simple scripts (in the case of Arch Linux).
>
> And you are still ignoring the fact that systemd is anything but
> *simple*. How convenient to ignore that argument.

What argument? You _claim_ that it isn't simple, but you do not give any
proof for that claim.

>>>>> 2./ Have no dependencies
>>>>
>>>> That is pure BS. If something has no dependencies, it has to do
>>>> everything in the binary itself. You either end up with no features, or
>>>> potential for tons of bugs.
>>>>
>>>> Having NO dependencies also means you have to bypass the C library and
>>>> implement everything from scratch - that is the worst idea ever.
>>>
>>> No need to overreact, the meaning is clear:
>>>
>>> 2. Have as few dependencies as possible, preferably dependencies that
>>> are used widely in most systems and that have few dependencies
>>> themselves, and are simple themselves
>>
>> Okay, where exactly does systemd violate that?
>
> d-bus, for starters.

Dependencies that are
* used widely - check
* in most systems - check
* have few dependencies themselves - check
* are simple themselves - ahemm

So, dbus almost qualifies. You said "for starters", what others are there.

>>>>> 3./ Be easy to follow, fix and lockdown, best fit being interpreted
>>>>> languages.
>>>>
>>>> So, init should be a small binary in an interpreted language? Am I the
>>>> only one who notices you are contradicting yourself.
>>>
>>> No. The "services" (in systemd lingo) should be in an interpreted
>>> language: e.g. shell.
>>
>> Why should they be? As far as I understand, they're human-readable text
>> files. One might say this is an "interpreted language".
>
> No, they are compiled binaries. The code is in C (not interpreted).

Ah, you mean those. You do realize that we now used many of those tools
in our initscripts, and I don't see you complaining about that.

There's probably plenty of reasons why they are in C, I don't know them.
In any case, I don't see how making something in a scripting language is
simpler - in contrast, I always find that writing a small C program for
a task is easier and the result is more robust than a script.


I'll stop discussing with you now, as this will lead nowhere. The fact
remains that all you do is complain, instead of providing an
alternative. The decisions are being made by the people who actually
_maintain_ this stuff inside Arch.
 

Thread Tools




All times are GMT. The time now is 09:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org