Discussion:
Arch Linux and systemd
(too old to reply)
Myra Nelson
2012-08-16 21:22:56 UTC
Permalink
There has been much ado on the arch-general mailing list about the move to
systemd. I participated in part of it, but like others finally tired of
"seeing a dead horse kicked" over and over and over. So much so that the
last dev who really paid attention to the list said goodbye. Yet the free
for all continues. I think a comment on Allan's blog post might illustrate
how I perceive this situation.

Are We Removing What Defines Arch Linux?
Allan McRae posted to Arch Planet on August 13, 2012 03:59 PM

It's not about a single file, ie rc.conf (well not completely), it's about
the simplicity of the system.

Controversy #2 – The demise of /etc/rc.conf
While the single rc.conf is highlighted as major feature of Arch Linux,
reading the reviews makes you notice that configuration of an Arch install
was never down to a single file. Other files mentioned included…

But lets take a step back here… How about some quotes from Judd, the
founder of Arch Linux:
“In Arch “simple” is different what other distros are considering.
The learning is more important than getting something easily done.”
“Relying on GUIs to build/use your system is just going to hurt a
user in the end. At some point in time a user will need to know all that
some GUIs hide.”

My question becomes, are we trading the simplicity and ease of setting up a
single individuals computer, not corporate or work machine, or a set of two
or three home machines for the trappings of the corporate desktop? Are we
trading learning the shell (bash or otherwise) and learning to write bug
free shell scripts, for learning a set or arbitrary and possibly arcane
rules, decided upon in a building somewhere in the world, by someone who
knows how to use your computer better than you do? We've already seen the
likes of those already seen with polkit and consolekit. Even with udev
moving into systemd, an individual on the systemd mailing list has already
stated his desire to finally be rid of udev altogether. He considers it an
abomination. As to the standardization mentioned, does not such
standardization remove one's freedom? I'm not an RMS fan, so don't go
there. However, I am old enough to remember when there was no choice for
home computers, and a commercial by Apple for the first Mac using the idea
of breaking out of 1984 and the dull boring corporate world. Now here we
are moving the one OS that's stayed somewhat of a maverick into the stable,
then out to pasture to graze with with the rest of the corporate world. At
least IMHO. It's not about changing Arch, it's about becoming part of the
corporate structure and playing nice with everyone else. You can read that
line with the knowledge "Old hippies die hard. And I still don't trust the
establishment as far a I can throw my house!"

Interoperability is necessary in today's world, but I think it can be done
with out sacrificing the heart and soul of Linux. When it comes to the move
of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like
not being able to put /usr on a separate partition, I know there's a
mkinitcpio hook to cover that, but I can see the logic in cleaning up the
system. I've never really cared for the mess of the LSB. IMHO systemd is
for administrators who, unlike Judd Vinet, want to hide the system setup
from the user with fancy gui's and not allow anyone but the sysadmin to
make any changes.

I laud the devs who are working on this project, but I ask you to consider
"Is it better for Arch to lead one of the last bastion's of freedom when
using Linux into lock step with the the PTB's, or would it be better to
develop an alternative that keeps, not just Arch Linux, but Linux a viable
alternative to OSX, Windows, any Unix/BSD environment, and the corporate
world?" I know it's the simpler, and probably less stressfull solution, but
is it the better solution?

I firmly believe more discussions like this on the ml would be more
productive than the brawls we've seen lately. It also might provide the
dev's an opportunity to participate more instead of throwing their hands up
in the air and saying never again. To me the mailing list has become
reactive. Too many responses, I've been guilty of this, come from
predetermined ideas which may or may not be rooted in fact. They may be
rooted in the users experience which may have been affected by other
circumstances such as the dependency hell being created by the tighter and
tighter upstream integration by KDE and Gnome. This again signals the move
towards a "corporate desktop environment".

A wise unix guru, can't remember the name right now, said something to the
effect "the system should be a set of well written programs loosely
connected programs, each doing one thing and doing it well". Something many
of today's programs don't accomplish.

As I said on the arch-general mailing list. These are the battles that have
spawned many a linux distro and there is always LFS, even though they moved
to use udev inside systemd.

Myra Nelson

To those who I bcc'd this to;

