subject:"Installing an Alternative Init\?"

On Mon, Nov 17, 2014 at 06:29:24PM +0300, Reco wrote:
  Hi.
 
 On Sun, Nov 16, 2014 at 03:48:34PM +0100, Ludovic Meyer wrote:
  On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote:
   As much as I dislike systemd, I'm not sure that it's a vendor
   conspiracy to control the Linux ecosystem.  Yes, redhat pays
   Lennart Poettering's salary (among others).  But... I'm hard pressed
   to see how turning a collection of free distros into functional
   equivalent's of redhat, or increasing the resources applied to free
   distros, is really to their benefit.  If anything, it would seem to
   dilute the competitive advantage of paid RHEL.
   
   Personally, I think it's more a matter of one, prima donna
   developer, who has the advantage of a salary, who has a vision and
   design philosophy that he's promoting in a very aggressive and
   single minded way.  And he's very overt about it.  (Somebody posted
   an email from Poettering last week saying, roughly, 'first we're
   going to get kdbus into the kernel, then we're going to make udev
   depend on it, and then everyone will have to eat systemd to get
   udev.'  As I recall, the message closed with 'gentoo, be warned.')
   
   I figure this is more a case of redhat management not wanting to
   tick off valued prima donna, and maybe seeing what he's doing as a
   contribution to the open source community (to date, redhat has been
   pretty good about contributing to the community in lots of different
   ways).  Still,  if I were in their shoes, I'd be trying to reign the
   guys in. 
  
  Why would the management of a external company care about what 
  happen in Debian ? 
 
 Because Debian is upstream for several critical RHEL parts, such as
 shadow (passwd, useradd and friends).

1 ( ie shadow-utils ) is not several.
And by having a critical look at your affirmation, RH is paying a lot 
of upstreams contributors for several critical Debian part :
- glibc
- gcc
- util-linux-ng
- kernel
- udevd

to name a few. I could name a few non critical stuff, from gnome, openjdk.
So I am not sure that your point is valid. Given the size of Redhat, 
I also suspect that having someone working on shadow-utils wouldn't be a 
problem. Judging by 
SEC fillings, public information, there is around 6900 people. 1 more coder is
not a stretch at all.

 And, curiously enough, systemd's
 goal is to replace those parts (see Revisiting How We Put Together Linux
 Systems at http://0pointer.net/blog ).
 Apparently, management doesn't like to be left out of control :)

This is free software, there is no way to be left out of control.

That's the whole point of the movement, provided you can code of course.
A lot of people seems to totally forget that point.

 And of course, another distribution = testing a product for free.

I wonder how, since Debian is lagging so much behind that even 
RHEL 7 is released with systemd. I wonder even why they
still have jobs posting for QA people if all is needed is to have users of
others distributions.


  People keep wanting the project to be free of corporate influence, but 
  it seems that some wouldn't be against having a bit of corporate influence 
  if the
  influence was in the way they want..
  
   Given that RHEL's main selling points are enterprise
   capabilities, quality control, and (for the government market)
   security accreditation and lots of support, I'd much rather see
   diversity and weak code spread across competing distributions.
  
  Canonical was criticized for keeping their code for their ( mir, unity ),
  and Redhat would be criticized for not keeping the code only for them. 
 
 No. RedHat is criticized for pushing their code to everyone and their
 dog.

People keep saying that, but none show no conclusive proof. Just stating
it doesn't make it true. And it doesn't resist simple inquiry such as:

if they wanted to push it everywhere, why would it be non portable to 
BSD ? 

We go back to criticize everything that happen, that's getting old.
And kinda poisonous, looking at the people leaving TC or Debian or 
maintainership.

 And it started way before systemd (dbus, hal and pulseaudio to
 name a few). At least Canonical keeps their 'innovations' to themselves
 last time.

So you agree with me. 
If you share, you are criticized, if you don't, you are criticized.
 
 
  I guess there is no good way for a company to make free software that
  change something in the core of existing ecosystem.
 
 Take a look at IBM, Oracle and Novell, you may reconsider your statement.

I fail to see what did they tried to change in the core ecosystem exactly.

Oracle is attacked by everyone for the stewardship leading to forks on mysql
and openoffice, among others. They even alienated their own community on 
solaris.

Novell was criticized for providing Mono, and providing software written in mono
for gnome ( thus changing part of the core of Gnome ), and was criticized for 
trying to get Microsoft working on interoperability. 

So

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sun, Nov 16, 2014 at 08:29:28PM -0500, Marty wrote:
 On 11/16/2014 03:32 PM, Ludovic Meyer wrote:
 On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote:
 snip
 My point is that in a modular design nothing should be so entrenched
 as to be irreplaceable. Absence of an alternate should not normally
 indicate impossibility of an alternate, but some discussions I've
 read about logind, udev and dbus are enough to raise serious
 concerns.
 
 The problem is that, without any action, the difference between nothing
 can be replaced and it can be replaced is purely theorical.
 
 The problem is very real, but there seems to be no agreement about
 solutions, which by itself is evidence of a problem.

There is not even anyone keeping a list of the solution or even the 
problem. Even the basis are not done.

If you truly want to iterate on a solution, you should
start doing it and document it.

   Now you
 can discuss for years in theory,
 
 In fact, people have been discussing this problem for years.

And how did it change anything ? It didn't. So what make you think that 
yet another year is gonna result in something ?

I do not want to be too critical, but that's the exact problem that the troll
in the Hobbit face, by discussing endless on how to cook the dwarfs, they 
get petrified.

And maybe the time to test and get something wrong, as itcan hardly be slower 
than discussing. The whole agile methodology.
 
   if this doesn't result in any practical
 outcome, you have just stresstested the mailling lists software.
 
 Until there's a rough consensus and a clear way forward, I don't
 think many people will commit to specific solutions. There are also
 unknowns like kdbus, to further complicate the matter.

Talk is cheap, as Linus said.
You seems to be in favor of design by comitee, but this doesn't seems to work
for now.

 People who just say, write your own, it's all FOSS are missing the
 point, I think. Debian is not one guy working in his mom's basement.
 It's one of the world's largest software projects. When Debian is
 stumped, because its best developers and upstreams are caught in the
 entanglement hairball, and see no clear way out, the it's clear case
 of *Houston we have a problem.*
 
 That's a interesting point, because with all those brillant minds,
 a vast majority do not even seems to care about this
 entanglement hairball. Maybe it is time to admit you do not
 know the whole details and accept that if developpers do not care,
 then they are maybe right in doing so ?
 
 Especially since you have been unable to give any technical reasons
 to why you do not want it, and how you would proceed.
 
 For you, I would start by explaining the Unix Philosophy and how it
 is a critical aspect of Debian's design:
 
 http://en.wikipedia.org/wiki/Unix_philosophy

That's not a technical reason.

 Then I would proceed to explain how various aspects of systemd
 conflict with this, causing said hairball. Finally, I would explain
 (to the best of my ability) how the entanglement issue precludes a
 quick resolution, and the delay does not indicate lack of interest.

And how would that be a technical reason ? If you disagree with the philosophy,
that's not a technical problem. That's just a opinion. Show a real technical 
issue,
not here is the design decided 20 years ago and that was ignored by several 
others 
components. heck, even in 1989, people wrote the unix hater handbook to
explain how the philosophy is wrong. For example, the example of cat not being
following this design anymore. No one throw a fuse over it, despites being
here, documented and visible by all since more than 20 years.
 
And I know Debian has popularized the idea of release when it is ready, but 
that's 
also the exact definition of vaporware. And people do not even have a estimation
of the work. Not knowing what solution to choose do not preclude from saying 
the time one of them would take. In fact, it would even help to choose.
 
 In fact, a quick google check would even give you the required
 knowledge of why it is better to link :
 http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html
 
 You can compare the code with link to systemd library vs cut and
 paste in every source code. As a exercise, you can
 surely add use dlopen() and see which one is simpler and easier to maintain
 in the long term.
 
 Then it will be your turn to explain why it is better to cut and paste or
 link statically the library, or why it is better to have to patch every 
 upstream
 to use dlopen().
 
 Not sure how we went from entanglement issues to PID tracking, but
 granting your point, it still doesn't explain how we arrive at kdb,
 console and qcodes in PID 1. :)

Because the blog post say how and why stuff requires to be linked with systemd. 
As you didn't
explain what you mean by hairballs ( ie, what requires exactly you are speaking 
about )
it is hard to explain it. I am sure that if you were precise, it can be 
explained or 
it

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-17 Thread Erwan David

Le 16/11/2014 02:13, Ludovic Meyer a écrit :
 On Sat, Nov 15, 2014 at 10:05:49PM +0100, Erwan David wrote:
 Le 15/11/2014 20:24, Brian a écrit :
 On Sat 15 Nov 2014 at 11:37:14 -0500, Miles Fidelman wrote:

 Brian wrote:
 On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:

 On Vi, 14 nov 14, 08:04:00, Marty wrote:
 By the same token systemd is a major waste with no real gain. It 
 duplicates
 equivalent modular alternatives, and also requires unnecessary effort to
 repair damage from excessive coupling.
 I challenge you to come up with a configuration that duplicates
 systemd's features with a combination of other software.
 That assumes that one needs or wants systemd's features.
 I rather think Andrei might not regard this as answering his challenge.
 (You also didn't say whether the link's picture made you chuckle :) ).

 For some (many?) of us, systemd represents no gain, and significant
 operational impact (time required to deal with changes).
 Fair enough, but working within the realities of a situation is also
 part of the deal. The deal for Jessie is systemd. This is not on a take
 it or leave basis; quite a lot of work has been put into ensuring the
 alternatives you want are there.

 It isq : when you have bugs like
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762623
 Once said oh it works with systemd, then no more activity on the bug,
 nothing.
 I would suggest to read the url you post. There was a message from the
 maintainer saying sorry, i tought I answered, I already reported it to
 udev, please give more information on the bug.

 Then indeed, you didn't followed up.
  

Sorry, I was not asked more precision since 2 days ago, and could not
answer right away.
 That means that practically, systemd is de facto compulsory. Not the
 default, the only way allowed.

 So it is take or leave.
 I think this conclusion is likely wrong and hasty, given the lack of 
 activity is a result on waiting on more information from the reporter. 

Reporter cannot give info if not asked to...

Moreover even when systemd is not pid 1, it must be used through logind,
pam, etc...

I cannot help more since I do not find any doc on debugging systemd
components, for people not knowng systemd internals.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546a5df3.40...@rail.eu.org

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sun, Nov 16, 2014 at 04:09:52PM -0500, The Wanderer wrote:
 On 11/16/2014 at 02:51 PM, Ludovic Meyer wrote:
 
  On Sun, Nov 16, 2014 at 01:28:35PM -0500, The Wanderer wrote:
 
 [about the Linux kernel developers]
 
  They do, however, maintain their external interfaces - rigidly so,
  sometimes to what others might call the point of insanity. An 
  intentionally user-visible API from the Linux kernel will
  essentially never change, and if an exception to that is ever made,
  it will be announced *years* in advance. That is one reason why
  they try to be *VERY* careful to get the user-facing interface
  right, at least on some basic level, before ever pulling it into
  a released kernel.
  
  The kernel interfaces which kernel modules need to use are 
  kernel-internal interfaces.
  
  The systemd interfaces described on the page you link to appear to
  be systemd-external interfaces.
  
  I know the difference, and I know this is just some tradeoff, there
  is advantages and disadvantages on doing that, and if I was cynical,
  I would postulate that companies like redhat do push for that model
  of internal/external interfaces in the kernel, because this give a
  reason to take entreprise distributions. ( ie, SLES, RHEL do have a
  stable promise API for each release like Windows do, because
  customers do pay also for that )
  
  My point is not that kernel or systemd devs are right or wrong. But
  the point is that people who complain that systemd do not have a
  internal interface yet forget that kernel do not have one since the
  start and will not have in a near future.
 
 Er... were people complaining that systemd does not have a stable
 internal interface?

 I thought (given the context of that linked-to page) that the complaint
 was that systemd does not have a stable *external* interface.

I think it does. The real question is
- is this interface sufficient
- is the boundary the one we agree on
 
 With possible room for dispute about what constitutes an interface,
 what qualifies as stable, and maybe even what counts as internal vs.
 external... but I didn't see anything that I recognized as being a
 complaint about systemd's internal interfaces.

Let's take the one about logind. What people complain is that
logind requires systemd as pid1, and the reason about this is because
logind requires the internal and non stable interface of systemd, otherwise,
someone would be able to run it with another init, provided it implement the 
stable
interface (this particular interface that do not exist).

Or people do complain they cannot replace or remove journald. Again, because 
there is no separation between the 2, because there is no documented
separation ie a external interface. I hope this clarify my point, but we seems 
to 
agree on this, if I read well what you said just after.
 
 No one is even trying to implement something outside of the systemd
 project that talks to systemd's internal interfaces directly, AFAIK -
 unless systemd-shim does, but I didn't think systemd-shim talked to
 systemd itself at all, just to other tools provided by the systemd
 project.
 
 And if the interfaces which those tools use to talk to
 systemd-the-init-system are considered internal interfaces, which is a
 position for which an argument could be made, then that would simply
 bring up the argument that since those are separate tools the interfaces
 between them should be considered external to each tool. Whether or not
 that's a reasonable argument, and the extent to which it might be
 possible to treat those interfaces that way, could be a discussion worth
 having - but having it would require *getting* to that point first.
 
 -- 
The Wanderer
 
 The reasonable man adapts himself to the world; the unreasonable one
 persists in trying to adapt the world to himself. Therefore all
 progress depends on the unreasonable man. -- George Bernard Shaw

-- 
l.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141117205859.gc31...@gmail.com

Re: Installing an Alternative Init?

2014-11-17 Thread Reco

On Mon, Nov 17, 2014 at 07:15:38PM +0100, Ludovic Meyer wrote:
 On Mon, Nov 17, 2014 at 06:29:24PM +0300, Reco wrote:
   Hi.
  
  On Sun, Nov 16, 2014 at 03:48:34PM +0100, Ludovic Meyer wrote:
   On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote:
As much as I dislike systemd, I'm not sure that it's a vendor
conspiracy to control the Linux ecosystem.  Yes, redhat pays
Lennart Poettering's salary (among others).  But... I'm hard pressed
to see how turning a collection of free distros into functional
equivalent's of redhat, or increasing the resources applied to free
distros, is really to their benefit.  If anything, it would seem to
dilute the competitive advantage of paid RHEL.

Personally, I think it's more a matter of one, prima donna
developer, who has the advantage of a salary, who has a vision and
design philosophy that he's promoting in a very aggressive and
single minded way.  And he's very overt about it.  (Somebody posted
an email from Poettering last week saying, roughly, 'first we're
going to get kdbus into the kernel, then we're going to make udev
depend on it, and then everyone will have to eat systemd to get
udev.'  As I recall, the message closed with 'gentoo, be warned.')

I figure this is more a case of redhat management not wanting to
tick off valued prima donna, and maybe seeing what he's doing as a
contribution to the open source community (to date, redhat has been
pretty good about contributing to the community in lots of different
ways).  Still,  if I were in their shoes, I'd be trying to reign the
guys in. 
   
   Why would the management of a external company care about what 
   happen in Debian ? 
  
  Because Debian is upstream for several critical RHEL parts, such as
  shadow (passwd, useradd and friends).
 
 1 ( ie shadow-utils ) is not several.

Google is your friend. Sorry, could not resist.


 And by having a critical look at your affirmation, RH is paying a lot 
 of upstreams contributors for several critical Debian part :
 - glibc

Not as of Wheezy. Wheezy uses eglibc.
And, while we're on topic of glibc - RedHat isn't writing new 'Modern'
libc to replace an old one. Yet.

Next few years we may see systemd-libc if things go as they're going
now.


 - gcc

A GNU project. Not a RedHat pet.


 - util-linux-ng

A kernel.org project. Not a RedHat pet again.


 - kernel

A joint project, controlled by Torvalds  co. RedHat is one of the few
who's playing a major role there, true. But that role was not enough to
push the most controversial features (kdbus, for example) into the
mainline.


 - udevd

Yup. You nailed that one if we consider latest udev development. It took
a merging into systemd to became that way.

Keep shooting, and you may score a couple of more hits ;)


 to name a few. I could name a few non critical stuff, from gnome, openjdk.

