On Mon, Jul 23, 2012 at 05:57:46PM +0200, Tom Gundersen wrote:
> > Is debian switching
>
> That remains to be seen.

If Debian intends to continue support for Hurd and
KfreeBSD they can't move to systemd -- which relies
on Linux kernel features to work.

That debian has a disincentive is not the same as
Arch having a disincentive, tho'.

I would rather we use DJB's daemontools as process 1
but I know exactly how these arguments tend to go.

The 23/07/12, Kevin Chadwick wrote:

> Did you read this before posting. It's obvious that reviewing the config
> files and getting the source and finding the bug in C is much easier of
> course and can be fixed immediately by anyone without another OS or
> machine.

Did you read this before posting. It's obvious that when a service is
failing, everybody first think it's because of the init process and try
to fix the bug in the /sbin/init C sources.

> 'silently failing', only if it's meant to.

A running software does exactly what was written from all the involved
sources.

What next?

--
Nicolas Sebrecht

On Tue, Jul 24, 2012 at 4:38 PM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> The 23/07/12, Kevin Chadwick wrote:
>
>> Did you read this before posting. It's obvious that reviewing the config
>> files and getting the source and finding the bug in C is much easier of
>> course and can be fixed immediately by anyone without another OS or
>> machine.
>
> Did you read this before posting. It's obvious that when a service is
> failing, everybody first think it's because of the init process and try
> to fix the bug in the /sbin/init C sources.

Its a common fallacy some seem to hold that the only way to
fix/debug/customize systemd is to edit the sources. Obviously those
who believe so have no idea what .service files are.

On Tue, 24 Jul 2012 04:54:08 +0200, Anthony 'Ishpeck' Tedjamulia
<archlinux@ishpeck.net> wrote:



On Mon, Jul 23, 2012 at 05:57:46PM +0200, Tom Gundersen wrote:

> Is debian switching

That remains to be seen.


If Debian intends to continue support for Hurd and
KfreeBSD they can't move to systemd -- which relies
on Linux kernel features to work.

That debian has a disincentive is not the same as
Arch having a disincentive, tho'.

I would rather we use DJB's daemontools as process 1
but I know exactly how these arguments tend to go.


http://wiki.debian.org/systemd#Installation
We talked about it on Debian mailing list, IICR Debian will switch, but I
might be mistaken.

- Ralf

> > 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.


You keep picking on other subjects too at one tiny part without
considering all that I have said.

/sbin/init 32K actually larger than I thought considering it's job was
designed so tightly bound.

/bin/systemd > 800K (26 times as large)

I have an embedded board sitting right here that can run Linux and has
64K of SRAM by default.

As I have said you are talking about Linux systems that are
nearer the top smaller end of the embedded and actually my Android
probably takes longer to boot than my desktop, maybe when I get time as
Sony aren't providing updates as they promised I will mod cyanogen
to boot a bit quicker or stop it slowing down further if systemd lands
with a simple init.


My real point was that the systemd speed argument was pointless and
the bloated argument in violation of UNIX principles wasn't. There is
nothing stopping building concurrency on top of init like Upstart which
obviously has major issues.

Do you have any numbers on how much time it saves you. I know Gnome
takes many many times longer to load than systemd saves!

--
__________________________________________________ ______

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

> For instance, (open)webOS (and probably android) has gone the upstart way.

Probably because it scales to the system.

--
__________________________________________________ ______

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

> 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.
>

init=/bin/sh

That happens a lot in embedded.

> > 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 .
>

That is completely debateable. I hope you look at counter arguments too.

I like what systemd does in code in the main. I just think it needs a
re-design to be more usable on the commandline and be more
modular so pid1 is small if it cannot stay as init.

> > 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.
>

Low memory embedded devices such as an mp3 player. I would also rather
desktop and embedded systems shared pid1 as a simple init like upstart
does.

> > 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?
>

Not really, it is used less on desktops because more code like Adobe
Flash breaks without intervention. My Arch desktops run grsecurity
kernels.

> Best regards,
> Karol Babioch
>



--
__________________________________________________ ______

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

> > Did you read this before posting. It's obvious that reviewing the config
> > files and getting the source and finding the bug in C is much easier of
> > course and can be fixed immediately by anyone without another OS or
> > machine.
>
> Did you read this before posting. It's obvious that when a service is
> failing, everybody first think it's because of the init process and try
> to fix the bug in the /sbin/init C sources.

It's funny how you think init which was designed to be as simple as
possible is likely to have as many bugs as systemd. You can batch test
a group of scripts quickly if you have to fall back to trial and error.
Cross platform peer reviewed scripts would be good of course.

--
__________________________________________________ ______

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

> >> Did you read this before posting. It's obvious that reviewing the config
> >> files and getting the source and finding the bug in C is much easier of
> >> course and can be fixed immediately by anyone without another OS or
> >> machine.
> >
> > Did you read this before posting. It's obvious that when a service is
> > failing, everybody first think it's because of the init process and try
> > to fix the bug in the /sbin/init C sources.
>
> Its a common fallacy some seem to hold that the only way to
> fix/debug/customize systemd is to edit the sources. Obviously those
> who believe so have no idea what .service files are.

I never said that, there is 800K of systemd to cause havoc that is
harder to test because it doesn't follow UNIX principles.

You would have to incorporate all code init can run in that. I like
some of systemd and an init consensus but it should have been developed
as many tools. Maybe systemds features were required to make this
happen and a init system with standardised scripts will finally come
along and fix this problem that has plagued Linux for so long.
Unfortunately it just might mean many will move back to Gentoo/Slackware
or another BSD like OS.

One of the founding principles of UNIX is that small tools that do
a single job well allow complete flexibility whereas large tools do
what the devs foresee very well but will likely hinder users or other
uses. That is a part of why I prefer sudo and RBAC/Selinux to polkit.
Maybe systemd doesn't hinder in this way but I'm sure it reduces re-use
of it's tools for other purposes and affects security that this
methodology has always brought.

I can't find the book referencing many highly regarded peers right now
to word it perfectly but Ironically this principle has been seen to
reduce UNIX use by the masses due to the potential for variation but
also means it has had technologies that never die out and especially
useful for the slightly skilled users. I didn't think Arch was trying
to be a Redhat for the masses.

--
__________________________________________________ ______

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

> For having used systemd myself, I am inclined to believe that it
> definitely fits the KISS principle.

I welcome the coss platform GUI for controlling services, however on
Arch rc.conf served very well.

I found I can see /etc/inittab and man inittab and edit.

With systemd I had to Google then type lots to Copy and symlink. It's
also harder to see what will run without booting said hardrive and the
output of systemctl makes it harder to see what services are enabled in
a single glance with all the other info provided but I'm sure that can
easily be fixed, though I didn't see the commandline argument required.


The main thing I would like to know is Will the DAEMONS line always
stay in rc.conf or will there be a single folder where we can see just
the service enabling files.

The KISS part I am mainly concerned about is the more complicated
nature of systemd that will innevitably lead to root exploits needlessly
on simple systems.

--
__________________________________________________ ______

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