I would like to humbly appologize if I intruded on your personal space, but
I wanted to make sure it would be read by you in your own private space
without the need to filter through the BS that's likely to occur on the ml.
--
Life's fun when your sick and psychotic!
Nicholas MIller
2012-08-16 21:34:48 UTC
Permalink
Post by Myra Nelson
There has been much ado on the arch-general mailing list about the move to
systemd. I participated in part of it, but like others finally tired of
"seeing a dead horse kicked" over and over and over. So much so that the
last dev who really paid attention to the list said goodbye. Yet the free
for all continues. I think a comment on Allan's blog post might illustrate
how I perceive this situation.
Are We Removing What Defines Arch Linux?
Allan McRae posted to Arch Planet on August 13, 2012 03:59 PM
It's not about a single file, ie rc.conf (well not completely), it's about
the simplicity of the system.
Controversy #2 – The demise of /etc/rc.conf
While the single rc.conf is highlighted as major feature of Arch Linux,
reading the reviews makes you notice that configuration of an Arch install
was never down to a single file. Other files mentioned included…
But lets take a step back here… How about some quotes from Judd, the
“In Arch “simple” is different what other distros are considering.
The learning is more important than getting something easily done.”
“Relying on GUIs to build/use your system is just going to hurt a
user in the end. At some point in time a user will need to know all that
some GUIs hide.”
My question becomes, are we trading the simplicity and ease of setting up a
single individuals computer, not corporate or work machine, or a set of two
or three home machines for the trappings of the corporate desktop? Are we
trading learning the shell (bash or otherwise) and learning to write bug
free shell scripts, for learning a set or arbitrary and possibly arcane
rules, decided upon in a building somewhere in the world, by someone who
knows how to use your computer better than you do? We've already seen the
likes of those already seen with polkit and consolekit. Even with udev
moving into systemd, an individual on the systemd mailing list has already
stated his desire to finally be rid of udev altogether. He considers it an
abomination. As to the standardization mentioned, does not such
standardization remove one's freedom? I'm not an RMS fan, so don't go
there. However, I am old enough to remember when there was no choice for
home computers, and a commercial by Apple for the first Mac using the idea
of breaking out of 1984 and the dull boring corporate world. Now here we
are moving the one OS that's stayed somewhat of a maverick into the stable,
then out to pasture to graze with with the rest of the corporate world. At
least IMHO. It's not about changing Arch, it's about becoming part of the
corporate structure and playing nice with everyone else. You can read that
line with the knowledge "Old hippies die hard. And I still don't trust the
establishment as far a I can throw my house!"
Interoperability is necessary in today's world, but I think it can be done
with out sacrificing the heart and soul of Linux. When it comes to the move
of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like
not being able to put /usr on a separate partition, I know there's a
mkinitcpio hook to cover that, but I can see the logic in cleaning up the
system. I've never really cared for the mess of the LSB. IMHO systemd is
for administrators who, unlike Judd Vinet, want to hide the system setup
from the user with fancy gui's and not allow anyone but the sysadmin to
make any changes.
I laud the devs who are working on this project, but I ask you to consider
"Is it better for Arch to lead one of the last bastion's of freedom when
using Linux into lock step with the the PTB's, or would it be better to
develop an alternative that keeps, not just Arch Linux, but Linux a viable
alternative to OSX, Windows, any Unix/BSD environment, and the corporate
world?" I know it's the simpler, and probably less stressfull solution, but
is it the better solution?
I firmly believe more discussions like this on the ml would be more
productive than the brawls we've seen lately. It also might provide the
dev's an opportunity to participate more instead of throwing their hands up
in the air and saying never again. To me the mailing list has become
reactive. Too many responses, I've been guilty of this, come from
predetermined ideas which may or may not be rooted in fact. They may be
rooted in the users experience which may have been affected by other
circumstances such as the dependency hell being created by the tighter and
tighter upstream integration by KDE and Gnome. This again signals the move
towards a "corporate desktop environment".
A wise unix guru, can't remember the name right now, said something to the
effect "the system should be a set of well written programs loosely
connected programs, each doing one thing and doing it well". Something many
of today's programs don't accomplish.
As I said on the arch-general mailing list. These are the battles that have
spawned many a linux distro and there is always LFS, even though they moved
to use udev inside systemd.
Myra Nelson
To those who I bcc'd this to;
I would like to humbly appologize if I intruded on your personal space, but
I wanted to make sure it would be read by you in your own private space
without the need to filter through the BS that's likely to occur on the ml.
--
Life's fun when your sick and psychotic!
That seems to be one of the more well thought out (not pro), responces to
systemd,
Myra Nelson
2012-08-16 22:09:58 UTC
Permalink
Post by Myra Nelson
Post by Myra Nelson
There has been much ado on the arch-general mailing list about the move
to
Post by Myra Nelson
systemd. I participated in part of it, but like others finally tired of
"seeing a dead horse kicked" over and over and over. So much so that the
last dev who really paid attention to the list said goodbye. Yet the free
for all continues. I think a comment on Allan's blog post might
illustrate
Post by Myra Nelson
how I perceive this situation.
Are We Removing What Defines Arch Linux?
Allan McRae posted to Arch Planet on August 13, 2012 03:59 PM
It's not about a single file, ie rc.conf (well not completely), it's
about
Post by Myra Nelson
the simplicity of the system.
Controversy #2 – The demise of /etc/rc.conf
While the single rc.conf is highlighted as major feature of Arch
Linux,
Post by Myra Nelson
reading the reviews makes you notice that configuration of an Arch
install
Post by Myra Nelson
was never down to a single file. Other files mentioned included…
But lets take a step back here… How about some quotes from Judd, the
“In Arch “simple” is different what other distros are
considering.
Post by Myra Nelson
The learning is more important than getting something easily done.”
“Relying on GUIs to build/use your system is just going to hurt a
user in the end. At some point in time a user will need to know all that
some GUIs hide.”
My question becomes, are we trading the simplicity and ease of setting
up a
Post by Myra Nelson
single individuals computer, not corporate or work machine, or a set of
two
Post by Myra Nelson
or three home machines for the trappings of the corporate desktop? Are we
trading learning the shell (bash or otherwise) and learning to write bug
free shell scripts, for learning a set or arbitrary and possibly arcane
rules, decided upon in a building somewhere in the world, by someone who
knows how to use your computer better than you do? We've already seen the
likes of those already seen with polkit and consolekit. Even with udev
moving into systemd, an individual on the systemd mailing list has
already
Post by Myra Nelson
stated his desire to finally be rid of udev altogether. He considers it
an
Post by Myra Nelson
abomination. As to the standardization mentioned, does not such
standardization remove one's freedom? I'm not an RMS fan, so don't go
there. However, I am old enough to remember when there was no choice for
home computers, and a commercial by Apple for the first Mac using the
idea
Post by Myra Nelson
of breaking out of 1984 and the dull boring corporate world. Now here we
are moving the one OS that's stayed somewhat of a maverick into the
stable,
Post by Myra Nelson
then out to pasture to graze with with the rest of the corporate world.
At
Post by Myra Nelson
least IMHO. It's not about changing Arch, it's about becoming part of the
corporate structure and playing nice with everyone else. You can read
that
Post by Myra Nelson
line with the knowledge "Old hippies die hard. And I still don't trust
the
Post by Myra Nelson
establishment as far a I can throw my house!"
Interoperability is necessary in today's world, but I think it can be
done
Post by Myra Nelson
with out sacrificing the heart and soul of Linux. When it comes to the
move
Post by Myra Nelson
of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't
like
Post by Myra Nelson
not being able to put /usr on a separate partition, I know there's a
mkinitcpio hook to cover that, but I can see the logic in cleaning up the
system. I've never really cared for the mess of the LSB. IMHO systemd is
for administrators who, unlike Judd Vinet, want to hide the system setup
from the user with fancy gui's and not allow anyone but the sysadmin to
make any changes.
I laud the devs who are working on this project, but I ask you to
consider
Post by Myra Nelson
"Is it better for Arch to lead one of the last bastion's of freedom when
using Linux into lock step with the the PTB's, or would it be better to
develop an alternative that keeps, not just Arch Linux, but Linux a
viable
Post by Myra Nelson
alternative to OSX, Windows, any Unix/BSD environment, and the corporate
world?" I know it's the simpler, and probably less stressfull solution,
but
Post by Myra Nelson
is it the better solution?
I firmly believe more discussions like this on the ml would be more
productive than the brawls we've seen lately. It also might provide the
dev's an opportunity to participate more instead of throwing their hands
up
Post by Myra Nelson
in the air and saying never again. To me the mailing list has become
reactive. Too many responses, I've been guilty of this, come from
predetermined ideas which may or may not be rooted in fact. They may be
rooted in the users experience which may have been affected by other
circumstances such as the dependency hell being created by the tighter
and
Post by Myra Nelson
tighter upstream integration by KDE and Gnome. This again signals the
move
Post by Myra Nelson
towards a "corporate desktop environment".
A wise unix guru, can't remember the name right now, said something to
the
Post by Myra Nelson
effect "the system should be a set of well written programs loosely
connected programs, each doing one thing and doing it well". Something
many
Post by Myra Nelson
of today's programs don't accomplish.
As I said on the arch-general mailing list. These are the battles that
have
Post by Myra Nelson
spawned many a linux distro and there is always LFS, even though they
moved
Post by Myra Nelson
to use udev inside systemd.
Myra Nelson
To those who I bcc'd this to;
I would like to humbly appologize if I intruded on your personal space,
but
Post by Myra Nelson
I wanted to make sure it would be read by you in your own private space
without the need to filter through the BS that's likely to occur on the
ml.
Post by Myra Nelson
--
Life's fun when your sick and psychotic!
That seems to be one of the more well thought out (not pro), responces to
systemd,
Thank you. My intent was to start an intelligent discussion. The rants and
raves are going no where. I'm not necessarily against systemd, just the
PTB's upstream dictating how Linux is and can be used. To me Linux is about
choice, unlike the OS I used for so many years. My other goal is to get the
devs involved to think about how to help the Arch community in general. If
Arch is what you make of it, don't take that choice away.

Yes, Tom, I've backed off a little. I've started reading the systemd
mailing list and although Arch likes to lead the way into the future, I'm
not sure systemd is the future any more than upstart, polkit, consolekit,
gnome3, kde4, ad nauseum. This last line may elicit the wrong responses,
but I hope not. It wasn't meant to slam any one particular idea. Just point
Simple things should be simple. Complex things should be possible.

Most software today is very much like an Egyptian pyramid with millions of
bricks piled on top of each other, with no structural integrity, but just
done by brute force and thousands of slaves.

We in the Linux community rest on the shoulders of giants all the way down
to Torvalds and GKH. We should act like it.

Myra
--
Life's fun when your sick and psychotic!
Rémy Oudompheng
2012-08-18 07:37:35 UTC
Permalink
Post by Myra Nelson
Post by Nicholas MIller
That seems to be one of the more well thought out (not pro), responces to
systemd,
Thank you. My intent was to start an intelligent discussion. The rants and
raves are going no where. I'm not necessarily against systemd, just the
PTB's upstream dictating how Linux is and can be used. To me Linux is about
choice, unlike the OS I used for so many years. My other goal is to get the
devs involved to think about how to help the Arch community in general. If
Arch is what you make of it, don't take that choice away.
The tools dictate how to use the system. Archlinux has never dictated
which tools to use, and the "move to systemd" is not more a dictation
about which tool to use than anything before. Arch is still what you
make of it, some tools just don't have alternatives and you are
welcome to develop one of them to help that choice.

Nobody is "removing an alternative" here, it's just cleaning up the
dead, the community is free to revive them.
I don't see how this discussion is different from the other ones. Most
of the discussions are based on the assumption that we currently have
working boot scripts in bash. This one is too.

Rémy.
Myra Nelson
2012-08-19 17:41:44 UTC
Permalink
On Sat, Aug 18, 2012 at 2:37 AM, Rémy Oudompheng
Post by Rémy Oudompheng
Post by Myra Nelson
Post by Nicholas MIller
That seems to be one of the more well thought out (not pro), responces
to
Post by Myra Nelson
Post by Nicholas MIller
systemd,
Thank you. My intent was to start an intelligent discussion. The rants
and
Post by Myra Nelson
raves are going no where. I'm not necessarily against systemd, just the
PTB's upstream dictating how Linux is and can be used. To me Linux is
about
Post by Myra Nelson
choice, unlike the OS I used for so many years. My other goal is to get
the
Post by Myra Nelson
devs involved to think about how to help the Arch community in general.
If
Post by Myra Nelson
Arch is what you make of it, don't take that choice away.
The tools dictate how to use the system. Archlinux has never dictated
which tools to use, and the "move to systemd" is not more a dictation
about which tool to use than anything before. Arch is still what you
make of it, some tools just don't have alternatives and you are
welcome to develop one of them to help that choice.
Nobody is "removing an alternative" here, it's just cleaning up the
dead, the community is free to revive them.
I don't see how this discussion is different from the other ones. Most
of the discussions are based on the assumption that we currently have
working boot scripts in bash. This one is too.
Rémy.
Remy:

Culling the herd never hurts and I'm not a firm believer that the current
bash scripts are perfect. My goal was to entice a lower tone, more
rational, not have to sort through all the bull shit conversations. As I
pointed out somewhere earlier, my brain doesn't process information the
same way most do and I get bore quickly sorting through the other posts for
real information. Hard data is true information, information equals power,
and distilled information is the best there is, but trying to sort through
the rants and raves it completely beyond me.

I have to map things out like logic gates:

If xyz then
blah blah
else if jkl
etc
end if

In other words, why oop still eludes me to this day. There are certain
transtions in my transitors that are broken and I need intelligent
responses like yours, Tom's, and the blog Allan posted to Planet Arch to
wend my way through things.