GNOME is can be considered to be controlled by RedHat indeed.
OpenJDK - please. Java is Oracle's turf, not a RedHat one. RedHat
invented their own Ceylon language just because of that fact.


 So I am not sure that your point is valid. Given the size of Redhat, 
 I also suspect that having someone working on shadow-utils wouldn't be a 
 problem. Judging by 
 SEC fillings, public information, there is around 6900 people.
 1 more coder is not a stretch at all.

No doubt this number includes a small army of corporate drones, janitors
and security guys.
Do you have any estimate on a number of real developers in Red Hat?


  And, curiously enough, systemd's
  goal is to replace those parts (see Revisiting How We Put Together Linux
  Systems at http://0pointer.net/blog ).
  Apparently, management doesn't like to be left out of control :)
 
 This is free software, there is no way to be left out of control.

For a fellow developer - sure, there's no way to be out of loop as long
as said developer plays by upstream rules.


 That's the whole point of the movement, provided you can code of course.
 A lot of people seems to totally forget that point.

But for a typical management drone - it seems we're both agree that
there's such a way. All it takes is inability to code.

So my point is simple. You mix a few really good developers and an army
of managers. That's a modern RedHat.

 
  And of course, another distribution = testing a product for free.
 
 I wonder how, since Debian is lagging so much behind that even 
 RHEL 7 is released with systemd.

By reading users' bug reports. RHEL has a limited choice of prebuilt
software, therefore a limited number of usecases.

Besides, RHEL7 is supported until 2024 (IIRC). There's plenty room for
small improvements.


 I wonder even why they
 still have jobs posting for QA people if all is needed is to have users of
 others distributions.

I haven't imply that offloading beta-testing to the community mutually
exclusive with internal testing :)



   People keep wanting the project to be free of corporate

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Mon, Nov 17, 2014 at 08:44:06AM +0900, Joel Rees wrote:
 One thing at a time.
 
 On Mon, Nov 17, 2014 at 1:23 AM, Ludovic Meyer ludo.v.me...@gmail.com wrote:
  [...]
  Your definition of mainstream is strange.
 
 What's strange about it? Do I need to provide a link to the dictionary
 for you for that? I assume not.
 
 Given a community, there is a mainstream within that community.

Well, the point is what is the community exactly. Not the community in general
but the community you are refering.

As it could be debian users, all regular linux distro users ( by
regular, I mean desktop/server ), or all linux users ( ie counting embedded 
appliance ? ), or do we count android as well ?

if we go just by the number, do we count users or
systems, especially in the light of amazon/yahoo/google/facebook 
server, who likely have combined more server than there is desktop users
of linux ( see a estimation in 2009 
http://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-servers/
 )
  
 We have a community of users of Linux-kernel OSses that provide,
 without excessive effort, command-line shells, full C compiler suites,
 administrator access to the device owner, etc.

So your definition is the community of people who are root on a linux system.
No problem, but that's not exactly clear. 
 
 (Sure, Android has No-root Debian and Terminal-IDE, but those are
 third-party apps and don't give true administrator access. The sdk is
 not something mainstream Android users can figure out without a lot of
 effort, and takes a separate machine. Thus, Android is outside the
 domain of discussion, and I shouldn't have had to explain why. Unless
 you think that Linux OSses should start limiting the device owner from
 doing things like adding users and changing the unit infrastructure,
 in which case, the reason we can't communicate is clear.)
 
 Now, you note that Fedora claims in the range of a million users. Even
 if their estimates are an order of magnitude high, that's hundreds of
 thousands.
 
 How can that not be mainstream?

Sure, so then Debian waited 3 years after the systemd hit the mainstream,
if you consider Fedora to be mainstream.

Therefore, your request of waiting was fullfilled. 

 Or are you under the misapprehension that there is only one
 mainstream? Fedora and Debian are the mainstreams of what most of us
 consider the Linux community. (Ubuntu being part of the greater Debian
 community and Cent being part of the greater Fedora community.)

You have been using the word as singular, so I was wondering which one you 
have been using. So based on the definition everybody will understand, Linux
itself not being mainstream
 
 Now, before you throw up any more quibbles, what I am talking about
 when I say mainstream users is those users who have not specifically
 chosen to be part of an experiment who are being dragged into an
 experiment.

The whole free software movement is mostly experiments. 
Experiment in the governance at the internet age, in term of software 
methodology, in term of research. There is people trying
new things. The kernel itself is always evolving, 
getting new features, etc.

 Except you'll now point out that Fedora is the cutting edge of Red
 Hat's stuff, which is ignoring the issue. And Fedora has rawhide, and
 Debian has sid, which is ignoring the issue.
 
 sid is locked into the future of stable, just like Rawhide is locked
 into the future of Fedora. The release schedule does not allow for
 major changes to be unrolled easily. Anything that gets accepted into
 sid and passes into testing gets into stable, unless a lot of people
 get excited during the testing phase.
 
 Now, is systemd a major change or isn't it?
 
 If you ask Poettering when he wants to sell systemd, it's a MAJOR
 improvement. If you ask systemd proponents when they are sandbagging,
 NO! NO! It's NOT a major change. (Sorry about the shouting, I'm just
 describing how it looks to me. It does look like you guys are being
 emphatic.)

It depend on how you measure it. Number of impacted packages ? Number
of impacted users ? Change of the name of the software, versionning ?
Debian did switch to parralel init, was it a major change ( as it
required to fix all initscript for lsb )

Gnome 3, kde 4, grub2, was it major change ?
Xfree to xorg ? Glibc to eglibc ?
Linux 2.0 to 2.2 to 2.4 ?

Why none of this had a alternative ? 

There is lots of major change anytime and since the start of Debian.
And again, you keep using word as if it was ginving any meaning to what you 
propose
but there is no actionable items at all.

 If it's a major change, it needs more time, and, I'm asserting, the
 special handling of a temporary parallel fork.

You mean like it was the case in the previous stable, where systemd was
present but not as default ?

And you say more time, how much more time ?
If that's not time based, what are the criteria, what are the bug that 
should be solved before saying this cannot be done. And why

Re: Installing an Alternative Init?

On Tue, Nov 18, 2014 at 12:41:14AM +0300, Reco wrote:
 On Mon, Nov 17, 2014 at 07:15:38PM +0100, Ludovic Meyer wrote:
  On Mon, Nov 17, 2014 at 06:29:24PM +0300, Reco wrote:
Hi.
   
   On Sun, Nov 16, 2014 at 03:48:34PM +0100, Ludovic Meyer wrote:
On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote:
 As much as I dislike systemd, I'm not sure that it's a vendor
 conspiracy to control the Linux ecosystem.  Yes, redhat pays
 Lennart Poettering's salary (among others).  But... I'm hard pressed
 to see how turning a collection of free distros into functional
 equivalent's of redhat, or increasing the resources applied to free
 distros, is really to their benefit.  If anything, it would seem to
 dilute the competitive advantage of paid RHEL.
 
 Personally, I think it's more a matter of one, prima donna
 developer, who has the advantage of a salary, who has a vision and
 design philosophy that he's promoting in a very aggressive and
 single minded way.  And he's very overt about it.  (Somebody posted
 an email from Poettering last week saying, roughly, 'first we're
 going to get kdbus into the kernel, then we're going to make udev
 depend on it, and then everyone will have to eat systemd to get
 udev.'  As I recall, the message closed with 'gentoo, be warned.')
 
 I figure this is more a case of redhat management not wanting to
 tick off valued prima donna, and maybe seeing what he's doing as a
 contribution to the open source community (to date, redhat has been
 pretty good about contributing to the community in lots of different
 ways).  Still,  if I were in their shoes, I'd be trying to reign the
 guys in. 

Why would the management of a external company care about what 
happen in Debian ? 
   
   Because Debian is upstream for several critical RHEL parts, such as
   shadow (passwd, useradd and friends).
  
  1 ( ie shadow-utils ) is not several.
 
 Google is your friend. Sorry, could not resist.

I spend time to give concrete response. It would be polite to do the same.
 
 
  And by having a critical look at your affirmation, RH is paying a lot 
  of upstreams contributors for several critical Debian part :
  - glibc
 
 Not as of Wheezy. Wheezy uses eglibc.
 And, while we're on topic of glibc - RedHat isn't writing new 'Modern'
 libc to replace an old one. Yet.

That doesn't change the fact that before, this was glibc, with the
infamous Ulrich Drepper, and that eglibc is now merged in glibc.
 
 Next few years we may see systemd-libc if things go as they're going
 now.
 
 
  - gcc
 
 A GNU project. Not a RedHat pet.

Read again :
RH is paying a lot of upstreams contributors
GCC was pushed historically by cygnus, and cygnus got 
acquired by RH.
If you look at the committers, you would see lots of
people from the company.
 
 
  - util-linux-ng
 
 A kernel.org project. Not a RedHat pet again.

https://git.kernel.org/cgit/utils/util-linux/util-linux.git
Look who make release, look where he work. 

In fact, by that same reasoning, we can say that systemd is 
a freedesktop.org project, whic is not more 
controlled by RH than stuff hosted on kernel.org.

 
  - kernel
 
 A joint project, controlled by Torvalds  co. RedHat is one of the few
 who's playing a major role there, true. But that role was not enough to
 push the most controversial features (kdbus, for example) into the
 mainline.

Kdbus is pushed by Greg Kroah-Hartman, who is employed by the Linux Foundation.
Before, he was working at Novell, and has no link with RH afaik. 


  - udevd
 
 Yup. You nailed that one if we consider latest udev development. It took
 a merging into systemd to became that way.

Mhh no.
http://blog.bofh.it/debian/id_442

Looking at the graph made by the debian maintener, we can see that 
more than 95% of the system have it installed since 2008.
 
 Keep shooting, and you may score a couple of more hits ;)

That's not a constest, I am not keeping score.

 
  to name a few. I could name a few non critical stuff, from gnome, openjdk.
 
 GNOME is can be considered to be controlled by RedHat indeed.
 OpenJDK - please. Java is Oracle's turf, not a RedHat one. RedHat
 invented their own Ceylon language just because of that fact.

Indeed, I wanted to say icedtea. 
 
 
  So I am not sure that your point is valid. Given the size of Redhat, 
  I also suspect that having someone working on shadow-utils wouldn't be a 
  problem. Judging by 
  SEC fillings, public information, there is around 6900 people.
  1 more coder is not a stretch at all.
 
 No doubt this number includes a small army of corporate drones, janitors
 and security guys.
 Do you have any estimate on a number of real developers in Red Hat?

How would I ?

Go find a Redhat developper and ask. 

The best approximation you can have is see how many offer there is for technical
people on the website vs others type.

Or dig in the SEC fillings, if you are familliar

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-17 Thread Marty


On 11/17/2014 01:54 PM, Ludovic Meyer wrote:

On Sun, Nov 16, 2014 at 08:29:28PM -0500, Marty wrote:

On 11/16/2014 03:32 PM, Ludovic Meyer wrote:
On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote:
snip
My point is that in a modular design nothing should be so entrenched
as to be irreplaceable. Absence of an alternate should not normally
indicate impossibility of an alternate, but some discussions I've
read about logind, udev and dbus are enough to raise serious
concerns.

The problem is that, without any action, the difference between nothing
can be replaced and it can be replaced is purely theorical.

The problem is very real, but there seems to be no agreement about
solutions, which by itself is evidence of a problem.


There is not even anyone keeping a list of the solution or even the
problem. Even the basis are not done.

If you truly want to iterate on a solution, you should
start doing it and document it.


There *are* people doing it, e.g. systemd-shim, uselessd, nosh and 
eudev, the refracta team, and others. There are so many projects, it's 
hard to know where to join in, but I'm willing to help if I can.



  Now you
can discuss for years in theory,

In fact, people have been discussing this problem for years.


And how did it change anything ? It didn't. So what make you think that
yet another year is gonna result in something ?


Right now Jessie is seems to have acceptable sysvinit support. The main 
concerns seem to be about Stretch, but that's 3-4 years away, so I think 
there's time to work on solutions.



I do not want to be too critical, but that's the exact problem that the troll
in the Hobbit face, by discussing endless on how to cook the dwarfs, they
get petrified.

And maybe the time to test and get something wrong, as itcan hardly be slower
than discussing. The whole agile methodology.


Keep in mind this is a mostly volunteer project, with a lot of people 
working in their spare time.



  if this doesn't result in any practical
outcome, you have just stresstested the mailling lists software.

Until there's a rough consensus and a clear way forward, I don't
think many people will commit to specific solutions. There are also
unknowns like kdbus, to further complicate the matter.


Talk is cheap, as Linus said.
You seems to be in favor of design by comitee, but this doesn't seems to work
for now.


I think small teams are the way to go in FOSS.


People who just say, write your own, it's all FOSS are missing the
point, I think. Debian is not one guy working in his mom's basement.
It's one of the world's largest software projects. When Debian is
stumped, because its best developers and upstreams are caught in the
entanglement hairball, and see no clear way out, the it's clear case
of *Houston we have a problem.*

That's a interesting point, because with all those brillant minds,
a vast majority do not even seems to care about this
entanglement hairball. Maybe it is time to admit you do not
know the whole details and accept that if developpers do not care,
then they are maybe right in doing so ?

Especially since you have been unable to give any technical reasons
to why you do not want it, and how you would proceed.

For you, I would start by explaining the Unix Philosophy and how it
is a critical aspect of Debian's design:

http://en.wikipedia.org/wiki/Unix_philosophy


That's not a technical reason.


It's a philosophy, and not even the dominant one in the software 
industry, but it is about technology and engineering, and part of the 
culture and design of Debian. I recognize that it also clashes with the 
universal operating system moniker, because the whole world is not 
Unix, so I see a place in Debian for monolithic OSs like systemd and 
Android clones, but I would have been more conservative about 
introducing it.



Then I would proceed to explain how various aspects of systemd
conflict with this, causing said hairball. Finally, I would explain
(to the best of my ability) how the entanglement issue precludes a
quick resolution, and the delay does not indicate lack of interest.


And how would that be a technical reason ? If you disagree with the philosophy,
that's not a technical problem. That's just a opinion. Show a real technical 
issue,
not here is the design decided 20 years ago and that was ignored by several 
others
components.


Design philosophies have major technical implications. If Debian had 
started with Windows 3.1, I don't think the project would be where it is 
today. Loose package coupling works well with volunteer projects. For 
systemd to work in Debian it has to work within the existing modular 
framework, and I think it can be done, with difficulty.


 heck, even in 1989, people wrote the unix hater handbook to

explain how the philosophy is wrong. For example, the example of cat not being
following this design anymore. No one throw a fuse over it, despites being
here, documented and visible by all since more than 20 years.


You forgot to include

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Laurent Bigonville

Le Sat, 15 Nov 2014 20:21:49 -0500,
Marty mar...@ix.netcom.com a écrit :

 On 11/15/2014 06:49 AM, Andrei POPESCU wrote:
[...]
 
  At least some of people rejecting systemd demand that it be removed
  completely, including libsystemd. How is it pro-choice to forbid me
  from being able to use a software at its full potential?
 
 For me it's more about being unable to remove it completely, because
 of vendor lock-in. There's no technical reason that I know of that
 anything in userspace cannot modular, and replaceable, so when
 something cannot be replaced then an alternative must be provided, or
 else my default assumption is that vendor lock-in is in effect.

Well, yes there are technical reasons why you cannot remove a library
package when you have symbols provided by this library used in an
executable. You can still recompile the package and remove some
configure flag if you want to remove this dependency.

OTHO there is no technical reasons that I can see, to completely remove
libsystemd package. You have tenth of other libraries on your system
that, like libsystemd, turn them self into a noop if some some
functionality or daemon are not enable. I'm thinking here for example
about libselinux and libaudit (both also written by Red Had and the
NSA, OMG!!!11), and yet I fail to see any outcry here...

So as long as you cannot _prove_ that having libsystemd installed on
your machine is causing any issues, I'll personally mentally classify
your request as I don't want to see any packages containing the
systemd string on my machine and redirect these to /dev/null.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116112652.78d2a...@fornost.bigon.be

Re: Installing an Alternative Init?

2014-11-16 Thread Brian

