> I will be too. I'm testing fedora in a virtualbox session, and besides
> some software not being truly "bleeding edge".

Except they chose grub2-beta (still beta, though grub2 is released)
before it supported automatic detection and multi-booting setup
requiring manual intervention. Arch are making good discussion and
testing.

I was intrigued by the selinux by default of fedora but I will
not install Fedora again for a long time for a few reasons. Many
criticise Debian but it is a lot better than fedora.

--
__________________________________________________ ______

Why not do something good every day and install BOINC.
__________________________________________________ ______

> Once again: I'm not sure whether there ever was something like a "Unix"
> system. Furthermore I don't get why systemd is not Unix-like.

The Unix philosophy of 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)

> I would
> argue that it is a response needed in order to get the maximum out of
> our hardware, which differs quite extensively from the one Unix was
> originally designed for.
>

That is exactly what unix was designed for in various flavours but
performance and so cpu handling depends on the application. Systemd is
larger than init, so for embedded it may well quadruple boot time.


> Am 22.07.2012 18:17, schrieb Nicholas MIller:
> > I'm also curious how the people who work on initscript believe systemd is
> > superior.
>
> Just take a look at [1].
>

A list made to impress. If you actually look at what it means to you, is
it so attractive.


> Am 22.07.2012 18:22, schrieb Jorge Almeida:
> > That's what worries me, that you sincerelly find it superior. I don't doubt
> > your good intentions.
>
> I'm not aware of anyone who has looked into it and doesn't find it
> superior. How else would you explain that all the major distributions
> are switching over and/or already have? Even before systemd there was
> "Upstart", because Canonical "discovered" that the old way of booting is
> not up to make most out of today's hardware.

Is debian switching if not I believe ubuntu and debian probably make up
far more share than perhaps all the others.

--
__________________________________________________ ______

Why not do something good every day and install BOINC.
__________________________________________________ ______

> > that without ck. Change ownership of some things to a
> > 'local' login ? I don't want that to happen.
>
> You're free to fight again changes or improvements. The simplest way I
> know consist in installing a 70th year old system and don't update it.

You should work for Redhat.

--
__________________________________________________ ______

Why not do something good every day and install BOINC.
__________________________________________________ ______

On Mon, Jul 23, 2012 at 5:35 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> Systemd is
> larger than init, so for embedded it may well quadruple boot time.

What utter bullshit. Please, Kevin, if you are going to throw around
numbers, do some measurements first.

systemd is so far even more successful in embedded environments than
in desktop ones (i.e. embedded people seem to be more eager to ship
it), I doubt that would be the case if it is four times slower to
boot. I'm currently using it on my raspberry pi, without any problems.
I have not done any performance measurements, but there are very good
reasons why initscripts are expected to be slower than systemd (on the
same setup) and it has nothing to do with bash versus C, or the size
of the binaries.

> Is debian switching

That remains to be seen. There are certainly lots of debian people
involved with systemd upstream, and there are people working on
systemd integration in debian.

-t

[2012-07-23 16:35:26 +0100] Kevin Chadwick:
> You should work for Redhat.

Could you give us a break for a couple minutes and reflect on how many
people you just spammed with your dozen content-free emails? Thanks for
thinking for more than half a second next time you send something here.

--
Gaetan

For having used systemd myself, I am inclined to believe that it
definitely fits the KISS principle. Systemctl is only a frontend to
simplify the addition and removal of services. Simplicity is only a
matter of learning new commands (systemctl enable <daemon>.service,
e.g.). What systemctl really does when you enable a service is that it
creates symbolic links in /etc/systemd/system/<target>.wants.target/
that point to appropriate deamon launch helpers located in
/usr/lib/systemd/system/. The proper target folder (graphical,
multi-user, single-user) is obtained by reading the actual target
file, but this can be overridden if you do the links manually.

What I find really powerful of systemd is that it hooks onto the
daemon itself and monitors exit codes and log files. Finding what's
wrong with your sshd service is only a matter of typing "systemctl
status sshd.service". You get current activity, its PID, the actual
command it ran to start it, its status code if it ceased working, and
the few last lines from the log file.

To find out what runs at startup, you may use systemctl. I don't know
the particular command, so I don't use it myself. I managed to figure
out how to do it in a couple of seconds: you only have to "ls" the
right directory. Graphical mode? "ls
/etc/systemd/system/graphical.target.wants". Multi-user: "ls
multi-user.target.wants". Could not be simpler.

I have also found that my system boots much more rapidly with systemd.
I can have a fully logged-in system running XFCE4, on older hardware
(Intel Pentium 64-bit laptop) in less that 40 seconds.

--
Sébastien Leblanc

On Mon, 23 Jul 2012 17:57:46 +0200
Tom Gundersen <teg@jklm.no> wrote:

> On Mon, Jul 23, 2012 at 5:35 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk>
> wrote:
> > Systemd is
> > larger than init, so for embedded it may well quadruple boot time.
>
> What utter bullshit. Please, Kevin, if you are going to throw around
> numbers, do some measurements first.
>
> systemd is so far even more successful in embedded environments than
> in desktop ones (i.e. embedded people seem to be more eager to ship
> it), I doubt that would be the case if it is four times slower to
> boot. I'm currently using it on my raspberry pi, without any problems.
> I have not done any performance measurements, but there are very good
> reasons why initscripts are expected to be slower than systemd (on the
> same setup) and it has nothing to do with bash versus C, or the size
> of the binaries.

To add, in general sysVinit does not see much use in modern embedded systems.
For instance, (open)webOS (and probably android) has gone the upstart way. So
far, only network appliances use sysVinit, but these are pretty conservative,
e.g. many are still on 2.4 kernels (stock cisco, tomato, dd-wrt, etc).

>
> > Is debian switching
>
> That remains to be seen. There are certainly lots of debian people
> involved with systemd upstream, and there are people working on
> systemd integration in debian.
>
> -t



--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Hi,

Am 23.07.2012 17:29, schrieb Kevin Chadwick:
> Tested, simply sophisticated and as fast as you make it.

There is no parallelization, no socket activation and no auto mounting.
In no way can it be as fast as systemd.

> Once you get to desktop level and SSDs, who cares about a few seconds.

It's not only about speed, but speed is a nice bonus. Its also about
reliability. But I'm not going to enumerate the advantages of systemd
over and over again. Just read the blog posts by Lennart .

> The fastest booting systems (< 1 second) use init and won't use systemd.

Which systems do you have in mind? Personally I can tell you out of
experience that my system boots up faster with systemd.

> WRT pulse audio it won't run under a grsecurity kernel so first
> I'd say define modern desktop. How functional, how secure.

On a "modern desktop" you probably have bigger concerns regarding
security then running grsecurity. That said it should run fine with
SElinux, which Fedora is using by default. Furthermore grsecurity seems
to focus on servers anyway, so I'm not sure why you even bring this up?

Best regards,
Karol Babioch

On Jul 24, 2012 12:10 AM, "Gaetan Bisson" <bisson@archlinux.org> wrote:
>
> [2012-07-23 16:35:26 +0100] Kevin Chadwick:
> > You should work for Redhat.
>
> Could you give us a break for a couple minutes and reflect on how many
> people you just spammed with your dozen content-free emails? Thanks for
> thinking for more than half a second next time you send something here.
>
> --
> Gaetan

Couldn't have said it better. I'm not by any means a technical expert, but
even I could see how much "basis" his posts had (or didn't)

On 22 July 2012 13:41, Damjan <gdamjan@gmail.com> wrote:

> Also, by splitting it in different files you make it more robust. You
> don't want to bork your network setup just because you were editing your
> locale and forgot to close a quote.


@Damjan: this isn't completely true because if the config file parser is
well coded it just can ignore the faulty locale line while correctly
parsing everything else, that's what I do when I need to parse a file: if a
line has a typo or a value is out of range or plain wrong I make the parser
show a warning message and keep parsing the config file

My 2 cents regarding rc.conf (as a 2-years Arch fan):
Seems I've been out of sync lately because I was totally unaware about this
grand change.
First of all I want to say I'm admitedly in love with Arch (as strange as
it sounds, being in love with software): for a lazy guy like me Arch is
both easy and simple, in fact easier and simpler than any other GNU/Linux
distro out there (may be with the only exception of Slackware).
It has a clean file layout, the packaging system is one of the best out
there -if not the best- and it's easy to see The Arch Way is implemented
system wide.
One of the great things I specially love about Arch is /etc/rc.conf and
it's whole sysconfig scheme: it's plain *awesome* to have init
configuration centralized in one slim file instead scattered through
god-may-know where; /etc/rc.conf is almost *perfect* specially if I compare
it with SysV Init cumbersome scheme, with plenty of directories and S and K
files, come on, that really sucks.
But as things change and as systemd is becoming a de-facto on GNU/Linux
distros, and there's nothing that can be done to keep the awesome rc.conf
from being splitted, I vote for EMBRACE THE CHANGE AS SOON AS WE CAN.
If rc.conf has it's days counted, then don't delay what must be done: Arch
is bleeding edge so let's honour it. While I don't like the idea of losing
rc.conf and I know I will miss the 'good old days' I don't want to delay a
change I know it's unavoidable :'(

Since I first met Arch Linux and since I first read The Arch Way I
instantly knew this was the distro I was looking for since so much time, it
was already packed with nothing else than awesomeness. Because that I
strongly believe devs and TUs and everyone else who contribute to the
distro development knows what's the best way to keep up with the The Arch
Way and to keep Arch Linux a simple, minimalist, clean, easy and
lightweight GNU/Linux distribution.

Cheers =)

--
-msx