Sorry if I seemed to have caused offending and extra noise.

Myra
--
Life's fun when your sick and psychotic!
Geoff
2012-08-17 07:57:46 UTC
Permalink
On Thu, 16 Aug 2012 16:22:56 -0500
Myra Nelson <***@hughes.net> wrote:

<snip>

I agree. I have read all the current threads and the few words which struck me
with greatest force were in a post from Marti Raudsepp, where he said that an
advantage of systemd is "... less fragmentation between Linux distribution". I
have been full time on linux for nearly 13 years now, with the most recent five
of those on Arch, and for me one of the principal attractions of the OS has
always been fragmentation between distributions. The recent changes to Arch
(and I dare say other distros which I do not monitor), all seem to me to point
in the direction of drab ecumenism - eventually "One distro to rule them
all ...." Sooner or later Arch will be distinguished only by its excellent
rolling release model and the wonderful pacman. Perhaps all this was
inevitable. I do not intend anything I say as a criticism of the devs - it is
their distro and they are entitled to do what they choose with it. But it does
make me sad.

Geoff
C Anthony Risinger
2012-08-17 09:08:32 UTC
Permalink
Post by Geoff
On Thu, 16 Aug 2012 16:22:56 -0500
<snip>
I agree. I have read all the current threads and the few words which struck me
with greatest force were in a post from Marti Raudsepp, where he said that an
advantage of systemd is "... less fragmentation between Linux distribution". I
have been full time on linux for nearly 13 years now, with the most recent five
of those on Arch, and for me one of the principal attractions of the OS has
always been fragmentation between distributions. The recent changes to Arch
(and I dare say other distros which I do not monitor), all seem to me to point
in the direction of drab ecumenism - eventually "One distro to rule them
all ...." Sooner or later Arch will be distinguished only by its excellent
rolling release model and the wonderful pacman. Perhaps all this was
inevitable. I do not intend anything I say as a criticism of the devs - it is
their distro and they are entitled to do what they choose with it. But it does
make me sad.
the boot process isn't really that interesting (once you
know/understand it anyway ... if not i encourage you to explor ;-) --
every distro pretty much does it the same way, but pointlessly
independent, thus resulting in annoying differences that are
completely irrelevant to begin with.

no flexibility is lost by moving to systemd, and really, much more
gained: wider userbase, wider testbase, simple units to write, simple
units to read, loosely coupled ordering, implicit dependencies, Grand
Unified logging capabilities, and of course, much better
speed/reliability/robustness.

take the (unanimous?) sentiments exhibiting by our developers -- and
*many* developers elsewhere, in a great variety of capacities/niches
-- as a sign of the good things to come. i fully expect 99%+ will have
little trouble adjusting, and 98% will at that time agree it was
clearly the right choice.

initiatives like this are not removing choice -- they are
consolidating the common bits so developers can get back to writing
the interesting next-gen stuff instead of spinning wheels or putting
out fires.

like most things in life, balance is key to good health.
--
C Anthony
Fons Adriaensen
2012-08-17 09:57:51 UTC
Permalink
Post by C Anthony Risinger
no flexibility is lost by moving to systemd, and really, much more
gained: wider userbase, wider testbase, simple units to write, simple
units to read, loosely coupled ordering, implicit dependencies, Grand
Unified logging capabilities, and of course, much better
speed/reliability/robustness.
That is probably all true.

But there is one observation in Myra's post which I think is
very much to the point: the fact that 'upstream' (in this case
mainly Redhat), is driving Linux to become 'enterprise-friendly'.
This is also very visible if you read Lennart's blog.

There's in principle nothing wrong with that, unless the way
this is done means that it becomes more difficult for a user
to configure his system differently. Note that the aim in most
enterprises is to take control away from the end user, even if
he's sitting right besides the system. It is inevitable that
anything that enables this goes against the interest of the
individual user.

I'm pretty sure that much of the resistance to systemd (and
some other subsystems) exists because it is seen (and IMHO
not entirely in error) as part of a strategy in that direction.

And it certainly matters to Arch users who by definition are
their own admins, and who want the flexibility without having
to disable, bypass or fight things they don't need and that
get in the way. Having to do that with other distros was what
drove me to Arch.

All this also means that it is futile to attack L.P. personally
(as seems to happen) - he is just a clever and ambitious young
man used as a pawn in a game that is much bigger than he is.

Ciao,
--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Geoff
2012-08-17 10:10:20 UTC
Permalink
On Fri, 17 Aug 2012 09:57:51 +0000
Fons Adriaensen <***@linuxaudio.org> wrote:

<snip>

+1 to every word. I ran LFS for three years, partly because I wanted to learn
and partly to avoid the issues you mention. I left only because at that point in
my life it was too time-consuming and Arch offered an ideal alternative.

Geoff
Geoff
2012-08-17 10:18:09 UTC
Permalink
On Fri, 17 Aug 2012 04:08:32 -0500
C Anthony Risinger <***@xtfx.me> wrote:

<snip>
Post by C Anthony Risinger
the boot process isn't really that interesting (once you
know/understand it anyway ... if not i encourage you to explor ;-) --
every distro pretty much does it the same way, but pointlessly
independent, thus resulting in annoying differences that are
completely irrelevant to begin with.
Thank you for a measured reply Anthony. I take your points. I have also
watched LP's FOSDEM systemd presentation on Youtube (understanding about 80% of
it), and read most of the links provided by other posters (especially the
internal debate between Red Hat devs). I understand that there are advantages,
but I am left with the lingering impression that systemd is part of a larger
project, - as discussed by Fons Adriaensen in this thread. It bothers me.

Geoff
Rodrigo Rivas
2012-08-17 12:03:17 UTC
Permalink
Post by Geoff
On Fri, 17 Aug 2012 04:08:32 -0500
<snip>
Post by C Anthony Risinger
the boot process isn't really that interesting (once you
know/understand it anyway ... if not i encourage you to explor ;-) --
every distro pretty much does it the same way, but pointlessly
independent, thus resulting in annoying differences that are
completely irrelevant to begin with.
Thank you for a measured reply Anthony. I take your points. I have also
watched LP's FOSDEM systemd presentation on Youtube (understanding about 80% of
it), and read most of the links provided by other posters (especially the
internal debate between Red Hat devs). I understand that there are advantages,
but I am left with the lingering impression that systemd is part of a larger
project, - as discussed by Fons Adriaensen in this thread. It bothers me.
"Part of a larger project". Yes, I have the same feeling, but it doesn't
have to be necessarily a bad thing. That would depend, in part, on what the
larger project is. For example, upstart is part of a larger project
(Ubuntu), so is git (Linux). Hey, even GCC is part of a bigger project
(GNU).

Some people fear that if you use it you will be giving something to that
unknown project behind systemd.
But if it takes you where you don't want to go, it can be forked. It has
happened before with bigger projects.

That's the great thing of opensource, you don't have put up with the powers
behind: fork - improve - share.

But for the time being they didn't give me any reason to believe that they
have a hidden agenda or that they are evil, or anything...
--
Rodrigo
Kevin Chadwick
2012-08-17 13:23:55 UTC
Permalink
Post by Rodrigo Rivas
But if it takes you where you don't want to go, it can be forked. It has
happened before with bigger projects.
That's true but no one can do that on a whim and apparently (Redhat
Dev) the code is rediculously hard to follow and review. I believe the
ones who would do that will likely just start from scratch or use an
existing shell based init and are more likely to fork upstart as a
basis with systemd as a reference.
--
_______________________________________________________________________

'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)
_______________________________________________________________________
Geoff
2012-08-17 12:59:30 UTC
Permalink
On Fri, 17 Aug 2012 14:03:17 +0200
Rodrigo Rivas <***@gmail.com> wrote:

<snip>
Post by Rodrigo Rivas
Some people fear that if you use it you will be giving something to that
unknown project behind systemd.
But if it takes you where you don't want to go, it can be forked. It has
happened before with bigger projects.
<snip>

Yes, but I have the feeling (just my feeling, I can be wrong), that the
epoch when the best and brightest people did fork projects of this kind may be
past, or at least passing. I am not blaming anyone, - the constraints of time /
career are perhaps more difficult to contend with than they were 20 years
ago. Further, the success of linux in fields far removed from my
irrelevant little desktop brings opportunities and problems which may interest
those people more. Times change, but one is allowed to regret some of the
consequences.

Geoff
Anthony ''Ishpeck'' Tedjamulia
2012-08-17 12:22:12 UTC
Permalink
Post by C Anthony Risinger
initiatives like this are not removing choice
... Kinda.

This initiative doesn't remove choice. It is a natural consequence
of the greater linux ecosystem choosing to abandon some choices.