On Sat 15 Nov 2014 at 19:31:27 -0500, The Wanderer wrote:

 On 11/15/2014 at 07:21 PM, Paul E Condon wrote:
 
  Yet another topic: It should be possible to install systemd on a
  system that already has some other init system installed on it. This
  should be tested, but how?
 
 If I understand what you mean by install systemd, then it's trivial:
 
 apt-get install systemd
 
 That does not switch the active init system to be systemd. Doing *that*
 would require:
 
 apt-get install systemd-sysv
 
 and even that, in its turn, does not (automatically?) remove
 sysvinit-core from the system; you can still boot to it (from a
 backup-installed location) with a kernel command line option, as a
 fallback if systemd does break something too badly to even boot.

systemd-sysv and sysvinit-core are not co-installable and this is
expressed in the Conflicts: for both packages. Installing one results
in the other being removed.

 Or that's the claim, anyway. I've been examining files from
 sysvinit-core on my own computer in an attempt to remind myself of some
 of the details of how that works, and at a glance I don't see the backup
 copy of /sbin/init anywhere...

A Wheezy system has the sysvinit package installed. Moving to Jessie
will upgrade this package. The only thing of real interest in it is
/lib/sysvinit/init, the fallback SysV init binary.

A new installation does not have the sysvinit package so it would have
to be purposefully installed to get the fallback init.

Which leads to yet another way of getting a first boot with sysvinit
using d-i:

1. Preseed installation of sysvinit with base-installer/includes or a
   late_command.

2. Boot with 'init=/lib/sysvinit/init'. A late_command could put this in
   /etc/default/grub.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/16112014103424.b38d685b4...@desktop.copernicus.demon.co.uk

Re: Installing an Alternative Init?

2014-11-16 Thread Brian

On Sun 16 Nov 2014 at 00:23:24 +, Martin Read wrote:

 On 15/11/14 23:04, Paul E Condon wrote:
 If one could absolutely rely on apt-get always getting it right, then
 
 apt-get install -y sysvinit-core
 
 could always be used to remove systemd even from a system that has
 been booted into systemd and running, and not just in the context
 of a pre-seed. Right?
 
 That command is unlikely to actually remove systemd on any Debian
 jessie system. What it will do is change what the symlink /sbin/init
 points to so that next time the system on which you do it is
 rebooted, it will use sysvinit as the init daemon.

I see a removal of a symlink, not a change.

With the systemd-sysvinit package installed:

   root@jessie-b2:~# ls -l /sbin/init
   lrwxrwxrwx 1 root root 20 Sep 28 20:05 /sbin/init - /lib/systemd/systemd

With the sysvinit-core package installed:

   root@jessie-b2:~# ls -l /sbin/init
   -rwxr-xr-x 1 root root 39396 Nov 11 19:59 /sbin/init



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1611201440.e3038d94c...@desktop.copernicus.demon.co.uk

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Joel Rees

I have been informed off-list that some might misinterpret something I
wrote here, so I will attempt to clarify a few things.

On Fri, Nov 14, 2014 at 8:59 AM, Joel Rees joel.r...@gmail.com wrote:
 On Thu, Nov 13, 2014 at 11:04 PM, Tanstaafl tansta...@libertytrek.org wrote:
 On 11/12/2014 5:18 PM, Andrei POPESCU andreimpope...@gmail.com wrote:
 On Mi, 12 nov 14, 15:43:09, Tanstaafl wrote:

 Sounds good to me, but in reality, since the default *and only* init
 system for the last very many years was Sysvinit (this extremely salient
 point seems to be completely and totally lost on the systemd
 proponents), I think only systemd and sysvinit need to be there... but
 allowing for additions once required bugs implementing them are resolved
 as fixed.

 You're forgetting about:

 It doesn't matter Andrei...

 1. The *default* is what we are discussing.

 The *default* for Debian has been sysvinit since - forever?

 2. The systemd proponents pushed to make systemd the *new* default - a
 massively major change from *all* previous releases since... forever?

 3. A bug was opened to allow for the ability to allow a clean install to
 be performed with systemd on wheezy, while sysvinit was still the default.

 It should have been made mandatory that the systemd folks get this bug
 fully resolved and functional *on wheezy*, *and* commit to maintaining
 this ability in jessie, as a pre-condition to even getting the question
 of a change of the default init system for jessi on the ballot.

 Anything else, as I said, makes no sense.

 To explain to the systemd advocates who refuse to understand the
 engineering questions, this is the real engineering mistake in
 systemd.

 The engineering question keeps getting sidetracked by people who
 assert that we are talking about technical details, and then proceed
 to question (foolishly) the necessity of modularity, or (rightly) the
 meaning of modularity, etc. That all was and is still relevant, but if
 proper engineering principles had been followed in bringing systemd
 in, the open development practices our larger community claims as its
 reason for existence would have taken care of the technical details.

 Maybe it would help if I said, engineering management, instead of
 just engineering, although you really can't separate management from
 engineering.

This person says that I have misrepresented the Fedora community's
reaction in my description of events.

This is not an attempt to be a linear history of systemd adoption in
Fedora. It is simply intended as a few of my observations there when I
was a user, and from here in the two years since I left.

 It was clear much longer than four years ago how deeply the changes
 would effect the infrastructure which defines the system, and on which
 the stability of the system depends. Every daemon package would be
 effected, even if the systemd project had restrained themselves to
 working only on the init part of the infrastructure. Every daemon
 package needed to be fixed to the new interface, and tested under it.
 (Many still need that.)

This is not disparaging, it is acknowledging reality. If I were to
develop an alternative init, add full daemon/service management, tie
it to device management, login management, error logging, etc., the
result would impose the same level of re-implementation and testing
burden across the OS.

I wouldn't do it that way, of course, but that's the level of
engineering cost the approach they take incurred.

 They didn't, of course they didn't,

... restrain themselves, that is.

 they've admitted many times that
 the init system was not their ultimate target.

Links to Poetterings blog have been posted. It's hard to assume that
he was intending to speak in the absurd, or that he was
misrepresenting the goals of the project he leads.

 Therefore, every package that uses or provides authentication got
 entangled in the changes and needed both careful editing and extensive
 testing. The testing is still to be completed, because we are not
 talking about context-free grammar simplicity here in any of the
 parts.

I know that the systemd proponents want to claim that testing is
almost finished, but, hey, we all know how it is when we tell them
that the project is 90% complete. It's 90% of what we can see, and
more than half the time we aren't seeing anything close to the real
extent of what remains. Top-down was supposed to fix that, objects
were supposed to fix that, declarative programming was supposed to fix
that, but programming projects tend to be like cave systems. The more
we get done, the deeper we dig, the more we discover has to be done
before we are finished.

This is one of the very reasons for the existence of open source
software, that we can decide, when it is our own project, this is
where we stop for now. But just because we stop doesn't mean we are
finished.

I know the systemd proponents really want the job to be mostly
complete, and most of what they see is mostly complete. It's

Re: Installing an Alternative Init?

2014-11-16 Thread The Wanderer

On 11/16/2014 at 05:58 AM, Brian wrote:

 On Sat 15 Nov 2014 at 19:31:27 -0500, The Wanderer wrote:
 
 On 11/15/2014 at 07:21 PM, Paul E Condon wrote:
 
 Yet another topic: It should be possible to install systemd on a
 system that already has some other init system installed on it.
 This should be tested, but how?
 
 If I understand what you mean by install systemd, then it's
 trivial:
 
 apt-get install systemd
 
 That does not switch the active init system to be systemd. Doing
 *that* would require:
 
 apt-get install systemd-sysv
 
 and even that, in its turn, does not (automatically?) remove
 sysvinit-core from the system; you can still boot to it (from a
 backup-installed location) with a kernel command line option, as a
 fallback if systemd does break something too badly to even boot.
 
 systemd-sysv and sysvinit-core are not co-installable and this is
 expressed in the Conflicts: for both packages. Installing one
 results in the other being removed.

You're right. I misinterpreted which functionality was provided by which
package.

The backup copy of sysvinit's init binary is provided by the sysvinit
package, not by the sysvinit-core package. I was confused by this
because A: the word core seems to imply that the core functionality of
the thing being packaged is present in that package, and B: the sysvinit
package's description claims that if you have systemd working fine, you
can safely remove that package - which I read as implying that the
actual sysvinit init binary must not be in the sysvinit package, because
otherwise it would not be safe to remove it.

I've figured out the real story again now, and I agree that there's a
logic to it; it just wasn't sufficiently intuitive for me last night for
some reason.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Installing an Alternative Init?

On Sb, 15 nov 14, 21:25:01, Marty wrote:

 I don't think Debian (or FOSS, for that matter) was ever about a
 winner-take-all approach to software choice. That seems to have originated
 in the commercial distributions, which have a financial interest in a)
 controlling users and b) controlling costs. I don't think that philosophy
 was ever part of Debian in the past.

My mental image about Debian and FOSS is more of an eco-systemd, where 
survival of the fittest applies.

 I had thought that all it takes is one
 interested maintainer to keep a package alive in Debian.

... with enough time and skill and...

 You might also be simplifying the problem. Software entanglement is a
 complex technical problem. There's a reason it's regarded as lock-in,
 because it's a technical cage that can be hard to break out of. It herds
 users in one direction, so the popularity issue is not only irrelevant, but
 misleading.
 
 I don't think there is a direct relationship between the number of users of
 alternate software, and the importance of maintaining it. I would say it's
 more of an opposite relationship, if user choice is valued. As less people
 use locked-out alternate software, those alternates arguably become more
 important to maintain to protect the choice of that minority. This of course
 presumes that user choice is still valued in Debian, which is something I no
 longer take for granted.
 
And how can this work in an environment where nobody can be forced to do 
work? Popularity and maintenance resources go hand in hand.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Installing an Alternative Init?

On Sb, 15 nov 14, 17:21:22, Paul E Condon wrote:
 
 Another topic:
 My reading of the man page for apt-get seems to say that there
 is no way to purge the configuration file of packages that were pulled
 in to satisfy a dependency and subsequently autoremoved. I hope this
 is an artifact of poor use of English. But if true, it should be fixed.

apt-get --purge autoremove

I agree it's not obvious from the manpage, so a minor bug could make 
sense.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Installing an Alternative Init?

On Du, 16 nov 14, 15:32:58, Andrei POPESCU wrote:
 
 My mental image about Debian and FOSS is more of an eco-systemd, where 
 ^^
 survival of the fittest applies.
 
That typo is just too funny :p

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sb, 15 nov 14, 11:37:14, Miles Fidelman wrote:
 
 For some (many?) of us, systemd represents no gain, and significant
 operational impact (time required to deal with changes).

Have you considered, just for a fraction of a second, that a migration 
to systemd, however painful it may prove, could in fact make your setup 
much more reliable and understandable?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Installing an Alternative Init?

On Sat, Nov 15, 2014 at 09:25:01PM -0500, Marty wrote:
 On 11/15/2014 07:45 PM, Ludovic Meyer wrote:
 On Wed, Nov 12, 2014 at 12:26:26AM -0500, Marty wrote:
 On 11/11/2014 02:16 PM, Brian wrote:
 On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote:
 
 On 11/11/2014 12:07 PM, Laurent Bigonville wrote:
 
 There are no functional differences between an installation with
 sysvinit-core out of the box or an install where sysvinit-core is
 installed later, this is a fact.
 
 Allowing the user to choose this at install time from the interface is
 a nice to have feature (wishlist bug) not a RC bug like you were
 claiming earlier.
 
 There is a potential practical consequence of not advertising an
 init alternative during setup. It makes users less likely to be
 aware of it, or even aware that the init system has changed.
 
 New users do not need to be be aware of all the background to the
 choosing of a default init. No advertisement is needed. By definition,
 they do not care. They want Debian. Please let them have it.
 
 They will not care by definition only if they are not aware of the
 change, and most won't be aware unless they are informed during the
 installation.
 
 They won't know they lost the choice they didn't know they had. Capisce?
 
 What choice have they lost?
 
 They lost an *informed* choice. I think the installation program
 should not take sides but just inform the user. A choice that the
 user is not aware of is the same as no choice, and is potentially
 coercive and disrespectful. It makes Debian seem partial to Red
 Hat's business plan to take over the Linux ecosystem.
 
 If you care so much about Redhat code, maybe you should document
 yourself, and see there pay coders for glibc, gcc, the kernel ( a
 ton of them, according to lwn and linux fundations reports ), on
 coreutils, gnome, kde, php, python, openssh, etc, etc.
 
  Whatever it was, it didn't exist as you imply
  in Wheezy.
 
 It wasn't an issue in Wheezy because the default init option had not
 changed from the previous release, and any release before that.
 
 They won't know, that is, until it bites them somewhere down the
 line. Then they won't know where to look or who to blame, and will
 blame Debian.
 
 What bites them?
 
 Individually, probably something that requires sysvinit or one many
 core services that got replaced. Collectively, getting trapped by
 vendor lock-in.
 
 You keep using those words, but you do not seems to use them correctly.
 If the same system is present on more than one distributio, that's not
 vendor lock-in since you can switch distribution and then reuse the same
 system.
 
 I meant that one vendor seeks to control the Linux ecosystem.
 Whether that plan is viable or even sane, is another issue, but I am
 not eager to see if their plan will succeed or be a guinea pin in
 the experiment.
 
 (I would like to see systemd succeed in Debian, however, *without*
 sacrificing modularity or user choice. That would be like embrace
 and extend in reverse, and could serve to protect downstreams.)
 
 Being tied to one package format ( and so on the ecosystem around ) would
 be true lock-in. And no one complained that much since Debian existed,
 despites the .deb having a few shortcomings at start, shortcomings that
 were fixed later such as having checksum of installed software, a feature
 rpm had at a time the dpkg didn't ( around 2002, so that's really a old 
 stuff ).
 
 In both cases it could be the result of users being steered to the
 default init by the installation program, leaving alternatives to
 rot.
 
 Alternatives will rot if no one use them, so either you recognize than
 no one is interested to use them and it will indeed rot,
 or that the few interested to use them are unable to fill bug reports and
 help the alternatives survives.
 
 Given that a reading of the archives here show less than 50 people by a
 large margin complaining on this list, I would indeed see that as a minority.
 
 ( as I hope there is more than 100 000 to 1 million Debian users, since
 Ubuntu speak of 20 millions, Fedora speaking around 2 or 3 millions. But that
 doesn't matter, since 100 000 or 1 million, there would still be far less 
 than 1%
 of the user base ).
 
 I don't think Debian (or FOSS, for that matter) was ever about a
 winner-take-all approach to software choice. That seems to have
 originated in the commercial distributions, which have a financial
 interest in a) controlling users and b) controlling costs. I don't
 think that philosophy was ever part of Debian in the past. I had
 thought that all it takes is one interested maintainer to keep a
 package alive in Debian.

You are incorrect, on several point. First, it would be totally stupid to 
want to control users when you give them the source code, way to build it
and the legal right to do what they want with it ( modulo GPL restrictions ). 
You can still use the software after you stop paying for it in commercial 
distribution, 
so if the goal is to control

Re: Installing an Alternative Init?