Am convinced that moving to systemd is probably the right thing for
Arch at this point. But let's not get overzealous in the proselyting.
Myra Nelson
2012-08-17 17:33:33 UTC
Permalink
Post by Geoff
Post by Geoff
On Thu, 16 Aug 2012 16:22:56 -0500
<snip>
I agree. I have read all the current threads and the few words which
struck me
Post by Geoff
with greatest force were in a post from Marti Raudsepp, where he said
that an
Post by Geoff
advantage of systemd is "... less fragmentation between Linux
distribution". I
Post by Geoff
have been full time on linux for nearly 13 years now, with the most
recent five
Post by Geoff
of those on Arch, and for me one of the principal attractions of the OS
has
Post by Geoff
always been fragmentation between distributions. The recent changes to
Arch
Post by Geoff
(and I dare say other distros which I do not monitor), all seem to me to
point
Post by Geoff
in the direction of drab ecumenism - eventually "One distro to rule them
all ...." Sooner or later Arch will be distinguished only by its
excellent
Post by Geoff
rolling release model and the wonderful pacman. Perhaps all this was
inevitable. I do not intend anything I say as a criticism of the devs -
it is
Post by Geoff
their distro and they are entitled to do what they choose with it. But
it does
Post by Geoff
make me sad.
the boot process isn't really that interesting (once you
know/understand it anyway ... if not i encourage you to explor ;-) --
every distro pretty much does it the same way, but pointlessly
independent, thus resulting in annoying differences that are
completely irrelevant to begin with.
no flexibility is lost by moving to systemd, and really, much more
gained: wider userbase, wider testbase, simple units to write, simple
units to read, loosely coupled ordering, implicit dependencies, Grand
Unified logging capabilities, and of course, much better
speed/reliability/robustness.
take the (unanimous?) sentiments exhibiting by our developers -- and
*many* developers elsewhere, in a great variety of capacities/niches
-- as a sign of the good things to come. i fully expect 99%+ will have
little trouble adjusting, and 98% will at that time agree it was
clearly the right choice.
initiatives like this are not removing choice -- they are
consolidating the common bits so developers can get back to writing
the interesting next-gen stuff instead of spinning wheels or putting
out fires.
like most things in life, balance is key to good health.
--
C Anthony
C. Anthony:

First let me apologize for you winding up with my post twice.

One thing that struck me from one of Tom's replies was "as a computer
scientist". Now my degree is in Geology and I didn't get to finish my MS in
Geophysics, not bragging just trying to set the stage for my discussion. My
programming skills started in the age of punch cards and fortran and I
skipped assembly.

I'm begining to see the disparity in this conversation. On one side we have
users and on the other side, so it seems, the devs are "computer
scientists" trying to bring the next generation to the world. A very worthy
and laudable effort. Please forgive the skeptic in me for saying, for some
of us this isn't our first rodeo and for some of us ( reads: I've been this
way for 60 years and it ain't gonna change any time soon) arguements put
forth about how simple things will become and how much better things will
be have been heard so many times with so little results, we have deaf ears.
The proof is always in the pudding and when that time comes, maybe, I'll
believe it.

The reason for differentiating between users and scientists was this. Too
many people in the world have come to distrust scientists. Just look at the
FUD that's come to this discussion. It's starting to remind me of an old
fashioned lynch mob. Now both sides have dug their feet in and refuse to
listen to each other. That was the point of my original post, to change the
discussion. To attempt to make the discussion meaningful. I would like to
take you to task on one point.
Post by Geoff
if not i encourage you to explor ;-) --
every distro pretty much does it the same way, but pointlessly
independent, thus resulting in annoying differences that are
completely irrelevant to begin with.
This may be accurate, it may be precise, it may make sense, but somewhere
someone thought it was the right way to do things. That does not, nor will
it ever, make it irrelevant. It's the beauty of using Linux. It's flexible,
one can make it work. I know first hand what happens when a scientist
attempts to make someone believe something is irrelevant and it ain't
pretty. It follows my version of Einstein's theory or relativity, "What's
relative to you may or may not be relative to me, or relative to me in the
same way".

I know all those involved are busy with their lives, school, work, etc, and
Arch users are supposed to be savvy enough to figure all this out on their
own. But consider this:

For example, you might feel in your gut that a particular design or
algorithm is the right way to go and that other suggestions aren’t as
effective. Great.

Now prove it.

It could be your expert intuition at work, or maybe it’s just a cognitive
bias or other bug. You need to get some feedback: create a prototype, run
some unit tests, and chart some benchmarks. Do what you need to do to prove
that your idea is a good one, because your intuition may have been wrong.
[94]

Feedback is the key to agile software development for precisely this
reason: software development depends on people. And as we’ve seen here,
people have bugs, too. In short, we’re all nuts—one way or another. Despite
our best intentions, we need to double-check ourselves and each other.

You need unit tests for yourself, too.
Testing Yourself

When you are dead solid convinced of something, ask yourself why. You’re
sure the boss is out to get you. How do you know? Everybody is using Java
for this kind of application. Says who? You’re a great/awful developer.
Compared to whom?

How do you know?

To help get a bigger picture perspective and test your understanding and
mental model, ask yourself something like the following questions:[95]

-

How do you know?
-

Says who?
-

How specifically?
-

How does what I’m doing cause you to...?
-

Compared to what or whom?
-

Does it always happen? Can you think of an exception?
-

What would happen if you did (or didn’t)?
-

What stops you from...?

Is there anything you can actually measure? Get hard numbers on? Any
statistics?[96] What happens when you talk this over with a colleague? How
about a colleague who has a very different viewpoint from your own? Do they
passively agree? Is that a danger sign? Do they violently oppose the idea?
Does that give it credibility? Or not?
From "Pragmatic Thinking and Learning" Refactor Your “Wetware”Andy HuntWe
all have inate hardware bugs and preceptions, and we all need to debug
ourselves.

Myra
--
Life's fun when your sick and psychotic!
Felipe Contreras
2012-08-21 23:52:01 UTC
Permalink
Post by C Anthony Risinger
no flexibility is lost by moving to systemd, and really, much more
gained: wider userbase, wider testbase, simple units to write, simple
units to read, loosely coupled ordering, implicit dependencies, Grand
Unified logging capabilities, and of course, much better
speed/reliability/robustness.
These are all unwarranted assumptions. I would like to see the
evidence for each one of these claims, and if you don't have hard
evidence at best these are *opinions*. I do have contrary evidence for
some of these, but I'm not claiming anything, you are, so you have the
burden of proof.
Post by C Anthony Risinger
take the (unanimous?) sentiments exhibiting by our developers -- and
*many* developers elsewhere, in a great variety of capacities/niches
-- as a sign of the good things to come. i fully expect 99%+ will have
little trouble adjusting, and 98% will at that time agree it was
clearly the right choice.
Maybe, maybe not, but is it the right choice *now*? That's the question.
Post by C Anthony Risinger
initiatives like this are not removing choice
Yes they are. I don't want to use systemd, what will be my choice?
--
Felipe Contreras
Leon Feng
2012-08-22 04:22:31 UTC
Permalink
Post by Felipe Contreras
Post by C Anthony Risinger
no flexibility is lost by moving to systemd, and really, much more
gained: wider userbase, wider testbase, simple units to write, simple
units to read, loosely coupled ordering, implicit dependencies, Grand
Unified logging capabilities, and of course, much better
speed/reliability/robustness.
These are all unwarranted assumptions. I would like to see the
evidence for each one of these claims, and if you don't have hard
evidence at best these are *opinions*. I do have contrary evidence for
some of these, but I'm not claiming anything, you are, so you have the
burden of proof.
Post by C Anthony Risinger
take the (unanimous?) sentiments exhibiting by our developers -- and
*many* developers elsewhere, in a great variety of capacities/niches
-- as a sign of the good things to come. i fully expect 99%+ will have
little trouble adjusting, and 98% will at that time agree it was
clearly the right choice.
Maybe, maybe not, but is it the right choice *now*? That's the question.
Some upstream package are start to require systemd support. Udev,
Polkit is just an example.
This is not Arch decision. It is the decision made by upstream. Arch
just follow the trend.
Add as the poll shows: More Arch users(80%) agree with upstream for this change.

There are indeed some corner cases that systemd not support. This is
exact the reason Arch should encourage users to try systemd out. If
there is indeed problem, they can just remove init= kernel parameter
and report it, wait for it been fixed.

If this step is not take, most essential package require systemd, Arch
users have to switch in short time.
There will be little time left to find and fix issue. This situation
is the worst and should be avoided.

Leon
Post by Felipe Contreras
Post by C Anthony Risinger
initiatives like this are not removing choice
Yes they are. I don't want to use systemd, what will be my choice?
--
Felipe Contreras
Felipe Contreras
2012-08-22 11:58:12 UTC
Permalink
Post by Leon Feng
Post by Felipe Contreras
Maybe, maybe not, but is it the right choice *now*? That's the question.
Some upstream package are start to require systemd support. Udev,
Polkit is just an example.
And I say this is extremely bad news. Make GTK+ depend on GNOME, and
guess what will happen: people will stop using GTK+ (or fork it). Make
PolicyKit depend on systemd and people will stop using it.

I for one look forward to alternatives to udev, systemd and Polkit
(and all the packages that depend on systemd).