On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote:
 Marty wrote:
 On 11/15/2014 07:45 PM, Ludovic Meyer wrote:
 On Wed, Nov 12, 2014 at 12:26:26AM -0500, Marty wrote:
 On 11/11/2014 02:16 PM, Brian wrote:
 On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote:
 
 On 11/11/2014 12:07 PM, Laurent Bigonville wrote:
 
 There are no functional differences between an installation with
 sysvinit-core out of the box or an install where sysvinit-core is
 installed later, this is a fact.
 
 Allowing the user to choose this at install time from the
 interface is
 a nice to have feature (wishlist bug) not a RC bug like you were
 claiming earlier.
 
 There is a potential practical consequence of not advertising an
 init alternative during setup. It makes users less likely to be
 aware of it, or even aware that the init system has changed.
 
 New users do not need to be be aware of all the background to the
 choosing of a default init. No advertisement is needed. By definition,
 they do not care. They want Debian. Please let them have it.
 
 They will not care by definition only if they are not aware of the
 change, and most won't be aware unless they are informed during the
 installation.
 
 They won't know they lost the choice they didn't know they
 had. Capisce?
 
 What choice have they lost?
 
 They lost an *informed* choice. I think the installation program
 should not take sides but just inform the user. A choice that the
 user is not aware of is the same as no choice, and is potentially
 coercive and disrespectful. It makes Debian seem partial to Red
 Hat's business plan to take over the Linux ecosystem.
 
 If you care so much about Redhat code, maybe you should document
 yourself, and see there pay coders for glibc, gcc, the kernel ( a
 ton of them, according to lwn and linux fundations reports ), on
 coreutils, gnome, kde, php, python, openssh, etc, etc.
 
  Whatever it was, it didn't exist as you imply
  in Wheezy.
 
 It wasn't an issue in Wheezy because the default init option had not
 changed from the previous release, and any release before that.
 
 They won't know, that is, until it bites them somewhere down the
 line. Then they won't know where to look or who to blame, and will
 blame Debian.
 
 What bites them?
 
 Individually, probably something that requires sysvinit or one many
 core services that got replaced. Collectively, getting trapped by
 vendor lock-in.
 
 You keep using those words, but you do not seems to use them correctly.
 If the same system is present on more than one distributio, that's not
 vendor lock-in since you can switch distribution and then reuse the same
 system.
 
 I meant that one vendor seeks to control the Linux ecosystem.
 Whether that plan is viable or even sane, is another issue, but I
 am not eager to see if their plan will succeed or be a guinea pin
 in the experiment.
 
 As much as I dislike systemd, I'm not sure that it's a vendor
 conspiracy to control the Linux ecosystem.  Yes, redhat pays
 Lennart Poettering's salary (among others).  But... I'm hard pressed
 to see how turning a collection of free distros into functional
 equivalent's of redhat, or increasing the resources applied to free
 distros, is really to their benefit.  If anything, it would seem to
 dilute the competitive advantage of paid RHEL.
 
 Personally, I think it's more a matter of one, prima donna
 developer, who has the advantage of a salary, who has a vision and
 design philosophy that he's promoting in a very aggressive and
 single minded way.  And he's very overt about it.  (Somebody posted
 an email from Poettering last week saying, roughly, 'first we're
 going to get kdbus into the kernel, then we're going to make udev
 depend on it, and then everyone will have to eat systemd to get
 udev.'  As I recall, the message closed with 'gentoo, be warned.')
 
 I figure this is more a case of redhat management not wanting to
 tick off valued prima donna, and maybe seeing what he's doing as a
 contribution to the open source community (to date, redhat has been
 pretty good about contributing to the community in lots of different
 ways).  Still,  if I were in their shoes, I'd be trying to reign the
 guys in. 

Why would the management of a external company care about what 
happen in Debian ? 
People keep wanting the project to be free of corporate influence, but 
it seems that some wouldn't be against having a bit of corporate influence if 
the
influence was in the way they want..

 Given that RHEL's main selling points are enterprise
 capabilities, quality control, and (for the government market)
 security accreditation and lots of support, I'd much rather see
 diversity and weak code spread across competing distributions.

Canonical was criticized for keeping their code for their ( mir, unity ),
and Redhat would be criticized for not keeping the code only for them. 

I guess there is no good way for a company to make free software that
change something in the core of existing ecosystem.

--

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Miles Fidelman


Andrei POPESCU wrote:

On Sb, 15 nov 14, 11:37:14, Miles Fidelman wrote:

For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Have you considered, just for a fraction of a second, that a migration
to systemd, however painful it may prove, could in fact make your setup
much more reliable and understandable?




Let me also turn the question back at you:

Have you considered, just for a fraction of a second, that a migration
to systemd, could, in fact, make some systems LESS reliable and understandable?


But in answer to your question:

Sure.

For a long time, I just assumed that Jessie would be an improvement on 
Wheezy (otherwise, why release a new version), and like previous 
releases, it would be largely backwards compatible, have some bugs 
resolved, some security holes tightened, and offer some new features 
that might or might not be of interest.  To the extent that I thought 
about systemd at all, it was to the same degree as I think of any other 
core system service - it's there, it works, nothing to see here.


Then, I became aware of how many basic system services were being 
incorporated into the systemd collection of stuff, and how many other 
things it touched (like, for example, PAM - which I use extensively), 
and logging, and so on.


And then I started reading the (conflicting) documentation, such as 
there is, describing all the things I'd have to test, change, watch out 
for when it came to rebuilding our servers on top of Jessie. Followed by 
reading about the design, philosophy, approach, and agenda of its 
developers - in their own words, in their own emails, and on their own 
blogs.  And then, I started seeing the reactions of the developers and 
apologists to legitimate criticisms and concerns.


I've sat through an awful lot of design reviews for software and system 
projects, on both sides of the table, and personally, I would have 
killed this thing early in its life.  Joel Rees has this exactly right, 
this has all the signs of a death march project, not just for Debian but 
for large chunks of the Linux ecosystem.


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5468c040.6040...@meetinghouse.net

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Du, 16 nov 14, 10:18:24, Miles Fidelman wrote:
 
 Let me also turn the question back at you:
 
 Have you considered, just for a fraction of a second, that a migration
 to systemd, could, in fact, make some systems LESS reliable and 
 understandable?

Sure I did. systemd is not bug-free and it's approach is different, so 
it does require learning before understanding it.

However, I fail to see any significant difference compared to any other 
major change I've been through since using Debian.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sun, Nov 16, 2014 at 09:43:23PM +0900, Joel Rees wrote:
 I have been informed off-list that some might misinterpret something I
 wrote here, so I will attempt to clarify a few things.
 
 On Fri, Nov 14, 2014 at 8:59 AM, Joel Rees joel.r...@gmail.com wrote:
  On Thu, Nov 13, 2014 at 11:04 PM, Tanstaafl tansta...@libertytrek.org 
  wrote:
  On 11/12/2014 5:18 PM, Andrei POPESCU andreimpope...@gmail.com wrote:
  On Mi, 12 nov 14, 15:43:09, Tanstaafl wrote:
 
  Sounds good to me, but in reality, since the default *and only* init
  system for the last very many years was Sysvinit (this extremely salient
  point seems to be completely and totally lost on the systemd
  proponents), I think only systemd and sysvinit need to be there... but
  allowing for additions once required bugs implementing them are resolved
  as fixed.
 
  You're forgetting about:
 
  It doesn't matter Andrei...
 
  1. The *default* is what we are discussing.
 
  The *default* for Debian has been sysvinit since - forever?
 
  2. The systemd proponents pushed to make systemd the *new* default - a
  massively major change from *all* previous releases since... forever?
 
  3. A bug was opened to allow for the ability to allow a clean install to
  be performed with systemd on wheezy, while sysvinit was still the default.
 
  It should have been made mandatory that the systemd folks get this bug
  fully resolved and functional *on wheezy*, *and* commit to maintaining
  this ability in jessie, as a pre-condition to even getting the question
  of a change of the default init system for jessi on the ballot.
 
  Anything else, as I said, makes no sense.
 
  To explain to the systemd advocates who refuse to understand the
  engineering questions, this is the real engineering mistake in
  systemd.
 
  The engineering question keeps getting sidetracked by people who
  assert that we are talking about technical details, and then proceed
  to question (foolishly) the necessity of modularity, or (rightly) the
  meaning of modularity, etc. That all was and is still relevant, but if
  proper engineering principles had been followed in bringing systemd
  in, the open development practices our larger community claims as its
  reason for existence would have taken care of the technical details.
 
  Maybe it would help if I said, engineering management, instead of
  just engineering, although you really can't separate management from
  engineering.
 
 This person says that I have misrepresented the Fedora community's
 reaction in my description of events.

And you still do. Proofreading and giving links is not so hard, but way harder 
if
that mean discovering that you may base your ideas on wrong premises.
 
 This is not an attempt to be a linear history of systemd adoption in
 Fedora. It is simply intended as a few of my observations there when I
 was a user, and from here in the two years since I left.
 
  It was clear much longer than four years ago how deeply the changes
  would effect the infrastructure which defines the system, and on which
  the stability of the system depends. Every daemon package would be
  effected, even if the systemd project had restrained themselves to
  working only on the init part of the infrastructure. Every daemon
  package needed to be fixed to the new interface, and tested under it.
  (Many still need that.)
 
 This is not disparaging, it is acknowledging reality. If I were to
 develop an alternative init, add full daemon/service management, tie
 it to device management, login management, error logging, etc., the
 result would impose the same level of re-implementation and testing
 burden across the OS.
 
 I wouldn't do it that way, of course, but that's the level of
 engineering cost the approach they take incurred.

You say that every daemon need to be fixed for the new interface, but
then either things are broken, and so, you should be able to show bugs reports
( from mageia, from arch, from opensuse ), or they are not and so
you cannot really show they are not broken.

It was a explicit goal of system to still support regular scripts, and
there isn't a flood of debian bug reports to say that it not working.

 
  They didn't, of course they didn't,
 
 ... restrain themselves, that is.
 
  they've admitted many times that
  the init system was not their ultimate target.
 
 Links to Poetterings blog have been posted. It's hard to assume that
 he was intending to speak in the absurd, or that he was
 misrepresenting the goals of the project he leads.
 
  Therefore, every package that uses or provides authentication got
  entangled in the changes and needed both careful editing and extensive
  testing. The testing is still to be completed, because we are not
  talking about context-free grammar simplicity here in any of the
  parts.
 
 I know that the systemd proponents want to claim that testing is
 almost finished,

Give links.

because no software is ever finished, so no testing can be complete unless 
you stop changing

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Miles Fidelman


Andrei POPESCU wrote:

On Du, 16 nov 14, 10:18:24, Miles Fidelman wrote:

Let me also turn the question back at you:

Have you considered, just for a fraction of a second, that a migration
to systemd, could, in fact, make some systems LESS reliable and understandable?

Sure I did. systemd is not bug-free and it's approach is different, so
it does require learning before understanding it.

However, I fail to see any significant difference compared to any other
major change I've been through since using Debian.



I guess that we have different ideas of major change.


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5468d2ff.5020...@meetinghouse.net

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Ric Moore


On 11/15/2014 08:35 PM, Ludovic Meyer wrote:


At the same time, most debian users likely do not really care about transition
plan and systemd. It was widely published everywhere in March and yet, no one 
would have cared if this
mattered ?


I installed systemd to Jessie as soon as it was announced. No problems 
so far. I'm happy. :) Ric



--
My father, Victor Moore (Vic) used to say:
There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome. R.I.P. Dad.
Linux user# 44256


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5468d844.5070...@gmail.com

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Marty


On 11/16/2014 05:26 AM, Laurent Bigonville wrote:

Le Sat, 15 Nov 2014 20:21:49 -0500,
Marty mar...@ix.netcom.com a Ã©crit :


On 11/15/2014 06:49 AM, Andrei POPESCU wrote:

[...]


 At least some of people rejecting systemd demand that it be removed
 completely, including libsystemd. How is it pro-choice to forbid me
 from being able to use a software at its full potential?

For me it's more about being unable to remove it completely, because
of vendor lock-in. There's no technical reason that I know of that
anything in userspace cannot modular, and replaceable, so when
something cannot be replaced then an alternative must be provided, or
else my default assumption is that vendor lock-in is in effect.


Well, yes there are technical reasons why you cannot remove a library
package when you have symbols provided by this library used in an
executable. You can still recompile the package and remove some
configure flag if you want to remove this dependency.

OTHO there is no technical reasons that I can see, to completely remove
libsystemd package. You have tenth of other libraries on your system
that, like libsystemd, turn them self into a noop if some some
functionality or daemon are not enable. I'm thinking here for example
about libselinux and libaudit (both also written by Red Had and the
NSA, OMG!!!11), and yet I fail to see any outcry here...

So as long as you cannot _prove_ that having libsystemd installed on
your machine is causing any issues, I'll personally mentally classify
your request as I don't want to see any packages containing the
systemd string on my machine and redirect these to /dev/null.


Except that proponents seem more prone to avoiding the hairball issue by 
just covering their eyes. ;)


My point is that in a modular design nothing should be so entrenched as 
to be irreplaceable. Absence of an alternate should not normally 
indicate impossibility of an alternate, but some discussions I've read 
about logind, udev and dbus are enough to raise serious concerns.


People who just say, write your own, it's all FOSS are missing the 
point, I think. Debian is not one guy working in his mom's basement. 
It's one of the world's largest software projects. When Debian is 
stumped, because its best developers and upstreams are caught in the 
entanglement hairball, and see no clear way out, the it's clear case of 
*Houston we have a problem.*



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5468e754.4020...@ix.netcom.com

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread The Wanderer

On 11/16/2014 at 11:23 AM, Ludovic Meyer wrote:

 On Sun, Nov 16, 2014 at 09:43:23PM +0900, Joel Rees wrote:
 
 I have been informed off-list that some might misinterpret
 something I wrote here, so I will attempt to clarify a few things.
 
 On Fri, Nov 14, 2014 at 8:59 AM, Joel Rees joel.r...@gmail.com
 wrote:

 This all would have been okay for them, if they had followed
 proper engineering (management) principles. As long as they were
 an independent maverick, they could do what they want. That was
 correct, that was good.
 
 I want to repeat that. As long as they kept their work out of the
 mainstream, it was no problem.
 
 Your definition of mainstream is strange. So far, I didn't see
 systemd being on something else than Linux, and GNU/Linux is not
 mainstream ( android is, but systemd is out of android ).
 
 So they kept it out of mainstream, unless you define mainstream as
 being used by users, in which way I would love to see how you get
 user feedback without having users in the first place.

I suspect that he meant the mainstream of Linux, which is reasonable
considering the scope of the discussion.

 They could refine their API as they went and the repercussions were
 limited to their own source tree. That means they could redefine
 the API as necessary without interfering with the day-to-day
 operations of thousands, or even hundreds of thousands of users.
 
 The more users you have, the harder it is to fix an API error.
 
 yeah, and that's why there is a table : 
 http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

  now, the linux kernel do not have such table, and prevent anyone
 from writing a out of kernel module due to that, despites requests.

One important distinction:

The Linux kernel recognizes and maintains a separation between internal
and external interfaces.

They refuse to stabilize and fix on, or I think even particularly to
document (beyond the source code itself), the internal interfaces. Doing
so would constrain them from making structural and design improvements
when and as they think that is necessary.

They do, however, maintain their external interfaces - rigidly so,
sometimes to what others might call the point of insanity. An
intentionally user-visible API from the Linux kernel will essentially
never change, and if an exception to that is ever made, it will be
announced *years* in advance. That is one reason why they try to be
*VERY* careful to get the user-facing interface right, at least on
some basic level, before ever pulling it into a released kernel.

The kernel interfaces which kernel modules need to use are
kernel-internal interfaces.

The systemd interfaces described on the page you link to appear to be
systemd-external interfaces.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sun, Nov 16, 2014 at 01:28:35PM -0500, The Wanderer wrote:
 On 11/16/2014 at 11:23 AM, Ludovic Meyer wrote:
 
  On Sun, Nov 16, 2014 at 09:43:23PM +0900, Joel Rees wrote:
  
  I have been informed off-list that some might misinterpret
  something I wrote here, so I will attempt to clarify a few things.
  
  On Fri, Nov 14, 2014 at 8:59 AM, Joel Rees joel.r...@gmail.com
  wrote:
 
  This all would have been okay for them, if they had followed
  proper engineering (management) principles. As long as they were
  an independent maverick, they could do what they want. That was
  correct, that was good.
  
  I want to repeat that. As long as they kept their work out of the
  mainstream, it was no problem.
  
  Your definition of mainstream is strange. So far, I didn't see
  systemd being on something else than Linux, and GNU/Linux is not
  mainstream ( android is, but systemd is out of android ).
  
  So they kept it out of mainstream, unless you define mainstream as
  being used by users, in which way I would love to see how you get
  user feedback without having users in the first place.
 
 I suspect that he meant the mainstream of Linux, which is reasonable
 considering the scope of the discussion.

Sure, and what does he mean by that ?

because I suspect also that Android, being Linux based, is not the mainstream
he is speaking about. So is Debian more mainstream that Ubuntu ? Is Debian
more mainstream than Mageia or Opensuse ?