And let's remember that not every Arch Linux user uses Polkit (right?).
Post by Leon Feng
This is not Arch decision. It is the decision made by upstream. Arch
just follow the trend.
Add as the poll shows: More Arch users(80%) agree with upstream for this change.
Yes, they agree with the change, but the poll doesn't ask *when* this
change should happen.
Post by Leon Feng
There are indeed some corner cases that systemd not support. This is
exact the reason Arch should encourage users to try systemd out. If
there is indeed problem, they can just remove init= kernel parameter
and report it, wait for it been fixed.
Yes, people should be trying systemd *now*, but what happens if in the
small percentage of users that are doing this you can already see
problems? This should hint that the move to make it the default should
be delayed for *later*.

Cheers.
--
Felipe Contreras
Jakob Herrmann
2012-08-22 14:46:39 UTC
Permalink
Hi,

\begin{quote{}
Add as the poll shows: More Arch users(80%) agree with upstream for
this change.
\end{quote}
Source?...And which poll? I don't remember that some has been opened.

Cheers,
Jakob
Andre Goree
2012-08-22 15:44:38 UTC
Permalink
Post by Jakob Herrmann
Hi,
\begin{quote{}
Add as the poll shows: More Arch users(80%) agree with upstream for this change.
\end{quote}
Source?...And which poll? I don't remember that some has been opened.
Cheers,
Jakob
It was a poll started by a member in another thread on this list (titled
"SystemD poll")

Here is the link:
http://www.easypolls.net/poll.html?p=502d2113e4b02c3adb09a939
--
Andre Goree
***@drenet.info
Leon Feng
2012-08-17 09:15:12 UTC
Permalink
Post by Geoff
On Thu, 16 Aug 2012 16:22:56 -0500
<snip>
I agree. I have read all the current threads and the few words which struck me
with greatest force were in a post from Marti Raudsepp, where he said that an
advantage of systemd is "... less fragmentation between Linux distribution". I
have been full time on linux for nearly 13 years now, with the most recent five
of those on Arch, and for me one of the principal attractions of the OS has
always been fragmentation between distributions. The recent changes to Arch
(and I dare say other distros which I do not monitor), all seem to me to point
in the direction of drab ecumenism - eventually "One distro to rule them
all ...." Sooner or later Arch will be distinguished only by its excellent
rolling release model and the wonderful pacman. Perhaps all this was
inevitable. I do not intend anything I say as a criticism of the devs - it is
their distro and they are entitled to do what they choose with it. But it does
make me sad.
Before Ubuntu start upstart, there is simply no choice but sysvinit.
No one complain it will end up to "One distro to rule them all ....".

Leon
Post by Geoff
Geoff
mike cloaked
2012-08-17 09:14:58 UTC
Permalink
Post by Myra Nelson
of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like
not being able to put /usr on a separate partition, I know there's a
mkinitcpio hook to cover that, but I can see the logic in cleaning up the
Thank you for a reasoned posting - one comment here about the issue of
/usr on a separate partition - if you put /usr on a separate partition
and then made a bind mount to / would that not work? I have not tried
it though!

I have been doing this for /home which is a directory /opt/home and
/opt is a separate partition - I then bind mount it to /home as a
directory in the root partition. It has never given a problem so I
wondered if the analogous technique might work for /usr too?

This is a side comment and I am not trying to subvert the main thread
discussion here.
--
mike c
Diep Pham Van
2012-08-17 09:28:21 UTC
Permalink
I used to have seperate /usr partition, previous year, I didn't remember details but
there was a bug that force me to reinstall my sytem without a sperate /usr partition.
Post by mike cloaked
Post by Myra Nelson
of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like
not being able to put /usr on a separate partition, I know there's a
mkinitcpio hook to cover that, but I can see the logic in cleaning up the
Thank you for a reasoned posting - one comment here about the issue of
/usr on a separate partition - if you put /usr on a separate partition
and then made a bind mount to / would that not work? I have not tried
it though!
I have been doing this for /home which is a directory /opt/home and
/opt is a separate partition - I then bind mount it to /home as a
directory in the root partition. It has never given a problem so I
wondered if the analogous technique might work for /usr too?
This is a side comment and I am not trying to subvert the main thread
discussion here.
--
mike c
mike cloaked
2012-08-17 19:07:20 UTC
Permalink
Post by mike cloaked
Post by Myra Nelson
of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like
not being able to put /usr on a separate partition, I know there's a
mkinitcpio hook to cover that, but I can see the logic in cleaning up the
Thank you for a reasoned posting - one comment here about the issue of
/usr on a separate partition - if you put /usr on a separate partition
and then made a bind mount to / would that not work? I have not tried
it though!
I have been doing this for /home which is a directory /opt/home and
/opt is a separate partition - I then bind mount it to /home as a
directory in the root partition. It has never given a problem so I
wondered if the analogous technique might work for /usr too?
Actually the answer to the /usr partition question seems to already be
in the arch wiki at
https://wiki.archlinux.org/index.php/Systemd#Arch_integration

"Warning: /usr must be mounted and available at bootup (this is not
particular to systemd). If your /usr is on a separate partition, you
will need to make accommodations to mount it from the initramfs and
unmount it from a pivoted root on shutdown. See the mkinitcpio wiki
page and freedesktop.org#separate-usr-is-broken"

https://wiki.archlinux.org/index.php/Mkinitcpio#.2Fusr_as_a_separate_partition
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

I should have read up on this before my previous post!
--
mike c
Kevin Chadwick
2012-08-18 01:09:17 UTC
Permalink
Post by mike cloaked
https://wiki.archlinux.org/index.php/Systemd#Arch_integration
"Warning: /usr must be mounted and available at bootup (this is not
particular to systemd). If your /usr is on a separate partition, you
will need to make accommodations to mount it from the initramfs and
unmount it from a pivoted root on shutdown. See the mkinitcpio wiki
page and freedesktop.org#separate-usr-is-broken"
https://wiki.archlinux.org/index.php/Mkinitcpio#.2Fusr_as_a_separate_partition
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
The link actually says this has nothing to do with systemd but I think
that's lies and the arch post is correct in that it's not just systemd.
Post by mike cloaked
I should have read up on this before my previous post!
Aside from most of the pro points being incorrect like actually
widening the difference between unixes (solaris being a minority), there
are things they have overlooked too.

_________________________________________________________________________

"we now just expect /usr to be pre-mounted from inside the initramfs, to
be available before 'init' starts"
_________________________________________________________________________


Well you used to execute /sbin/init and rc scripts after mounting /. so
what's the real reason that hasn't been bothered to be mentioned with
lennart pointing back to the thread that doesn't mention it.

Also Lennart says

_________________________________________________________________________

"Now you only have to pull out your rescue CD, if /boot is corrupted
and not if / is corrupted."
_________________________________________________________________________

Not true, you could always fix some errors but lots of things can not
be fixed this way else the kernel/initramfs would be or as large as the
filesystem which equates to more ignorance of busybox and embedded.

On OpenBSD the critical files are on / and so is the kernel. /usr holds
the well audited and so files that almost never need
updating. /usr/local holds packages so you can update them whilst
reducing the risk of trojaning login or damaging critical filesystems
for example. You can easily update and backup the root filesystem too.

/usr on Linux is far far more likely to have problems mounting as it
is large and heavily used so actually you have made Linux less reliable
not more reliable (as lennart argues) just like systemd does to. If it
has all these functional bugs that seem to still be appearing and is so
difficult to review the code then the only people that are likely to
find the security bugs are the criminals and those getting paid many
more times than Google pay for bugs in chrome not to mention that
those who can find those bugs will not be running and so auditing
systemd in any case.

The simplicity of controlling the init scripts was a major factor in my
choice of arch. The fast updates and simple and secure default stance
led me to believe Arch held security highly and which I no longer
believe. So as soon as my free time permits (which unfortunately may be
a while). I shall have to join Baho in his quest for another OS. The
decision to move to systemd actually has very little to do directly with
my decision but the manner of the decision process and unbalanced
summing up in arch is far more worrying and much more one sided than the
summary made by RedHat devs. There may be more developer contention and
balance than was dared to be made public, but it is unclear to me. A
couple of devs murmured dislike of systemd, a couple made rediculous
comments (not you Tom, you got hot headed and a little offensive at
times but I understood why) but most devs reacted to lets move to
systemd now for an easy life and an easy life has nothing to do with
what I strive to achieve.

Suggestion for distros without systemd and which hold security or code
correctness and little enabled by default are welcome.


Tom: Seccomp is only really there for a very particular usage by Google
in Chrome. It is far too large grained to add security to daemons.

Kc
--
_______________________________________________________________________

'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)
_______________________________________________________________________
mike cloaked
2012-08-17 09:31:49 UTC
Permalink
Post by Myra Nelson
There has been much ado on the arch-general mailing list about the move to
systemd. I participated in part of it, but like others finally tired of
"seeing a dead horse kicked" over and over and over. So much so that the
last dev who really paid attention to the list said goodbye. Yet the free
for all continues. I think a comment on Allan's blog post might illustrate
Here are some stats that are quite useful in terms of the number of
users of systemd:

At http://smolt.fedoraproject.org/static/stats/stats.html

Using the "kernel" tab we see that the approximate number of systems
that have their system details logged using Fedora 16 is over 100,000
if you total the entries for x86_64 and the i686 and i686 PAE kernels
most of which are systems using systemd. Given that so many machines
are currently running systemd it can't be all that bad! This is of
course only for Fedora but machines are also running systemd in other
distributions as well.

Speaks volumes really - and again supports the decision that the devs
have made - with a much larger user base than the straw poll made
available by another poster on this mailing list.
--
mike c
Thomas Rand
2012-08-17 09:47:27 UTC
Permalink
Post by mike cloaked
Post by Myra Nelson
There has been much ado on the arch-general mailing list about the move to
systemd. I participated in part of it, but like others finally tired of
"seeing a dead horse kicked" over and over and over. So much so that the
last dev who really paid attention to the list said goodbye. Yet the free
for all continues. I think a comment on Allan's blog post might illustrate
Here are some stats that are quite useful in terms of the number of
At http://smolt.fedoraproject.org/static/stats/stats.html
Using the "kernel" tab we see that the approximate number of systems
that have their system details logged using Fedora 16 is over 100,000
if you total the entries for x86_64 and the i686 and i686 PAE kernels
most of which are systems using systemd. Given that so many machines
are currently running systemd it can't be all that bad! This is of
course only for Fedora but machines are also running systemd in other
distributions as well.
Speaks volumes really - and again supports the decision that the devs
have made - with a much larger user base than the straw poll made
available by another poster on this mailing list.
--
mike c
Thank you for starting a thread that (crosses fingers) will stay rant
free & intelligent.

After reading all the who-har in the other's I decided to install
systemd on my lappy & TBH was very pleased with the result. That being
that the install itself was hassle free & the configuration was
bizarrely intuitive & easy, I had a small issue that
lightdm-unity-greeter was not starting, so I made a note of the error
given & checked the .service, .device, .target files & was astounded
to see seriously plain text to the point where I followed through the
process systemd took & worked out the problem reboot & bingo I fixed
it without even looking on the web!

I still have sysVinit installed & will begin cloning the system prior
to removing sysVinit, one point is that my Arch-laptop has one
partition for the whole OS but when i come to try this on my desktop I
will be facing lots of different drives & partitions which I feel may
also be relatively easy to resolve & get working.

Either way I think I have the same feeling on this as other Archers,
that being that we came to arch to live on the OS edge & take
advantage of what is new in the linux world whilst trying to stick
with the KISS principle. I think systemd is a step forward but the
truth will be in the pudding.

Again thanks for a sane thread :)
--
Regards
Thomas Rand
Stephen E. Baker
2012-08-17 12:34:44 UTC
Permalink
Post by Thomas Rand
Thank you for starting a thread that (crosses fingers) will stay rant
free & intelligent.
After reading all the who-har in the other's I decided to install
systemd on my lappy & TBH was very pleased with the result. That being
that the install itself was hassle free & the configuration was
bizarrely intuitive & easy, I had a small issue that
lightdm-unity-greeter was not starting, so I made a note of the error
given & checked the .service, .device, .target files & was astounded
to see seriously plain text to the point where I followed through the
process systemd took & worked out the problem reboot & bingo I fixed
it without even looking on the web!
I also decided I should install systemd on my laptop last night. (At a
time when
I didn't actually have much time to work on it, because that's the kind of
guy I am ;) ). I agree that the install itself was very easy, and with
the recent
rc.conf changes there was very little else to configure except to setup the
starting services.

I did hit a couple issues: Arch doesn't ship with units for all the daemons
I use. I was able to copy the mysqld instructions out of the wiki, but
my attempt at getting timidity working on my own failed. (Again,
I suspect I will be able to get it working, but I was doing things quickly.)

The other issue I hit was that it didn't like one of my fstab entries,
for a loop back file system in my home partition that I use to fake
a small drive for one of my old wine games. This error caused it to
boot to a
root console where I could see the file system in error. I haven't yet
tried to
debug the line, but once I commented it out I was able to boot my system.

Stephen E. Baker

[snip]
Post by Thomas Rand
Again thanks for a sane thread :)
+1
Stephen E. Baker
2012-08-20 12:29:48 UTC
Permalink
Post by Stephen E. Baker
The other issue I hit was that it didn't like one of my fstab entries,
for a loop back file system in my home partition that I use to fake
a small drive for one of my old wine games. This error caused it to
boot to a
root console where I could see the file system in error. I haven't
yet tried to
debug the line, but once I commented it out I was able to boot my system.
Some people have been replying off list with suggestions. With some help
on #systemd I added x-systemd.automount to the options on the fstab and
now that file system is working fine.

I've now removed initscripts and sysvinit and everything is working nicely.
I'm not convinced for me that there was much real advantage to the move,
but there doesn't seem to be any disadvantage either.

Stephen E. Baker
Jorge Almeida
2012-08-17 09:48:58 UTC
Permalink
Post by mike cloaked
most of which are systems using systemd. Given that so many machines
are currently running systemd it can't be all that bad! This is of
How many machines are currently running Windows*?

Jorge Almeida
Leon Feng
2012-08-17 09:51:49 UTC
Permalink
Post by mike cloaked
Post by Myra Nelson
There has been much ado on the arch-general mailing list about the move to
systemd. I participated in part of it, but like others finally tired of
"seeing a dead horse kicked" over and over and over. So much so that the
last dev who really paid attention to the list said goodbye. Yet the free
for all continues. I think a comment on Allan's blog post might illustrate
Here are some stats that are quite useful in terms of the number of
At http://smolt.fedoraproject.org/static/stats/stats.html
Using the "kernel" tab we see that the approximate number of systems
that have their system details logged using Fedora 16 is over 100,000
if you total the entries for x86_64 and the i686 and i686 PAE kernels
most of which are systems using systemd. Given that so many machines
are currently running systemd it can't be all that bad! This is of
course only for Fedora but machines are also running systemd in other
distributions as well.
Speaks volumes really - and again supports the decision that the devs
have made - with a much larger user base than the straw poll made
available by another poster on this mailing list.
Maybe there are some misunderstanding to be clear:

Even if Arch support systemd as default, it does not means all Arch
users are force to use systemd. Users prefer current initscripts can
still use it. It is just like the choice between Grub/Grub2/syslinux.

Leon.
Post by mike cloaked
--
mike c
Kyle
2012-08-17 21:13:20 UTC
Permalink
I made the move to systemd on my flash drive install 2 days ago, and I
have to say I am impressed. The only extra thing I needed to do was to
write a unit file for espeakup, since there isn't yet a unit in the
package or in systemd-arch-units. Writing the new .service file was
extremely quick and painless, and worked the very first time I rebooted
after enabling it. I didn't think it would be possible to make a very
old computer with USB 1.1 boot or shutdown any faster, but systemd
certainly made it happen with a minimum amount of effort, and everything
works as well or better than it did before the migration. I also like
the ease of use and configuration of systemd units and the intuitive
layout of the files and directories. I also found the systemctl and
journalctl commands to be very intuitive and easy to use. I only have to
remember to include the .service suffix when enabling or disabling a
service, as this process requires the complete unit name rather than
just the name of the service, unlike starting, stopping, etc. Although
there is always room for improvement in any software, systemd has come
quite a long way in a relatively short amount of time, and continues to
improve quickly. I would like to thank the systemd developers for their
hard work, and the Arch developers for seeing systemd as a viable
alternative to sysvinit and other aging and/or fragmented parts of a
Linux system. Add me to the list of happy systemd users.
~Kyle
Leon Feng
2012-08-18 02:40:17 UTC
Permalink
I made the move to systemd on my flash drive install 2 days ago, and I have
to say I am impressed. The only extra thing I needed to do was to write a
unit file for espeakup, since there isn't yet a unit in the package or in
systemd-arch-units. Writing the new .service file was extremely quick and
painless, and worked the very first time I rebooted after enabling it. I
didn't think it would be possible to make a very old computer with USB 1.1
boot or shutdown any faster, but systemd certainly made it happen with a
minimum amount of effort, and everything works as well or better than it did
before the migration. I also like the ease of use and configuration of
systemd units and the intuitive layout of the files and directories. I also
found the systemctl and journalctl commands to be very intuitive and easy to
use. I only have to remember to include the .service suffix when enabling or
disabling a service, as this process requires the complete unit name rather
than just the name of the service, unlike starting, stopping, etc. Although
there is always room for improvement in any software, systemd has come quite
a long way in a relatively short amount of time, and continues to improve
quickly. I would like to thank the systemd developers for their hard work,
and the Arch developers for seeing systemd as a viable alternative to
sysvinit and other aging and/or fragmented parts of a Linux system. Add me
to the list of happy systemd users.
Systemd support shortform service name now. See the wiki page:
https://wiki.archlinux.org/index.php/Systemd#Using_Units
~Kyle
Kyle
2012-08-18 02:06:16 UTC
Permalink
Post by Leon Feng
https://wiki.archlinux.org/index.php/Systemd#Using_Units
For now, this only seems to work for starting, stopping and reloading
services. Unfortunately it doesn't yet seem to work for enabling or
disabling them. If I try for example