if he want to be clearly understood, and I think we all want that, he must
be a bit more clearer in what he say. 
 
  They could refine their API as they went and the repercussions were
  limited to their own source tree. That means they could redefine
  the API as necessary without interfering with the day-to-day
  operations of thousands, or even hundreds of thousands of users.
  
  The more users you have, the harder it is to fix an API error.
  
  yeah, and that's why there is a table : 
  http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
 
   now, the linux kernel do not have such table, and prevent anyone
  from writing a out of kernel module due to that, despites requests.
 
 One important distinction:
 
 The Linux kernel recognizes and maintains a separation between internal
 and external interfaces.
 
 They refuse to stabilize and fix on, or I think even particularly to
 document (beyond the source code itself), the internal interfaces. Doing
 so would constrain them from making structural and design improvements
 when and as they think that is necessary.

I know the arguments, but this doesn't contradict the fact that there is
demand for such interfaces. This is also something that windows, solaris 
or mac osx offer, and that help hardware vendors to support
their systems, and companies to offer software (firewall, antivirus
are the example that came to mind, but i am not dealing with
windows anymore).

Now, that's indeed a costly approach due to the reduced agility, 
and while I am sure this can be surely automated, I can see why 
kernel coders do not want to take care of that ( coders in general
would prefer not care of boring stuff and constraints, as we
can see in the free software world, who is hard to consume unless you
have group between users and coders to make thing usable ).

 They do, however, maintain their external interfaces - rigidly so,
 sometimes to what others might call the point of insanity. An
 intentionally user-visible API from the Linux kernel will essentially
 never change, and if an exception to that is ever made, it will be
 announced *years* in advance. That is one reason why they try to be
 *VERY* careful to get the user-facing interface right, at least on
 some basic level, before ever pulling it into a released kernel.
 
 The kernel interfaces which kernel modules need to use are
 kernel-internal interfaces.
 
 The systemd interfaces described on the page you link to appear to be
 systemd-external interfaces.

I know the difference, and
I know this is just some tradeoff, there is advantages and 
disadvantages on doing that, and if I was cynical, I would
postulate that companies like redhat do push for that model of 
internal/external 
interfaces in the kernel, because this give a reason to take 
entreprise distributions. ( ie, SLES, RHEL do have a stable promise API 
for each release like Windows do, because customers do pay also for that )

My point is not that kernel or systemd devs are right or wrong.
But the point is that people who complain that systemd do not have a internal 
interface yet forget that kernel do not have one since the start and will not 
have
in a near future. 

And this, despites having (IMHO) a bigger need  for
a internal interface of the kernel than one for systemd. 
By bigger needs, I mean that there is a lot more of people wanting to 
have out of tree modules, while I guess we wouldn't see more than 5 
differents reimplementation of some systemd components.
( and again,

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote:
 On 11/16/2014 05:26 AM, Laurent Bigonville wrote:
 Le Sat, 15 Nov 2014 20:21:49 -0500,
 Marty mar...@ix.netcom.com a Ã©crit :
 
 On 11/15/2014 06:49 AM, Andrei POPESCU wrote:
 [...]
 
  At least some of people rejecting systemd demand that it be removed
  completely, including libsystemd. How is it pro-choice to forbid me
  from being able to use a software at its full potential?
 
 For me it's more about being unable to remove it completely, because
 of vendor lock-in. There's no technical reason that I know of that
 anything in userspace cannot modular, and replaceable, so when
 something cannot be replaced then an alternative must be provided, or
 else my default assumption is that vendor lock-in is in effect.
 
 Well, yes there are technical reasons why you cannot remove a library
 package when you have symbols provided by this library used in an
 executable. You can still recompile the package and remove some
 configure flag if you want to remove this dependency.
 
 OTHO there is no technical reasons that I can see, to completely remove
 libsystemd package. You have tenth of other libraries on your system
 that, like libsystemd, turn them self into a noop if some some
 functionality or daemon are not enable. I'm thinking here for example
 about libselinux and libaudit (both also written by Red Had and the
 NSA, OMG!!!11), and yet I fail to see any outcry here...
 
 So as long as you cannot _prove_ that having libsystemd installed on
 your machine is causing any issues, I'll personally mentally classify
 your request as I don't want to see any packages containing the
 systemd string on my machine and redirect these to /dev/null.
 
 Except that proponents seem more prone to avoiding the hairball
 issue by just covering their eyes. ;)
 
 My point is that in a modular design nothing should be so entrenched
 as to be irreplaceable. Absence of an alternate should not normally
 indicate impossibility of an alternate, but some discussions I've
 read about logind, udev and dbus are enough to raise serious
 concerns.

The problem is that, without any action, the difference between nothing 
can be replaced and it can be replaced is purely theorical. Now you 
can discuss for years in theory, if this doesn't result in any practical
outcome, you have just stresstested the mailling lists software.
 
 People who just say, write your own, it's all FOSS are missing the
 point, I think. Debian is not one guy working in his mom's basement.
 It's one of the world's largest software projects. When Debian is
 stumped, because its best developers and upstreams are caught in the
 entanglement hairball, and see no clear way out, the it's clear case
 of *Houston we have a problem.*

That's a interesting point, because with all those brillant minds, 
a vast majority do not even seems to care about this 
entanglement hairball. Maybe it is time to admit you do not
know the whole details and accept that if developpers do not care, 
then they are maybe right in doing so ?

Especially since you have been unable to give any technical reasons
to why you do not want it, and how you would proceed.
 
In fact, a quick google check would even give you the required
knowledge of why it is better to link :
http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html

You can compare the code with link to systemd library vs cut and
paste in every source code. As a exercise, you can
surely add use dlopen() and see which one is simpler and easier to maintain
in the long term.

Then it will be your turn to explain why it is better to cut and paste or 
link statically the library, or why it is better to have to patch every 
upstream 
to use dlopen().

And once you will have been able to justify that on a technical level,
maybe people will start to listen to you. 

For the record, see also the discussion on 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555980

-- 
l.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116203224.gg25...@gmail.com

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread The Wanderer

On 11/16/2014 at 02:51 PM, Ludovic Meyer wrote:

 On Sun, Nov 16, 2014 at 01:28:35PM -0500, The Wanderer wrote:

[about the Linux kernel developers]

 They do, however, maintain their external interfaces - rigidly so,
 sometimes to what others might call the point of insanity. An 
 intentionally user-visible API from the Linux kernel will
 essentially never change, and if an exception to that is ever made,
 it will be announced *years* in advance. That is one reason why
 they try to be *VERY* careful to get the user-facing interface
 right, at least on some basic level, before ever pulling it into
 a released kernel.
 
 The kernel interfaces which kernel modules need to use are 
 kernel-internal interfaces.
 
 The systemd interfaces described on the page you link to appear to
 be systemd-external interfaces.
 
 I know the difference, and I know this is just some tradeoff, there
 is advantages and disadvantages on doing that, and if I was cynical,
 I would postulate that companies like redhat do push for that model
 of internal/external interfaces in the kernel, because this give a
 reason to take entreprise distributions. ( ie, SLES, RHEL do have a
 stable promise API for each release like Windows do, because
 customers do pay also for that )
 
 My point is not that kernel or systemd devs are right or wrong. But
 the point is that people who complain that systemd do not have a
 internal interface yet forget that kernel do not have one since the
 start and will not have in a near future.

Er... were people complaining that systemd does not have a stable
internal interface?

I thought (given the context of that linked-to page) that the complaint
was that systemd does not have a stable *external* interface.

With possible room for dispute about what constitutes an interface,
what qualifies as stable, and maybe even what counts as internal vs.
external... but I didn't see anything that I recognized as being a
complaint about systemd's internal interfaces.

No one is even trying to implement something outside of the systemd
project that talks to systemd's internal interfaces directly, AFAIK -
unless systemd-shim does, but I didn't think systemd-shim talked to
systemd itself at all, just to other tools provided by the systemd
project.

And if the interfaces which those tools use to talk to
systemd-the-init-system are considered internal interfaces, which is a
position for which an argument could be made, then that would simply
bring up the argument that since those are separate tools the interfaces
between them should be considered external to each tool. Whether or not
that's a reasonable argument, and the extent to which it might be
possible to treat those interfaces that way, could be a discussion worth
having - but having it would require *getting* to that point first.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Joel Rees

One thing at a time.

On Mon, Nov 17, 2014 at 1:23 AM, Ludovic Meyer ludo.v.me...@gmail.com wrote:
[...]
Your definition of mainstream is strange.

What's strange about it? Do I need to provide a link to the dictionary
for you for that? I assume not.

Given a community, there is a mainstream within that community.

We have a community of users of Linux-kernel OSses that provide,
without excessive effort, command-line shells, full C compiler suites,
administrator access to the device owner, etc.

(Sure, Android has No-root Debian and Terminal-IDE, but those are
third-party apps and don't give true administrator access. The sdk is
not something mainstream Android users can figure out without a lot of
effort, and takes a separate machine. Thus, Android is outside the
domain of discussion, and I shouldn't have had to explain why. Unless
you think that Linux OSses should start limiting the device owner from
doing things like adding users and changing the unit infrastructure,
in which case, the reason we can't communicate is clear.)

Now, you note that Fedora claims in the range of a million users. Even
if their estimates are an order of magnitude high, that's hundreds of
thousands.

How can that not be mainstream?

Or are you under the misapprehension that there is only one
mainstream? Fedora and Debian are the mainstreams of what most of us
consider the Linux community. (Ubuntu being part of the greater Debian
community and Cent being part of the greater Fedora community.)

Now, before you throw up any more quibbles, what I am talking about
when I say mainstream users is those users who have not specifically
chosen to be part of an experiment who are being dragged into an
experiment.

Except you'll now point out that Fedora is the cutting edge of Red
Hat's stuff, which is ignoring the issue. And Fedora has rawhide, and
Debian has sid, which is ignoring the issue.

sid is locked into the future of stable, just like Rawhide is locked
into the future of Fedora. The release schedule does not allow for
major changes to be unrolled easily. Anything that gets accepted into
sid and passes into testing gets into stable, unless a lot of people
get excited during the testing phase.

Now, is systemd a major change or isn't it?

If you ask Poettering when he wants to sell systemd, it's a MAJOR
improvement. If you ask systemd proponents when they are sandbagging,
NO! NO! It's NOT a major change. (Sorry about the shouting, I'm just
describing how it looks to me. It does look like you guys are being
emphatic.)

If it's a major change, it needs more time, and, I'm asserting, the
special handling of a temporary parallel fork.

If it's not a major change, why do we have problems like the problem
of installing other inits?

[...]

--
Joel Rees

Be careful when you look at conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself, as well.

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAAr43iNJ8-+tDvqyXzHGm8Zhn6n41vOirSy-=tl2ux0gid8...@mail.gmail.com

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-16 Thread Marty


On 11/16/2014 03:32 PM, Ludovic Meyer wrote:

On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote:

snip

My point is that in a modular design nothing should be so entrenched
as to be irreplaceable. Absence of an alternate should not normally
indicate impossibility of an alternate, but some discussions I've
read about logind, udev and dbus are enough to raise serious
concerns.


The problem is that, without any action, the difference between nothing
can be replaced and it can be replaced is purely theorical.


The problem is very real, but there seems to be no agreement about 
solutions, which by itself is evidence of a problem.


  Now you

can discuss for years in theory,


In fact, people have been discussing this problem for years.

  if this doesn't result in any practical

outcome, you have just stresstested the mailling lists software.


Until there's a rough consensus and a clear way forward, I don't think 
many people will commit to specific solutions. There are also unknowns 
like kdbus, to further complicate the matter.



People who just say, write your own, it's all FOSS are missing the
point, I think. Debian is not one guy working in his mom's basement.
It's one of the world's largest software projects. When Debian is
stumped, because its best developers and upstreams are caught in the
entanglement hairball, and see no clear way out, the it's clear case
of *Houston we have a problem.*


That's a interesting point, because with all those brillant minds,
a vast majority do not even seems to care about this
entanglement hairball. Maybe it is time to admit you do not
know the whole details and accept that if developpers do not care,
then they are maybe right in doing so ?

Especially since you have been unable to give any technical reasons
to why you do not want it, and how you would proceed.


For you, I would start by explaining the Unix Philosophy and how it is a 
critical aspect of Debian's design:


http://en.wikipedia.org/wiki/Unix_philosophy

Then I would proceed to explain how various aspects of systemd conflict 
with this, causing said hairball. Finally, I would explain (to the best 
of my ability) how the entanglement issue precludes a quick resolution, 
and the delay does not indicate lack of interest.



In fact, a quick google check would even give you the required
knowledge of why it is better to link :
http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html

You can compare the code with link to systemd library vs cut and
paste in every source code. As a exercise, you can
surely add use dlopen() and see which one is simpler and easier to maintain
in the long term.

Then it will be your turn to explain why it is better to cut and paste or
link statically the library, or why it is better to have to patch every upstream
to use dlopen().


Not sure how we went from entanglement issues to PID tracking, but 
granting your point, it still doesn't explain how we arrive at kdb, 
console and qcodes in PID 1. :)



And once you will have been able to justify that on a technical level,
maybe people will start to listen to you.

For the record, see also the discussion on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555980


You did not make much of a case for a complex PID 1 process, and on that 
question I defer to a kernel dev who takea a rather dim view of it: 
http://lwn.net/Articles/618024/




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54694f78.6090...@ix.netcom.com

Re: Installing an Alternative Init?

On Vi, 14 nov 14, 07:55:23, Miles Fidelman wrote:
 
 Note that there seems to be an ongoing issue with whether or not the
 installer will issue a warning before a package dependency leads to an

 automatic change to systemd.  See bugs 765803 and 762194.

installer usually means Debian Installer (i.e. the thing that installs 
Debian from scratch), you probably meant package manager, which means 
(dist-)upgrades.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Vi, 14 nov 14, 13:27:22, Helmut Wollmersdorfer wrote:
 
 And all this says nothing about big servers, which need some 
 magnitudes more of reliability, stability and scaling. E.g. not using 
 plain text files for logs causes problems in the long run and in daily 
 work.

The default setting for the Debian systemd package is to forward all 
messages to your syslog and rsyslog is still installed by default.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Vi, 14 nov 14, 08:04:00, Marty wrote:
 On 11/14/2014 05:26 AM, Andrei POPESCU wrote:
 On Vi, 14 nov 14, 08:59:11, Joel Rees wrote:
 snip
 
 Jumping in here as myself, not Joel's tag-team member. :)
 
 Debian as an entity doesn't really do much. There are only one or
 several volunteers who start doing things. Setting up a separate port
 for systemd would have been a major waste of resources (both human and
 hardware) with no real gain.
 
 By the same token systemd is a major waste with no real gain. It duplicates
 equivalent modular alternatives, and also requires unnecessary effort to
 repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates 
systemd's features with a combination of other software.

http://0pointer.de/blog/projects/why.html

 You are completely dismissing the work of Debian Developers who *did*
 have a very good look at the options and decided switching to systemd is
 doable and would be a good thing from a *technical* point of view.
 
 Non-responsive to his argument. If the work was biased and over-optimistic
 then it doesn't matter how much they looked at it.
 
This argument cuts both ways :)
 
 However, you and several others are rejecting systemd on ideological
 grounds. There's not much that can be done about that, short or
 re-implementing systemd according to your vision.
 
 Many others reject choice and the anti-choice stance is the ideological
 position at issue here. It is in direct conflict with Debian policy.
 The systemd upstream are the ones with vision, ideology, rejecting
 opponents as haters in an overt campaign to establish a Linux monopoly.
 They have a financial interest in *psychological projection* of this kind. I
 still cannot see what Debian stands to gain by jumping on their marketing
 bandwagon.
 
At least some of people rejecting systemd demand that it be removed 
completely, including libsystemd. How is it pro-choice to forbid me from 
being able to use a software at its full potential?

 I hope you do understand why neither the systemd developers, maintainers
 or users have any interest whatsoever in doing that.
 
 But upstreams have other interests, like establishment of a Linux monopoly
 via tying and customer lock-in. Why should there not be a rational effort to
 counter that?
 
In my opinion the best defence against a monopoly[1] of any kind is to 
develop competitive alternatives.

[1] which I don't believe applies, but will ignore for the moment.

After all, systemd
 already works fine for them.
 
 Windows already works fine for most people, and it is consistent with the
 anti-choice philosophy, so why bother with Linux at all?