sudo systemctl enable ***@Kyle

or

sudo systemctl disable ***@Kyle

I receive the following error:

Failed to issue method call: Invalid argument

If I use the .service suffix, it works as expected.

sudo systemctl start ***@Kyle

and

systemctl stop ***@Kyle

also work as expected. Maybe it's a bug, but for now, I'll just remember
the .service suffix unless I find out this behaviour is indeed abnormal.
Thanks for the link. The wiki page is well written and helped prevent
some potentially major headaches.
~Kyle
mike cloaked
2012-08-17 13:37:32 UTC
Permalink
Post by Jorge Almeida
Post by mike cloaked
most of which are systems using systemd. Given that so many machines
are currently running systemd it can't be all that bad! This is of
How many machines are currently running Windows*?
Surely that is not particularly relevant - Windows users are largely
people who are not computer literate (though some fraction of Windows
users are able to do some real hacking but not too many as a fraction
of the total). They are users who got Windows as "the" system when
they bought their laptops/desktops, and are none the wiser that any
alternative exists - on the other hand the majority of linux users are
computer literate, hands-on, people who know that they have choices -
and if they are using a particular flavour of linux and find they
don't like it then they have the knowledge and power to change it and
move to a different distribution - so the majority of Windows users
who find problems will seek a Windows guru to fix their machine ( or
re-install it from scratch, clean up the registry, run "defrag" and
other tools to try and get working until Microsoft eventually delivers
the next great version of Windows ). On the other hand linux users if
they "really" don't like what they see will change their system - if
they don't like Gnome they can use KDE, LXDE, XFCE etc - and if they
are Fedora users and "really" don't like systemd then they can move to
another distribution where systemd is not the default - they have
alternatives -

So logic would suggest that the inferences drawn from large numbers of
linux users is likely to be different from the inference about even
larger numbers of Windows users.
--
mike c
Felipe Contreras
2012-08-21 23:56:22 UTC
Permalink
Even with udev moving into systemd, an individual on the systemd mailing list
has already stated his desire to finally be rid of udev altogether. He considers it an
abomination.
Who is this member? It seems I joined late to the party. I also
dislike udev, and I think I can replace it with something much, *much*
simpler. Similarly with systemd.

Just like pacman is something non-standard maintained by Arch Linux
developers, perhaps we can replace the udev-systemd abomination with
something else, giving people a *choice*.
--
Felipe Contreras
Sven-Hendrik Haase
2012-08-22 00:15:23 UTC
Permalink
Post by Felipe Contreras
Even with udev moving into systemd, an individual on the systemd mailing list
has already stated his desire to finally be rid of udev altogether. He considers it an
abomination.
Who is this member? It seems I joined late to the party. I also
dislike udev, and I think I can replace it with something much, *much*
simpler. Similarly with systemd.
Just like pacman is something non-standard maintained by Arch Linux
developers, perhaps we can replace the udev-systemd abomination with
something else, giving people a *choice*.
Well, then why don't you go ahead and come back with some software that
is better and simpler?
Oon-Ee Ng
2012-08-22 00:30:48 UTC
Permalink
On Wed, Aug 22, 2012 at 7:56 AM, Felipe Contreras
Post by Felipe Contreras
Even with udev moving into systemd, an individual on the systemd mailing list
has already stated his desire to finally be rid of udev altogether. He considers it an
abomination.
Who is this member? It seems I joined late to the party. I also
dislike udev, and I think I can replace it with something much, *much*
simpler. Similarly with systemd.
Just like pacman is something non-standard maintained by Arch Linux
developers, perhaps we can replace the udev-systemd abomination with
something else, giving people a *choice*.
Not sure why you use 'we' here, considering you've repeatedly
disparaged the Arch devs and Arch community, saying "you are breaking
things" and all that rot.

Code talks. Get coding.
Felipe Contreras
2012-08-22 00:54:10 UTC
Permalink
Post by Oon-Ee Ng
On Wed, Aug 22, 2012 at 7:56 AM, Felipe Contreras
Post by Felipe Contreras
Even with udev moving into systemd, an individual on the systemd mailing list
has already stated his desire to finally be rid of udev altogether. He considers it an
abomination.
Who is this member? It seems I joined late to the party. I also
dislike udev, and I think I can replace it with something much, *much*
simpler. Similarly with systemd.
Just like pacman is something non-standard maintained by Arch Linux
developers, perhaps we can replace the udev-systemd abomination with
something else, giving people a *choice*.
Not sure why you use 'we' here, considering you've repeatedly
disparaged the Arch devs and Arch community, saying "you are breaking
things" and all that rot.
"We", is me and the people that don't like the systemd+udev beast, and
they are a lot.

And what's the point of being belligerent towards me? What could
possibly be the purpose of your comment if not attack me personally.

And no, I didn't disparage anyone.

And no, I didn't say anything like "you are breaking things" at all.
It seems you are simply unable to understand what I am saying.

Cheers.
--
Felipe Contreras
Kwpolska
2012-08-22 08:13:33 UTC
Permalink
On Wed, Aug 22, 2012 at 2:54 AM, Felipe Contreras
Post by Felipe Contreras
"We", is me and the people that don't like the systemd+udev beast, and
they are a lot.
Huh? I've never seen any complaints about udev before you. Mind you,
udev is around since 2003. It was merged into systemd's source, but
it's not a problem to use it without running systemd. Otherwise your
system won't run, don't you think? Udev provides /dev after all...
Wikipedia says you can use something else, but libudev itself is in
use.
--
Kwpolska <http://kwpolska.tk>
stop html mail | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
GPG KEY: 5EAAEA16
Kevin Chadwick
2012-08-22 08:58:34 UTC
Permalink
Post by Kwpolska
Post by Felipe Contreras
"We", is me and the people that don't like the systemd+udev beast, and
they are a lot.
Huh? I've never seen any complaints about udev before you. Mind you,
udev is around since 2003.
Actually it's completely different to back in 2003 because of huge
amounts of complaints. Check lwn.net
Post by Kwpolska
It was merged into systemd's source, but
it's not a problem to use it without running systemd. Otherwise your
system won't run, don't you think? Udev provides /dev after all...
Wikipedia says you can use something else, but libudev itself is in
use.
Where's the link, does it mean for dynamic /dev otherwise that's
completely wrong and libudev != udev/systemd.
--
_______________________________________________________________________

'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)
_______________________________________________________________________
Guus Snijders
2012-08-22 10:16:07 UTC
Permalink
Post by Kevin Chadwick
Post by Kwpolska
Post by Felipe Contreras
"We", is me and the people that don't like the systemd+udev beast, and
they are a lot.
Huh? I've never seen any complaints about udev before you. Mind you,
udev is around since 2003.
Actually it's completely different to back in 2003 because of huge
amounts of complaints. Check lwn.net
Post by Kwpolska
It was merged into systemd's source, but
it's not a problem to use it without running systemd. Otherwise your
system won't run, don't you think? Udev provides /dev after all...
Wikipedia says you can use something else, but libudev itself is in
use.
Where's the link, does it mean for dynamic /dev otherwise that's
completely wrong and libudev != udev/systemd.
Kevin, you seem to be fairly advanced user. How about creating a vm with
Arch and getting an alternative to udev running?
Should be an interesting experiment.
Same goes for (for example) openrc.

When it's working reliable for you, it should be easy enough to create some
packages.

In the case of init scripts, a very nice add-on would be to parse systemd's
ini files (either 'live' or once). That way it would be a very easy
transition for users already running systemd.

For the record: this is meant as an encouragement. I would be very
interested in things like this and be willing to help out.
Perhaps more people on this list feel the same way.

mvg, Guus
Kevin Chadwick
2012-08-22 10:38:23 UTC
Permalink
Post by Guus Snijders
Kevin, you seem to be fairly advanced user. How about creating a vm with
Arch and getting an alternative to udev running?
Seems is probably the right word. We are all fools fiddling in the dark
to some degree with different ground covered. Some of us have more
powerful torches and some keep to the lit roads more ;-)

You might find this hard to believe and maybe arch wasn't the
best choice (but not too bad so far) but a large reason of coming to
Arch was to reduce my time spent on admin and not increase it and I
can't afford any time at the moment. I don't really have an issue with
udev, it breaks little and is perfectly replaceable. Build time will
increase now but more options will become more prominent or it will fork
if it isn't suitably maintained. The kernel is unlikely to break
anything :-) on purpose or for a long time atleast.
--
_______________________________________________________________________