Doesn't work fine for me. At $dayjob I'm forced to use it and I can tell 
you my private laptop with a Dual Core 1,8 GHz and 2 GB RAM runs circles 
around a Core i5 with Windows 7. But this is off-topic for d-u.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Vi, 14 nov 14, 22:53:36, Joel Rees wrote:
 On Fri, Nov 14, 2014 at 7:26 PM, Andrei POPESCU
 andreimpope...@gmail.com wrote:
  On Vi, 14 nov 14, 08:59:11, Joel Rees wrote:
   [...]
  [snip another wall of text about engineering principles]
 
 And, thus, once again,
 
   The engineering question keeps getting sidetracked by people who
   assert that we are talking about technical details, [...]
 
 If you can't deal with it, snip it?

I don't think it brings anything useful to a discussion on -user. That's 
much more suitable for some init-systemd-devel list.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-15 Thread Ron

On Sat, 15 Nov 2014 13:49:18 +0200
Andrei POPESCU andreimpope...@gmail.com wrote:

 In my opinion the best defence against a monopoly[1] of any kind is to 
 develop competitive alternatives.

We have seen how well that worked with MS Windows over the years...
 
Cheers,
 
Ron.
-- 
 Nada es tan peligroso como dejar permanecer
largo tiempo a un mismo ciudadano en el poder.
 El pueblo se acostumbra a obedecer,
y él se acostumbra a mandarlo;
   de donde se origina la usurpación y la tiranía.
  -- Simon Bolivar

   -- http://www.olgiati-in-paraguay.org --
 


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141115091340.4e213...@ron.cerrocora.org

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:

 On Vi, 14 nov 14, 08:04:00, Marty wrote:
  
  By the same token systemd is a major waste with no real gain. It duplicates
  equivalent modular alternatives, and also requires unnecessary effort to
  repair damage from excessive coupling.
 
 I challenge you to come up with a configuration that duplicates 
 systemd's features with a combination of other software.

One picture is worth a thousand words.

   https://np237.livejournal.com/34598.html