'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)
_______________________________________________________________________
Felipe Contreras
2012-08-22 12:06:50 UTC
Permalink
Post by Guus Snijders
Kevin, you seem to be fairly advanced user. How about creating a vm with
Arch and getting an alternative to udev running?
I do this all the time with buildroot; udev is a choice, and I often
have trouble compiling it because it depends on so many things, like
specific kernel configurations, and certain toolchain options. The
fact of the matter is that udev doesn't do much for me,
CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y does most of the job,
the rest is loading the right modules at boot time, which can be done
with a simple script. There's also mdev from busybox, but it's too
simple, I don't really understand what is the point of it.

But there's certainly people that don't use udev at all:
http://wiki.gentoo.org/wiki/Mdev

Cheers.
--
Felipe Contreras
Guus Snijders
2012-08-22 20:12:58 UTC
Permalink
Post by Felipe Contreras
Post by Guus Snijders
How about creating a vm with
Arch and getting an alternative to udev running?
I do this all the time with buildroot; udev is a choice, and I often
have trouble compiling it because it depends on so many things, like
specific kernel configurations, and certain toolchain options. The
fact of the matter is that udev doesn't do much for me,
CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y does most of the job,
the rest is loading the right modules at boot time, which can be done
with a simple script. There's also mdev from busybox, but it's too
simple, I don't really understand what is the point of it.
Looks like i need to do some catching up ;-). Udev has worked fine for me,
so my interest is mostly academic.

Just in case, it's always good to learn about alternatives.

Thanks.
mvg, Guus
Kevin Chadwick
2012-08-22 22:07:02 UTC
Permalink
Post by Guus Snijders
Post by Felipe Contreras
I do this all the time with buildroot; udev is a choice, and I often
have trouble compiling it because it depends on so many things, like
specific kernel configurations, and certain toolchain options. The
fact of the matter is that udev doesn't do much for me,
CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y does most of the job,
the rest is loading the right modules at boot time, which can be done
with a simple script. There's also mdev from busybox, but it's too
simple, I don't really understand what is the point of it.
Looks like i need to do some catching up ;-).
Udev used to do a lot more but a lot of it's functionality was taken
into the kernel for a more sane design and after much constructive
flaming ;-). It's on lwn.net.
--
_______________________________________________________________________

'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)
_______________________________________________________________________
atilla ontas
2012-08-23 10:10:12 UTC
Permalink
I think these discussions will not change the result for Arch. Sooner
or later Arch will have to seperate its way from its KISS philosophy.
While the main approach of Arch is to use vanilla software, as
possible; Arch devs have to follow upstream decisions and at some
point Arch and other distros fall into software those hide things from
end users. I think most of the main upstream software (take systemd,
KDE, GNOME and others) trying to be corporate software. Not all
upstream decisions are good but we have to follow them. My two
cents...
Kevin Chadwick
2012-08-23 11:12:05 UTC
Permalink
Post by atilla ontas
trying to be corporate software.
I've been wondering what the best term for 'corporate' or 'enterprise'
software like exchange is where they change your nappies for you but
also offer you razor wire to hang yourself with by giving you IE to
browse the web on the mail server itself and encouraging compulsory
remote wipe for clients!

"http://www.h-online.com/security/news/item/iCloud-attack-began-with-Amazon-hack-1661646.html"

Especially when these features are so ineffective that they do nothing
but cost you money.

http://www.wired.com/gadgetlab/2012/08/mat-honan-data-recovery/all/
--
_______________________________________________________________________

'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)
_______________________________________________________________________
Anthony ''Ishpeck'' Tedjamulia
2012-08-25 02:38:25 UTC
Permalink
Post by Kevin Chadwick
I've been wondering what the best term for 'corporate' or 'enterprise'
software like exchange is where they change your nappies for you but
also offer you razor wire to hang yourself with by giving you IE to
browse the web on the mail server itself and encouraging compulsory
remote wipe for clients!
I've always just called it "commoditized software" when I'm not
surging with invective and use the term "infantile computing BS"
Jakob Herrmann
2012-08-23 14:45:34 UTC
Permalink
\begin{quote}
While the main approach of Arch is to use vanilla software, as
possible; Arch devs have to follow upstream decisions and at some
point Arch and other distros fall into software those hide things from
end users. I think most of the main upstream software (take systemd,
KDE, GNOME and others) trying to be corporate software. Not all
upstream decisions are good but we have to follow them. My two
cents...
\end{quote}
So which components (obviously used by the majority of Arch users) do
currently have or will soon have hardcoded! dependencies to systemd?
As far as i can say, Gnome doesn't and if it will, there is still the
possibility for everyone to either patch it, to install it along with
systemd or just to use an alternative. Folks always confront me with
the argument of more and more hardcoded dependencies, but I can't find
them and am still happy without systemd (besides the udev thing which
in fact isn't such a thing).

Cheers,
Jakob
Anthony ''Ishpeck'' Tedjamulia
2012-08-25 02:41:55 UTC
Permalink
Post by Jakob Herrmann
So which components (obviously used by the majority of Arch users) do
currently have or will soon have hardcoded! dependencies to systemd?
udev.

Upstream, Gnome has considered it.
Kevin Chadwick
2012-08-28 10:16:38 UTC
Permalink
Post by Anthony ''Ishpeck'' Tedjamulia
Post by Jakob Herrmann
So which components (obviously used by the majority of Arch users) do
currently have or will soon have hardcoded! dependencies to systemd?
udev.
Upstream, Gnome has considered it.
You know why, because according to heise some of their longterm devs
have left leaving more than half the devs being RedHat employees.

p.s. I have nothing against RedHat, I value they're work, mostly the
work which goes unnoticed. Unfortunately the most prominent of they're
work gets a bad rep or is it more prominent because of the rep?
I think both because it often has a bad user experience and
interaction factor.
--
_______________________________________________________________________

'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)
_______________________________________________________________________
Jayesh Badwaik
2012-08-28 11:13:26 UTC
Permalink
Post by Kevin Chadwick
You know why, because according to heise some of their longterm devs
have left leaving more than half the devs being RedHat employees.
p.s. I have nothing against RedHat, I value they're work, mostly the
work which goes unnoticed. Unfortunately the most prominent of they're
work gets a bad rep or is it more prominent because of the rep? I
think both because it often has a bad user experience and
interaction factor.
In this context, I had shared a link where systemd devs had suggested
gnome devs to consider adding systemd as a dependency due to some
funcitonality which was present in systemd only. [1]

What is going on I am not sure, but this shows that GNOME in future is
going to have a hard dependency on systemd.
--
Cheers and Regards
Jayesh Badwaik
stop html mail | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html

[1] https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html
Ralf Mardorf
2012-08-28 11:30:55 UTC
Permalink
Post by Kevin Chadwick
Post by Kevin Chadwick
You know why, because according to heise some of their longterm devs
have left leaving more than half the devs being RedHat employees.
p.s. I have nothing against RedHat, I value they're work, mostly the
work which goes unnoticed. Unfortunately the most prominent of
they're
Post by Kevin Chadwick
work gets a bad rep or is it more prominent because of the rep? I
think both because it often has a bad user experience and
interaction factor.
In this context, I had shared a link where systemd devs had suggested
gnome devs to consider adding systemd as a dependency due to some
funcitonality which was present in systemd only. [1]
What is going on I am not sure, but this shows that GNOME in future is
going to have a hard dependency on systemd.
[1]
https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html
If somebody doesn't want to use systemd, IMO it's easy to quit GNOME. I
don't think that gcalctool and other small apps will have a dependency
chain, as well as GTK. Or could it become that extreme? Sorry for the
noob question, Ralf

Anthony ''Ishpeck'' Tedjamulia
2012-08-25 02:16:19 UTC
Permalink
Post by Kwpolska
Huh? I've never seen any complaints about udev before you.
udev is kinda crufty. And it really doesn't belong inside
the same monolithic program that manages startup and file-
system mounting.
Myra Nelson
2012-08-22 05:14:05 UTC
Permalink
On Tue, Aug 21, 2012 at 6:56 PM, Felipe Contreras
Post by Felipe Contreras
Even with udev moving into systemd, an individual on the systemd mailing list
has already stated his desire to finally be rid of udev altogether. He considers it an
abomination.
Who is this member? It seems I joined late to the party. I also
dislike udev, and I think I can replace it with something much, *much*
simpler. Similarly with systemd.
Just like pacman is something non-standard maintained by Arch Linux
developers, perhaps we can replace the udev-systemd abomination with
something else, giving people a *choice*.
--
Felipe Contreras
I've been in the conversation for a while. I just don't bother with
the threads with all the BikeShed on them, that's why I'm the OP. The
reason you have run across my posts is I don't post them to threads
you are in. Way too much noise. As others have stated and I will
reiterate, if you think Arch has so many non-standard packages find a
distro to your liking, or come up with something better. I believe the
proper terminology in my part of the world is "fish or cut bait".

FYI, Lennart does not want to be rid of systemd completely, that was
my error. He wants it completely absorbed into systemd.

So please be polite and don't hijack another thread like you have so
many others.

Myra Nelson
--
Life's fun when your sick and psychotic!
Continue reading on narkive:
Loading...