(Sorry, couldn't resist).


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/15112014121345.2e551aff5...@desktop.copernicus.demon.co.uk

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Vi, 14 nov 14, 08:55:47, Tanstaafl wrote:
 On 11/14/2014 5:26 AM, Andrei POPESCU andreimpope...@gmail.com wrote:
  It was claimed that sysvinit was the default *and only* (emphasis not 
  mine) init, and therefore no selection was needed, but now that there 
  are several a selection suddenly is needed.
 
 I don't recall claiming that sysvinit was the *only* init, nor do I
 recall anyone else making such a claim.

https://lists.debian.org/debian-user/2014/11/msg00814.html
Maybe a language issue? (I'm not a native speaker).
 
 My very simple point is and has been that, *because* the *default* init
 system for debian has been sysvinit since anyone can apparently
 remember, the very act of even *suggesting* that it be switched in
 jessie to not only a *different*, but a (relatively) *very new* one,
 should have invoked a very simple requirement - for which the
 responsibility for implementation and maintenance would be on those
 calling for the switch - to provide a means for easily switching back
 and forth so that everyone else could easily test things, and
 ultimately, after the release of jessie with the new default, provide a
 means to easily choose the previous default installer at both update
 *and* install time, and maintain such at *least* during the life of the
 jessie (if not jessie+1).

For fresh installs, given that there is a suitable[1] workaround the 
incentive to fix the bug[2] so late in the release cycle is low, as it 
might introduce other breakage.

[1] so far the only claims against that workaround have been of the sort 
I don't want systemd anywhere near my systems, without actual proof of 
something going wrong.

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001

For dist-upgrades, even assuming systems will be switched automatically 
(which is still undecided):

- one can prevent switching by installing sysvinit-core before the 
  dist-upgrade step
- the sysvinit package contains the binary /lib/sysvinit/init which can 
  be used with the init= kernel parameter
- there is a grub patch[3] pending integration[4] to offer an 
  alternative sysvinit boot option

[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757298
[4] https://lists.debian.org/debian-ctte/2014/10/msg00057.html 

The transition plan[5] has been posted on -devel since July with no 
objections.

[5] https://lists.debian.org/debian-devel/2014/07/msg00611.html

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-15 Thread Joel Rees

On Sat, Nov 15, 2014 at 9:20 PM, Andrei POPESCU
andreimpope...@gmail.com wrote:
 [(clipping too much, I now realize)]
 The transition plan[5] has been posted on -devel since July with no
 objections.

 [5] https://lists.debian.org/debian-devel/2014/07/msg00611.html

My impression is that objections logged to that thread, had there been
any, would have been to the method or timing, not to the switch
itself.

In other words, members of dev who disagreed to the switch itself
would have needed a different thread to register their continued
disagreement.

And I am under the impression that there was an undercurrent of
object to this and lose your geek cred.

-- 
Joel Rees

There is one conspirator against you,
that has not changed.
The only question is whether you will participate
or turn your back to it.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caar43inl1sxtpndpprn4twa4zpfijoq6b9pzrfrpb5oyo6m...@mail.gmail.com

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-15 Thread Joel Rees

On Sat, Nov 15, 2014 at 8:51 PM, Andrei POPESCU
andreimpope...@gmail.com wrote:
On Vi, 14 nov 14, 22:53:36, Joel Rees wrote:
On Fri, Nov 14, 2014 at 7:26 PM, Andrei POPESCU
andreimpope...@gmail.com wrote:
On Vi, 14 nov 14, 08:59:11, Joel Rees wrote:
[...]
[snip another wall of text about engineering principles]

And, thus, once again,

The engineering question keeps getting sidetracked by people who
assert that we are talking about technical details, [...]

If you can't deal with it, snip it?

I don't think it brings anything useful to a discussion on -user. That's
much more suitable for some init-systemd-devel list.

Re-read the wall of text you deleted, then think again about this suggestion.

If you still don't see how this suggestion is a short-circuit to
ground for objections, I've written a bit more colorfully on the
subject on my general blog, maybe you would care to re-read that as
well.

There's something in this question that is actually entangled in the
difference between declarative and procedural programming, but I can't
really talk with you about it until you start digging in to one or the
other.

--
Joel Rees

Living without understanding programming
is kind of like playing poker without understanding statistics.

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/caar43in2dxjcauqbxm21sb1jahek7a+rxjtr6yvq7y9pvfd...@mail.gmail.com

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-15 Thread Dimitrios Chr. Ioannidis


On 15-11-2014 14:17, Brian wrote:

On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:


On Vi, 14 nov 14, 08:04:00, Marty wrote:

 By the same token systemd is a major waste with no real gain. It duplicates
 equivalent modular alternatives, and also requires unnecessary effort to
 repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.


One picture is worth a thousand words.

   https://np237.livejournal.com/34598.html

(Sorry, couldn't resist).


I couldn't resist also ...

A use case better covered by SysV init: encrypted block devices

  http://tanguy.ortolo.eu/blog/categorie2/debian


Regards,
--
Dimitrios Chr. Ioannidis


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/66dd4e331f467402fea441f4814d6...@nephelae.eu

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sb, 15 nov 14, 22:05:58, Joel Rees wrote:
 On Sat, Nov 15, 2014 at 9:20 PM, Andrei POPESCU
 andreimpope...@gmail.com wrote:
  [(clipping too much, I now realize)]
  The transition plan[5] has been posted on -devel since July with no
  objections.
 
  [5] https://lists.debian.org/debian-devel/2014/07/msg00611.html
 
 My impression is that objections logged to that thread, had there been
 any, would have been to the method or timing, not to the switch
 itself.
 
 In other words, members of dev who disagreed to the switch itself
 would have needed a different thread to register their continued
 disagreement.
 
In my impression Debian is most of the times much *less* formalised than 
this.

What is actually quite frustrating in this particular case (for me as an 
outsider, can't even imagine how it is for people directly involved) is 
how people don't engage in such a thread, but instead escalate to the TC 
and/or GR directly.

 And I am under the impression that there was an undercurrent of
 object to this and lose your geek cred.

Definitely doesn't match my impression.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sat 15 Nov 2014 at 15:22:06 +0200, Dimitrios Chr. Ioannidis wrote:

 On 15-11-2014 14:17, Brian wrote:
 On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:
 
 On Vi, 14 nov 14, 08:04:00, Marty wrote:
 
  By the same token systemd is a major waste with no real gain. It 
  duplicates
  equivalent modular alternatives, and also requires unnecessary effort to
  repair damage from excessive coupling.
 
 I challenge you to come up with a configuration that duplicates
 systemd's features with a combination of other software.
 
 One picture is worth a thousand words.
 
https://np237.livejournal.com/34598.html
 
 (Sorry, couldn't resist).
 
 I couldn't resist also ...
 
 A use case better covered by SysV init: encrypted block devices
 
   http://tanguy.ortolo.eu/blog/categorie2/debian

I'll see you and raise you with a link to a helpful post:

   https://lists.debian.org/debian-user/2014/04/msg01286.html
   https://lists.debian.org/debian-devel/2014/07/msg01048.html


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/15112014145609.e73095746...@desktop.copernicus.demon.co.uk

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-15 Thread Joel Rees

2014/11/15 22:57 Andrei POPESCU andreimpope...@gmail.com:

 On Sb, 15 nov 14, 22:05:58, Joel Rees wrote:
  On Sat, Nov 15, 2014 at 9:20 PM, Andrei POPESCU
  andreimpope...@gmail.com wrote:
   [(clipping too much, I now realize)]
   The transition plan[5] has been posted on -devel since July with no
   objections.
  
   [5] https://lists.debian.org/debian-devel/2014/07/msg00611.html
 
  My impression is that objections logged to that thread, had there been
  any, would have been to the method or timing, not to the switch
  itself.
 
  In other words, members of dev who disagreed to the switch itself
  would have needed a different thread to register their continued
  disagreement.

 In my impression Debian is most of the times much *less* formalised than
 this.

 What is actually quite frustrating in this particular case (for me as an
 outsider, can't even imagine how it is for people directly involved) is
 how people don't engage in such a thread, but instead escalate to the TC
 and/or GR directly.

  And I am under the impression that there was an undercurrent of
  object to this and lose your geek cred.

 Definitely doesn't match my impression.

Well, Brian posted a link to a repurposed graphic of the waiting forever
meme.

And Dimitrios posted a link to a use case that is, indeed, not well covered
by the _current_ (as of the freeze) systemd package.

Sure, if you know the trick, you can get it to go, with some compromise.
Have to encrypt root too or something equally counterintuitive. And I'm
sure they'll get that fixed, too, put the documentation in, get plymouth
set up to no longer be just a splash screen by default, instruct everyone
to encrypt their root partitions or whatever the other part was. Maybe
after the freeze they get whatever requires that second part fixed as well.

What they are selling is a solution to everyone's problems, and they way it
works is that they
provide a solution after we find the problem.

That is not substantially different from the way it was with sysvinit,
except now the systemd crowd are the go-to guys for all things init, where,
before, you had the expertise spread out. There wasn't a single group.

We teach them and they become our experts.

And it works as long as everyone will just do it their way.

Renaud's sig had a rather interesting quote from Simon Bolivar a few posts
up.

Joel Rees

Re: Installing an Alternative Init?


Andrei POPESCU wrote:

On Vi, 14 nov 14, 07:55:23, Miles Fidelman wrote:

Note that there seems to be an ongoing issue with whether or not the
installer will issue a warning before a package dependency leads to an



automatic change to systemd.  See bugs 765803 and 762194.

installer usually means Debian Installer (i.e. the thing that installs
Debian from scratch), you probably meant package manager, which means
(dist-)upgrades.




Yes.  Yes I did.

Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54678169.4030...@meetinghouse.net

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)


Brian wrote:

On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:


On Vi, 14 nov 14, 08:04:00, Marty wrote:

By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.


That assumes that one needs or wants systemd's features.

For some (many?) of us, systemd represents no gain, and significant 
operational impact (time required to deal with changes).


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5467813a.2060...@meetinghouse.net

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-15 Thread Dimitrios Chr. Ioannidis


On 15-11-2014 16:59, Brian wrote:

On Sat 15 Nov 2014 at 15:22:06 +0200, Dimitrios Chr. Ioannidis wrote:


On 15-11-2014 14:17, Brian wrote:
On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:

On Vi, 14 nov 14, 08:04:00, Marty wrote:

 By the same token systemd is a major waste with no real gain. It duplicates
 equivalent modular alternatives, and also requires unnecessary effort to
 repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

One picture is worth a thousand words.

   https://np237.livejournal.com/34598.html

(Sorry, couldn't resist).

I couldn't resist also ...

A use case better covered by SysV init: encrypted block devices

  http://tanguy.ortolo.eu/blog/categorie2/debian


I'll see you and raise you with a link to a helpful post:

   https://lists.debian.org/debian-user/2014/04/msg01286.html
   https://lists.debian.org/debian-devel/2014/07/msg01048.html


Irrelevant ... Read carefullty  ... use case better covered ... 

if systemd requires specific configuration to handle such a case, 
whereas SysV init does not, that means this case is better covered by 
SysV init;


systemd :

[Unit]
Description=Unlock EncFS
DefaultDependencies=no
After=local-fs.target
Before=display-manager.service getty@tty1.service

[Service]
Type=oneshot
RemainAfterExit=true
Environment=RootDir=/home/.encfs/crypt
Environment=MountPoint=/home/crypt
ExecStart=/bin/sh -c systemd-ask-password --no-tty --timeout=30 'Unlock
EncFS' | encfs --stdinpass $RootDir $MountPoint
ExecStop=/bin/umount $MountPoint

[Install]
WantedBy=sysinit.target

This is a specific configuration ...

Any way thx for playing ... ( it was just humor ... )

Regards,
--
Dimitrios Chr. Ioannidis


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/d48be499e67f1d6cc9c3c37f2b0d8...@nephelae.eu

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sat 15 Nov 2014 at 11:37:14 -0500, Miles Fidelman wrote:

 Brian wrote:
 On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:
 
 On Vi, 14 nov 14, 08:04:00, Marty wrote:
 By the same token systemd is a major waste with no real gain. It duplicates
 equivalent modular alternatives, and also requires unnecessary effort to
 repair damage from excessive coupling.
 I challenge you to come up with a configuration that duplicates
 systemd's features with a combination of other software.
 
 That assumes that one needs or wants systemd's features.

I rather think Andrei might not regard this as answering his challenge.
(You also didn't say whether the link's picture made you chuckle :) ).

 For some (many?) of us, systemd represents no gain, and significant
 operational impact (time required to deal with changes).

Fair enough, but working within the realities of a situation is also
part of the deal. The deal for Jessie is systemd. This is not on a take
it or leave basis; quite a lot of work has been put into ensuring the
alternatives you want are there.

We have been here before, so some of what follows is repetition. For
users who feel the same as you it is (AFAIK) the way to get basically
what you want. It cannot be definitive because changes between now and
the release of Jessie are likely to alter the advice.

Upgrading
-

   After changing sources.list and an 'apt-get update' do

 apt-get install sysvinit-core systemd-shim

   Then proceed with an upgrade and dist-upgrade.

New Install
---

   Use the apt-get command above immediately after installation or
   preseed the installation of sysvinit-core and systemd-shim.

Both of these may or may not have an operational impact in individual
cases but (as an outline) they are (AKAIK) the only ways to avoid
systemd-sysv being installed. After that you are on your own, leaving
aside bugs.

I appreciate any major change to a way of working can be stressful but
(without wishing to teach anyone how to do their job) there are ways of
testing which can increase confidence in the provided methods. The
testing also has the added benefit (should there be problems) of
improving on the already large amount of work done within Debian. The
BTS would be the appropriate place to put one's experiences.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141115192449.gn3...@copernicus.demon.co.uk

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-15 Thread Tanstaafl

On 11/15/2014 7:20 AM, Andrei POPESCU andreimpope...@gmail.com wrote:
 On Vi, 14 nov 14, 08:55:47, Tanstaafl wrote:
 On 11/14/2014 5:26 AM, Andrei POPESCU andreimpope...@gmail.com wrote:
 It was claimed that sysvinit was the default *and only* (emphasis not 
 mine) init, and therefore no selection was needed, but now that there 
 are several a selection suddenly is needed.

 I don't recall claiming that sysvinit was the *only* init, nor do I
 recall anyone else making such a claim.
 
 https://lists.debian.org/debian-user/2014/11/msg00814.html
 Maybe a language issue? (I'm not a native speaker).

Nope, that was me and I actually did say it... weird that I didn't
remember saying that... but it doesn't really change anything...

Just because other init systems exist doesn't mean they were actually
being used, other than maybe just someone toying around.

Are you seriously suggesting that anything other than a tiny and
insignificant fraction were using anything other than sysvinit (until
systemd came along at least)?

 For fresh installs, given that there is a suitable[1] workaround

sigh

how many times does it  have to be said - that is not a workaround for a
CLEAN INSTALL.

 For dist-upgrades, even assuming systems will be switched automatically 
 (which is still undecided):
 
 - one can prevent switching by installing sysvinit-core before the 
   dist-upgrade step
 - the sysvinit package contains the binary /lib/sysvinit/init which can 
   be used with the init= kernel parameter
 - there is a grub patch[3] pending integration[4] to offer an 
   alternative sysvinit boot option

Yes, and how long after upgrading to jessie staying with sysvinit until
things start breaking (most likely subtle breakage, which is the least
desirable on a server).

 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757298
 [4] https://lists.debian.org/debian-ctte/2014/10/msg00057.html 
 
 The transition plan[5] has been posted on -devel since July with no 
 objections.

Maybe because most debian *users* don't follow the dev list because they
aren't devs...


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5467bafc.9030...@libertytrek.org

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-15 Thread Erwan David

Le 15/11/2014 20:24, Brian a écrit :
 On Sat 15 Nov 2014 at 11:37:14 -0500, Miles Fidelman wrote:

 Brian wrote:
 On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:

 On Vi, 14 nov 14, 08:04:00, Marty wrote:
 By the same token systemd is a major waste with no real gain. It 
 duplicates
 equivalent modular alternatives, and also requires unnecessary effort to
 repair damage from excessive coupling.
 I challenge you to come up with a configuration that duplicates
 systemd's features with a combination of other software.
 That assumes that one needs or wants systemd's features.
 I rather think Andrei might not regard this as answering his challenge.
 (You also didn't say whether the link's picture made you chuckle :) ).

 For some (many?) of us, systemd represents no gain, and significant
 operational impact (time required to deal with changes).
 Fair enough, but working within the realities of a situation is also
 part of the deal. The deal for Jessie is systemd. This is not on a take
 it or leave basis; quite a lot of work has been put into ensuring the
 alternatives you want are there.


It isq : when you have bugs like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762623
Once said oh it works with systemd, then no more activity on the bug,
nothing.

That means that practically, systemd is de facto compulsory. Not the
default, the only way allowed.

So it is take or leave.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5467c02d.2010...@rail.eu.org

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)


Brian wrote:

On Sat 15 Nov 2014 at 11:37:14 -0500, Miles Fidelman wrote:


Brian wrote:

On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:


On Vi, 14 nov 14, 08:04:00, Marty wrote:

By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

That assumes that one needs or wants systemd's features.

I rather think Andrei might not regard this as answering his challenge.
(You also didn't say whether the link's picture made you chuckle :) ).


Well yes, but also shudder.




For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Fair enough, but working within the realities of a situation is also
part of the deal. The deal for Jessie is systemd. This is not on a take
it or leave basis; quite a lot of work has been put into ensuring the
alternatives you want are there.

We have been here before, so some of what follows is repetition. For
users who feel the same as you it is (AFAIK) the way to get basically
what you want. It cannot be definitive because changes between now and
the release of Jessie are likely to alter the advice.

Upgrading
-

After changing sources.list and an 'apt-get update' do

  apt-get install sysvinit-core systemd-shim

Then proceed with an upgrade and dist-upgrade.

New Install
---

Use the apt-get command above immediately after installation or
preseed the installation of sysvinit-core and systemd-shim.

Both of these may or may not have an operational impact in individual
cases but (as an outline) they are (AKAIK) the only ways to avoid
systemd-sysv being installed. After that you are on your own, leaving
aside bugs.

I appreciate any major change to a way of working can be stressful but
(without wishing to teach anyone how to do their job) there are ways of
testing which can increase confidence in the provided methods. The
testing also has the added benefit (should there be problems) of
improving on the already large amount of work done within Debian. The
BTS would be the appropriate place to put one's experiences.


At the risk of repeating myself,  I'm going to stick with Wheezy as long 
as I can, see of LTS kicks in, and wait to see if bug #668001 ever gets 
fixed (and note that an awful lot of conflict might have been avoided if 
it had been marked release critical.)  Meanwhile, I'm going to start 
testing other distros, including BSD and illumos based ones.


Miles Fidelman



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5467c332.9090...@meetinghouse.net

Re: Installing an Alternative Init?

2014-11-15 Thread Paul E Condon

On 2014_0733-0500, Miles Fidelman wrote:
 Brian wrote:
 On Tue 11 Nov 2014 at 02:02:07 +0100, Michael Biebl wrote:
 
 Am 11.11.2014 um 01:58 schrieb Miles Fidelman:
 
 Michael Biebl wrote:
 Sorry, but that is not what I asked for. I asked for specifics.
 Your answer doesn't contain any specific problem which would make me
 able to reproduce any problem.
 
 I've tested various use cases and apt-get install -y sysvinit-core
 always did the right thing.
 
 Please show me an example where it doesn't.
 Frankly, no.  40 years of experience administering various kinds of
 systems gives me some perspective.  I've had enough experience with
 dependency hell on Debian (apt is phenomenal, expect when it isn't), and
   ^^
I think you meant 'except', rather than 'expect'. Right?
If one could absolutely rely on apt-get always getting it right, then

apt-get install -y sysvinit-core

could always be used to remove systemd even from a system that has
been booted into systemd and running, and not just in the context
of a pre-seed. Right? 

But if that that apt-get command doesn't work on an installation of systemd,
*that* is a bug in apt-get that *should* be fixed in Jessie *before* it is
released. Right? 

And the apt-get command,

apt-get install -y systemd 

should switch a host that is running sysvinit or upstart, to running systemd.
If not that is *another* bug in apt-get that must be fixed before release of
Jessie. 

If the release team were to accept that *both* these (hypothesized)
bugs are release critical, and have them tested and fixed before 
release, then there might be peace once again in Debian.

HTH


-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141115225444.ga27...@big.lan.gnu

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sat 15 Nov 2014 at 19:24:49 +, Brian wrote:

 Upgrading
 -
 
After changing sources.list and an 'apt-get update' do
 
  apt-get install sysvinit-core systemd-shim
 
Then proceed with an upgrade and dist-upgrade.
 
 New Install
 ---
 
Use the apt-get command above immediately after installation or
preseed the installation of sysvinit-core and systemd-shim.

In the light of

   https://lists.debian.org/debian-ctte/2014/11/msg00063.html

I'd like to revise the above and point out that at some time in
the near future the command

   apt-get install sysvinit-core

or preseeding the installation of only sysvinit-core should be
sufficient.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/15112014231357.f27ee7fd4...@desktop.copernicus.demon.co.uk

Re: Installing an Alternative Init?

2014-11-15 Thread Paul E Condon

On 2014_1200-0500, Tanstaafl wrote:
 On 11/11/2014 11:38 AM, The Wanderer wande...@fastmail.fm wrote:
  Other people subscribe to a meaning of default which, e.g., assumes
  only that systemd will get installed as PID 1 unless some action is
  taken to prevent it from getting so installed. That seems like an
  entirely reasonable interpretation, at least to me.
 
 Absolutely correct. The concept 'Default' implies that there are
 *alternatives*.

Systemd can be installed, and yet not functioning, if the address of
some other piece of code is planted in PID 1. Of course, much more
than a simple storing of an address value in a specific location in
RAM is involved in a successful switch of the *running* init system.
Tanstaafl's argument is faulty, IMO. 

Apt-get can be made to modify the information on disk so that the
next boot will install in RAM an init system that is different from
the init system under which apt-get was run.

This is 'inefficient' but much less 'inefficient' than trying to 
convince intelligent people of a falsehood thru right reason, which
is, in the end, a total waste of eveybody's time.

I suggest that the word 'default' not be used any more in this 
discussion. It serves only to obfuscate the nature of the problem.

-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141115233738.gb27...@big.lan.gnu

Re: Installing an Alternative Init?

2014-11-15 Thread The Wanderer

On 11/15/2014 at 06:37 PM, Paul E Condon wrote:

 I suggest that the word 'default' not be used any more in this
 discussion. It serves only to obfuscate the nature of the problem.

The word default is used in the discussion because the initial
decision made by the Debian project in regard to this topic was that
the default init system for jessie shall be systemd.

You can't avoid the word default unless you avoid discussing that
decision, and that decision is one of the things which people do want to
discuss. It's also one of the things which is relied upon in justifying
some (possibly all) of the changes being made to Debian in relation to
systemd.

Some people think the decision supports making those changes; other
people think it does not. That difference of opinion is, I suspect,
rooted in a disagreement about what the word default means.

If so, there will be no possibility of resolving the conflict between
the people who think the one way and the people who think the other
without first resolving that disagreement about the meaning of that
word... and resolving that disagreement would require using the word, if
only to discuss the word itself in that context.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Installing an Alternative Init?

2014-11-15 Thread Paul E Condon

On 2014_1807+0100, Laurent Bigonville wrote:
 Le Tue, 11 Nov 2014 07:42:33 -0500,
 Tanstaafl tansta...@libertytrek.org a écrit :
 
  On 11/10/2014 6:18 PM, Michael Biebl bi...@debian.org wrote:
   Am 11.11.2014 um 00:14 schrieb Miles Fidelman:
   Ok, then explain to me the procedure for running the installer in
   such a way that systemd is never installed, thus avoiding any
   potential problems that might result from later uninstallation all
   the dependencies that systemd brings in with it.
  
   Please be specific. What problems of of dependencies are you
   talking about?
  
  Please stop bring up irrelevant questions and address the question
  being asked.
  
  This does require you to at least understand and acknowledge the
  difference between a *clean* install, and installing something one
  way, then having to uninstall a primary piece and replace it with
  something else.
  
  The two are not the same, and no amount of you trying to act as if
  they are will change the fact that they are not.
 
 There are no functional differences between an installation with
 sysvinit-core out of the box or an install where sysvinit-core is
 installed later, this is a fact.

Theory tells us this should be true, but it would be nice if there
were experimental evidence. For instance, a demonstration that the
files on two hardware-identical computers, with software installed
in the two different ways, are bit-for-bit identical. But this
can't be done, as I understand the situation, because *clean*
install of sysvinit-core is impossible until the dbootstrap bug is
fixed. 

I predict that the initial 'fix' of that bug will fail to
achieve your predicted result. Naturally, I hope I'm wrong, but I
would like proof. 

Another topic:
My reading of the man page for apt-get seems to say that there
is no way to purge the configuration file of packages that were pulled
in to satisfy a dependency and subsequently autoremoved. I hope this
is an artifact of poor use of English. But if true, it should be fixed.

Yet another topic:
It should be possible to install systemd on a system that already 
has some other init system installed on it. This should be tested,
but how?


-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116002122.gc27...@big.lan.gnu

Re: Installing an Alternative Init?

2014-11-15 Thread Martin Read


On 15/11/14 23:04, Paul E Condon wrote:

If one could absolutely rely on apt-get always getting it right, then

apt-get install -y sysvinit-core

could always be used to remove systemd even from a system that has
been booted into systemd and running, and not just in the context
of a pre-seed. Right?


That command is unlikely to actually remove systemd on any Debian jessie 
system. What it will do is change what the symlink /sbin/init points to 
so that next time the system on which you do it is rebooted, it will use 
sysvinit as the init daemon.



But if that that apt-get command doesn't work on an installation of systemd,
*that* is a bug in apt-get that *should* be fixed in Jessie *before* it is
released. Right?


Probably wrong.

It seems to me that if doing apt-get install -y sysvinit-core on a 
Debian jessie system fails, it's far more likely to involve a packaging 
bug in one or more of the packages being added/removed than a bug in 
apt-get.



And the apt-get command,

apt-get install -y systemd

should switch a host that is running sysvinit or upstart, to running systemd.


Nope. It should install the programs comprising the systemd suite...


If not that is *another* bug in apt-get that must be fixed before release of
Jessie.


... but if you meant apt-get install -y systemd-sysv, I stand by my 
statement above: any problems arising in this process are unlikely to be 
bugs in apt-get.


And while writing this, I noticed that apt-get install -y systemd-sysv 
on a system running upstart looks like it will have... *unhappy* 
consequences, since unlike systemd and sysvinit, upstart has not had its 
packaging restructured into a package full of programs and a package 
that changes the /sbin/init symlink.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5467ee7c.6090...@zen.co.uk

Re: Installing an Alternative Init?

2014-11-15 Thread Martin Read


On 16/11/14 00:21, Paul E Condon wrote:

It should be possible to install systemd on a system that already
has some other init system installed on it. This should be tested,
but how?


The obvious way is to upgrade a wheezy system, following the upgrade to 
jessie while keeping sysvinit as the init system procedure, reboot, and 
then install the package 'systemd-sysv' and make sure that the system 
(a) keeps running and (b) reboots cleanly.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5467f082.2080...@zen.co.uk

Re: Installing an Alternative Init?

2014-11-15 Thread The Wanderer

On 11/15/2014 at 07:21 PM, Paul E Condon wrote:

 On 2014_1807+0100, Laurent Bigonville wrote:

 There are no functional differences between an installation with
 sysvinit-core out of the box or an install where sysvinit-core is
 installed later, this is a fact.
 
 Theory tells us this should be true, but it would be nice if there
 were experimental evidence. For instance, a demonstration that the
 files on two hardware-identical computers, with software installed in
 the two different ways, are bit-for-bit identical.

While I agree that this is the sort of test that would be needed to
satisfy the people who are insisting that you can't be sure there isn't
a difference, and while I'd like to see that verified myself, it does go
well beyond testing for *functional* differences - at least as I
understand that term.

 Yet another topic: It should be possible to install systemd on a
 system that already has some other init system installed on it. This
 should be tested, but how?

If I understand what you mean by install systemd, then it's trivial:

apt-get install systemd

That does not switch the active init system to be systemd. Doing *that*
would require:

apt-get install systemd-sysv

and even that, in its turn, does not (automatically?) remove
sysvinit-core from the system; you can still boot to it (from a
backup-installed location) with a kernel command line option, as a
fallback if systemd does break something too badly to even boot.

Or that's the claim, anyway. I've been examining files from
sysvinit-core on my own computer in an attempt to remind myself of some
of the details of how that works, and at a glance I don't see the backup
copy of /sbin/init anywhere...

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Installing an Alternative Init?

On Wed, Nov 12, 2014 at 12:26:26AM -0500, Marty wrote:
 On 11/11/2014 02:16 PM, Brian wrote:
 On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote:
 
 On 11/11/2014 12:07 PM, Laurent Bigonville wrote:
 
 There are no functional differences between an installation with
 sysvinit-core out of the box or an install where sysvinit-core is
 installed later, this is a fact.
 
 Allowing the user to choose this at install time from the interface is
 a nice to have feature (wishlist bug) not a RC bug like you were
 claiming earlier.
 
 There is a potential practical consequence of not advertising an
 init alternative during setup. It makes users less likely to be
 aware of it, or even aware that the init system has changed.
 
 New users do not need to be be aware of all the background to the
 choosing of a default init. No advertisement is needed. By definition,
 they do not care. They want Debian. Please let them have it.
 
 They will not care by definition only if they are not aware of the
 change, and most won't be aware unless they are informed during the
 installation.
 
 They won't know they lost the choice they didn't know they had. Capisce?
 
 What choice have they lost?
 
 They lost an *informed* choice. I think the installation program
 should not take sides but just inform the user. A choice that the
 user is not aware of is the same as no choice, and is potentially
 coercive and disrespectful. It makes Debian seem partial to Red
 Hat's business plan to take over the Linux ecosystem.

If you care so much about Redhat code, maybe you should document
yourself, and see there pay coders for glibc, gcc, the kernel ( a
ton of them, according to lwn and linux fundations reports ), on 
coreutils, gnome, kde, php, python, openssh, etc, etc.

  Whatever it was, it didn't exist as you imply
  in Wheezy.
 
 It wasn't an issue in Wheezy because the default init option had not
 changed from the previous release, and any release before that.
 
 They won't know, that is, until it bites them somewhere down the
 line. Then they won't know where to look or who to blame, and will
 blame Debian.
 
 What bites them?
 
 Individually, probably something that requires sysvinit or one many
 core services that got replaced. Collectively, getting trapped by
 vendor lock-in.

You keep using those words, but you do not seems to use them correctly. 
If the same system is present on more than one distributio, that's not 
vendor lock-in since you can switch distribution and then reuse the same 
system.

Being tied to one package format ( and so on the ecosystem around ) would
be true lock-in. And no one complained that much since Debian existed,
despites the .deb having a few shortcomings at start, shortcomings that 
were fixed later such as having checksum of installed software, a feature 
rpm had at a time the dpkg didn't ( around 2002, so that's really a old stuff ).
 
 In both cases it could be the result of users being steered to the
 default init by the installation program, leaving alternatives to
 rot.

Alternatives will rot if no one use them, so either you recognize than
no one is interested to use them and it will indeed rot, 
or that the few interested to use them are unable to fill bug reports and 
help the alternatives survives. 

Given that a reading of the archives here show less than 50 people by a 
large margin complaining on this list, I would indeed see that as a minority.

( as I hope there is more than 100 000 to 1 million Debian users, since
Ubuntu speak of 20 millions, Fedora speaking around 2 or 3 millions. But that
doesn't matter, since 100 000 or 1 million, there would still be far less than 
1%
of the user base ).


 Installation time may be only means that most users (like me*) ever
 would learn about it.
 
 * Install instructions? We don't need no stinkin' instructions
 
 Reading? You are right. Who wants it? Just spew out nonsense and hope
 nobody notices.
 
 Isn't that where the dumbed-down install is headed? Don't worry
 about the details silly, Windows tells you when it's time to reboot.

The part about Debian being a universal operating system also mean
it should aim for people who are not interested in details. Maybe you are 
ok by having Debian being seen as complicated and hard to use, spewing useless
questions on install, but that just mean than regular people will avoid it.

And if you want free software to be used, you would recognize that the setting 
is advanced and do not belong to d-i.

Now of course, maybe you are fine of having people staying on Windows or Mac OS 
X
because they have less trouble to install them and to use them, but you kinda 
lose the right to complain  why do no one use Linux ? ( and you also lose
the right to complain when others take that opportunity and are successful ).

--  
l. 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sat, Nov 15, 2014 at 11:37:14AM -0500, Miles Fidelman wrote:
 Brian wrote:
 On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:
 
 On Vi, 14 nov 14, 08:04:00, Marty wrote:
 By the same token systemd is a major waste with no real gain. It duplicates
 equivalent modular alternatives, and also requires unnecessary effort to
 repair damage from excessive coupling.
 I challenge you to come up with a configuration that duplicates
 systemd's features with a combination of other software.
 
 That assumes that one needs or wants systemd's features.
 
 For some (many?) of us, systemd represents no gain, and significant
 operational impact (time required to deal with changes).

Well, maybe taking some of the time you used to send 71 mails over the course
of 15 days on this list could be invested into dealing with the changes.

It is not like Jessie will not come with others configuration breaking changes
( such as Apache 2.4, to name one ).

You say significant operational impact, but all your mails seems to
imply that you are basing your analysis on absolutely no test. If you did things
right with your servers, you would just have to use your configuration 
management
system to spin a new server to test, either bare metal or a VM if you can't 
afford
a test machine, and see by yourself, and then, be precise in what is the 
problem.
( provided you use configuration management, but I would find baffling than any 
serious sysadmin do not use one these days ) 

Cause if no one can reproduce the problem ( because you give no indication ) 
and 
no one can find it ( because people test and have no issues ), it is not 
different
from having a problem that do not really exist, and insisting on it is then no 
different
than baseless trolling. You want to make a difference, so just do something 
useful.

-- 
l. 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116010515.gb22...@gmail.com

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sat, Nov 15, 2014 at 10:05:49PM +0100, Erwan David wrote:
 Le 15/11/2014 20:24, Brian a écrit :
  On Sat 15 Nov 2014 at 11:37:14 -0500, Miles Fidelman wrote:
 
  Brian wrote:
  On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:
 
  On Vi, 14 nov 14, 08:04:00, Marty wrote:
  By the same token systemd is a major waste with no real gain. It 
  duplicates
  equivalent modular alternatives, and also requires unnecessary effort to
  repair damage from excessive coupling.
  I challenge you to come up with a configuration that duplicates
  systemd's features with a combination of other software.
  That assumes that one needs or wants systemd's features.
  I rather think Andrei might not regard this as answering his challenge.
  (You also didn't say whether the link's picture made you chuckle :) ).
 
  For some (many?) of us, systemd represents no gain, and significant
  operational impact (time required to deal with changes).
  Fair enough, but working within the realities of a situation is also
  part of the deal. The deal for Jessie is systemd. This is not on a take
  it or leave basis; quite a lot of work has been put into ensuring the
  alternatives you want are there.
 
 
 It isq : when you have bugs like
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762623
 Once said oh it works with systemd, then no more activity on the bug,
 nothing.

I would suggest to read the url you post. There was a message from the
maintainer saying sorry, i tought I answered, I already reported it to
udev, please give more information on the bug.

Then indeed, you didn't followed up.
 
 That means that practically, systemd is de facto compulsory. Not the
 default, the only way allowed.
 
 So it is take or leave.

I think this conclusion is likely wrong and hasty, given the lack of 
activity is a result on waiting on more information from the reporter. 

-- 
l.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116011301.gc22...@gmail.com

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

2014-11-15 Thread Marty


On 11/15/2014 06:49 AM, Andrei POPESCU wrote:

On Vi, 14 nov 14, 08:04:00, Marty wrote:

On 11/14/2014 05:26 AM, Andrei POPESCU wrote:
On Vi, 14 nov 14, 08:59:11, Joel Rees wrote:
snip

Jumping in here as myself, not Joel's tag-team member. :)

Debian as an entity doesn't really do much. There are only one or
several volunteers who start doing things. Setting up a separate port
for systemd would have been a major waste of resources (both human and
hardware) with no real gain.

By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.


I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

http://0pointer.de/blog/projects/why.html


You are completely dismissing the work of Debian Developers who *did*
have a very good look at the options and decided switching to systemd is
doable and would be a good thing from a *technical* point of view.

Non-responsive to his argument. If the work was biased and over-optimistic
then it doesn't matter how much they looked at it.


This argument cuts both ways :)


However, you and several others are rejecting systemd on ideological
grounds. There's not much that can be done about that, short or
re-implementing systemd according to your vision.

Many others reject choice and the anti-choice stance is the ideological
position at issue here. It is in direct conflict with Debian policy.
The systemd upstream are the ones with vision, ideology, rejecting
opponents as haters in an overt campaign to establish a Linux monopoly.
They have a financial interest in *psychological projection* of this kind. I
still cannot see what Debian stands to gain by jumping on their marketing
bandwagon.


At least some of people rejecting systemd demand that it be removed
completely, including libsystemd. How is it pro-choice to forbid me from
being able to use a software at its full potential?


For me it's more about being unable to remove it completely, because of 
vendor lock-in. There's no technical reason that I know of that anything 
in userspace cannot modular, and replaceable, so when something cannot 
be replaced then an alternative must be provided, or else my default 
assumption is that vendor lock-in is in effect.



I hope you do understand why neither the systemd developers, maintainers
or users have any interest whatsoever in doing that.

But upstreams have other interests, like establishment of a Linux monopoly
via tying and customer lock-in. Why should there not be a rational effort to
counter that?


In my opinion the best defence against a monopoly[1] of any kind is to
develop competitive alternatives.


That's true on a level playing field, but here is just one player with 
control of the user-space software stack, fully leveraging it by 
dependency tying. It's like a manufacturing business that creates a 
monopoly by vertically integrating, in a way that no competitor can.



[1] which I don't believe applies, but will ignore for the moment.


They seem determined to make it apply in the future, so that's what 
drives the original concern (for me). It may apply in a way you are not 
expecting.



   After all, systemd
already works fine for them.

Windows already works fine for most people, and it is consistent with the
anti-choice philosophy, so why bother with Linux at all?


Doesn't work fine for me. At $dayjob I'm forced to use it and I can tell
you my private laptop with a Dual Core 1,8 GHz and 2 GB RAM runs circles
around a Core i5 with Windows 7. But this is off-topic for d-u.


It might be somewhat on-topic after all, because I was thinking more 
about Windows 10, which is Red Hat's likely target and competitor. 
Debian and the other free software distros are just Wall Street cannon 
fodder.




Kind regards,
Andrei




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5467fc2d.7010...@ix.netcom.com

Re: engineering management practices and systemd (Re: Installing an Alternative Init?)

On Sat, Nov 15, 2014 at 03:43:40PM -0500, Tanstaafl wrote:
 On 11/15/2014 7:20 AM, Andrei POPESCU andreimpope...@gmail.com wrote:
  On Vi, 14 nov 14, 08:55:47, Tanstaafl wrote:
  On 11/14/2014 5:26 AM, Andrei POPESCU andreimpope...@gmail.com wrote:
  It was claimed that sysvinit was the default *and only* (emphasis not 
  mine) init, and therefore no selection was needed, but now that there 
  are several a selection suddenly is needed.
 
  I don't recall claiming that sysvinit was the *only* init, nor do I
  recall anyone else making such a claim.
  
  https://lists.debian.org/debian-user/2014/11/msg00814.html
  Maybe a language issue? (I'm not a native speaker).
 
 Nope, that was me and I actually did say it... weird that I didn't
 remember saying that... but it doesn't really change anything...

That's a attempt at moonlighting people, not very classy.
 
 Just because other init systems exist doesn't mean they were actually
 being used, other than maybe just someone toying around.
 
 Are you seriously suggesting that anything other than a tiny and
 insignificant fraction were using anything other than sysvinit (until
 systemd came along at least)?

  For fresh installs, given that there is a suitable[1] workaround
 
 sigh
 
 how many times does it  have to be said - that is not a workaround for a
 CLEAN INSTALL.
 
  For dist-upgrades, even assuming systems will be switched automatically 
  (which is still undecided):
  
  - one can prevent switching by installing sysvinit-core before the 
dist-upgrade step
  - the sysvinit package contains the binary /lib/sysvinit/init which can 
be used with the init= kernel parameter
  - there is a grub patch[3] pending integration[4] to offer an 
alternative sysvinit boot option
 
 Yes, and how long after upgrading to jessie staying with sysvinit until
 things start breaking (most likely subtle breakage, which is the least
 desirable on a server).

The distinction server/desktop is clearly not relevent. There is huge deployment
of Debian desktop, and they do not want subtle breakage anymore than others 
people.

Now, if there is breakage ( so far, you speak of the future ), it will be 
because 
no one detected them in the first place, and given the Debian structure, 
that mean that not enough people were using that setup on testing and/or 
unstable. 
For this, there is a few fixes :
- find people to test that ( starting by yourself ). If half of the people who 
rant since a few months
on this list were doing tests and filling bug report, this would be rock solid.
- automate that testing ( Ubuntu has a lot of ressources on the topic 
https://wiki.ubuntu.com/Testing/Automation
and so does OpenSuse ).
- make sure that bugfixes are propagated faster to stable and provides patches 
and or bugs when stable is here.

Now of course, if no one take time to do any of theses, that's gonna cause 
problem. But that's
a problem because people who want the work to happen do not make it happen. ( 
and no we do not
have time, if people have time to post on ml, they have time to post bug 
reports ).
  
  [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757298
  [4] https://lists.debian.org/debian-ctte/2014/10/msg00057.html 
  
  The transition plan[5] has been posted on -devel since July with no 
  objections.
 
 Maybe because most debian *users* don't follow the dev list because they
 aren't devs...

At the same time, most debian users likely do not really care about transition 
plan and systemd. It was widely published everywhere in March and yet, no one 
would have cared if this
mattered ?
And those that care should make the efforts to follow what happen in the 
distribution, reading
one or two time a week the title on a web archive is not a huge time investment.
( at least not more than following this lists and answering on it )

-- 
l.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116013520.gd22...@gmail.com

Re: Installing an Alternative Init?

2014-11-15 Thread Marty


On 11/15/2014 07:45 PM, Ludovic Meyer wrote:

On Wed, Nov 12, 2014 at 12:26:26AM -0500, Marty wrote:

On 11/11/2014 02:16 PM, Brian wrote:
On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote:

On 11/11/2014 12:07 PM, Laurent Bigonville wrote:

There are no functional differences between an installation with
sysvinit-core out of the box or an install where sysvinit-core is
installed later, this is a fact.

Allowing the user to choose this at install time from the interface is
a nice to have feature (wishlist bug) not a RC bug like you were
claiming earlier.

There is a potential practical consequence of not advertising an
init alternative during setup. It makes users less likely to be
aware of it, or even aware that the init system has changed.

New users do not need to be be aware of all the background to the
choosing of a default init. No advertisement is needed. By definition,
they do not care. They want Debian. Please let them have it.

They will not care by definition only if they are not aware of the
change, and most won't be aware unless they are informed during the
installation.

They won't know they lost the choice they didn't know they had. Capisce?

What choice have they lost?

They lost an *informed* choice. I think the installation program
should not take sides but just inform the user. A choice that the
user is not aware of is the same as no choice, and is potentially
coercive and disrespectful. It makes Debian seem partial to Red
Hat's business plan to take over the Linux ecosystem.


If you care so much about Redhat code, maybe you should document
yourself, and see there pay coders for glibc, gcc, the kernel ( a
ton of them, according to lwn and linux fundations reports ), on
coreutils, gnome, kde, php, python, openssh, etc, etc.


 Whatever it was, it didn't exist as you imply
 in Wheezy.

It wasn't an issue in Wheezy because the default init option had not
changed from the previous release, and any release before that.

They won't know, that is, until it bites them somewhere down the
line. Then they won't know where to look or who to blame, and will
blame Debian.

What bites them?

Individually, probably something that requires sysvinit or one many
core services that got replaced. Collectively, getting trapped by
vendor lock-in.


You keep using those words, but you do not seems to use them correctly.
If the same system is present on more than one distributio, that's not
vendor lock-in since you can switch distribution and then reuse the same
system.


I meant that one vendor seeks to control the Linux ecosystem. Whether 
that plan is viable or even sane, is another issue, but I am not eager 
to see if their plan will succeed or be a guinea pin in the experiment.


(I would like to see systemd succeed in Debian, however, *without* 
sacrificing modularity or user choice. That would be like embrace and 
extend in reverse, and could serve to protect downstreams.)



Being tied to one package format ( and so on the ecosystem around ) would
be true lock-in. And no one complained that much since Debian existed,
despites the .deb having a few shortcomings at start, shortcomings that
were fixed later such as having checksum of installed software, a feature
rpm had at a time the dpkg didn't ( around 2002, so that's really a old stuff ).


In both cases it could be the result of users being steered to the
default init by the installation program, leaving alternatives to
rot.


Alternatives will rot if no one use them, so either you recognize than
no one is interested to use them and it will indeed rot,
or that the few interested to use them are unable to fill bug reports and
help the alternatives survives.

Given that a reading of the archives here show less than 50 people by a
large margin complaining on this list, I would indeed see that as a minority.

( as I hope there is more than 100 000 to 1 million Debian users, since
Ubuntu speak of 20 millions, Fedora speaking around 2 or 3 millions. But that
doesn't matter, since 100 000 or 1 million, there would still be far less than 
1%
of the user base ).


I don't think Debian (or FOSS, for that matter) was ever about a 
winner-take-all approach to software choice. That seems to have 
originated in the commercial distributions, which have a financial 
interest in a) controlling users and b) controlling costs. I don't think 
that philosophy was ever part of Debian in the past. I had thought that 
all it takes is one interested maintainer to keep a package alive in Debian.


You might also be simplifying the problem. Software entanglement is a 
complex technical problem. There's a reason it's regarded as lock-in, 
because it's a technical cage that can be hard to break out of. It herds 
users in one direction, so the popularity issue is not only irrelevant, 
but misleading.


I don't think there is a direct relationship between the number of users 
of alternate software, and the importance of maintaining it. I would say 
it's more of an opposite

Re: Installing an Alternative Init?