Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

On Feb 28, seth AT swoolley.homeip.net [seth AT swoolley.homeip.net] wrote:
> On Wed, Feb 28, 2007 at 04:27:36PM -0600, Jeremy Blosser wrote:
> > On Feb 28, seth AT swoolley.homeip.net [seth AT swoolley.homeip.net] wrote:
> > > I thought I might forward this onto the discussion.  The major issue 
> > > with simpleinit-msb on newer kernels has now been isolated (not that 
> > > there aren't still minor issues).  :)
> > > 
> > > A lot of people helped contribute to fixing this bug.  I'd like to 
> > > thank 
> > > them all, including David Kowis, Jeremy Blosser, Andrew Stitt, Juuso 
> > > Alasuutari, David Brown, George Sherwood, and Arwed v. Merkatz.
> > > 
> > > Excellent example of teamwork.
> > 
> > That's one spin.  ;-P  While I definitely appreciate everyone helping on
> > this, this is to me an excellent example of why we need other options, 
> > even
> > just one other option for the short term.  That's too many people and too
> > many hours spent on finding something that ended up being this trivial,
> > isn't it?
> > 
> > "How many SMGL devs does it take to screw in a lightbulb?"
> 
> This bug was extra hard for a few reasons that aren't necessarily 
> expected in the future:

No.  The bug was hard because we had no idea how the internals worked to
know where we might start looking for the problem in the code, so we had to
start with stracing the symptoms and work backward from there.  If someone
who actually supported it and knew what it was doing heard the symptoms
they probably could have solved it nearly immediately because they'd know
where the messages originated and could start there.  And that's assuming
it wouldn't have been fixed during the course of normal development as they
tracked relevant kernel and libraries changes.  You know, the kinds of
maintenance people do with maintained software.

> * There was an unrelated kernel change in signaling that distracted the 
> system call traces.
> 
> * There was a kernel change that changed file semantics significantly.
> 
> * The code problem was in a small block of code not allowing userspace 
> init to find the problem, since it only acts directly on the console in 
> non-userspace mode.

All of these were only issues because we don't know or regularly support
this code.  They distracted us until we could rule them out because we
didn't know what was expected behavior and had to disprove everything else
that looked anamolous wasn't a problem.  I'm frankly embarassed it took us
that long to find a bug so simple, whether I think it was really our
problem to solve or not.

> Other than that, I doubt most init systems even have a userspace init 
> mode and have zero bugs and never had issues with portability due to 
> kernel changes.

Of course nothing else is perfect.  That is not the point.  The point is
having a path to a resolution that makes sense.  There are bugs, and then
there is bit rot.

> That we handled it is reason enough to believe that we're capable of 
> maintaining deep code like this on our own.  Yes, we might not want to, 
> and that's reason enough to make alternatives available, but we mustn't 
> overreact and remove simpleinit-msb as a result of this bug.

It is not a question of *capability* it is a question of *purpose*.  We no
doubt had capability during the scm discussions to reverse engineer
perforce and make a GPL clone of that and maintain that ourselves for our
own use.  But it would have been a poor use of our resources and it would
have had nothing to do with our purpose as a distribution.  Yes, I know the
scale of those two things is very different, but the principle is the same.

And if you think this talk of replacing simpleinit is somehow new or
specific to this particular bug you haven't been paying attention.  That's
like the arguments each time p4 was down that "we shouldn't talk about
replacing it just because it's down this one time", no matter how many
times it had been down before, or how many other issues we had with it.
(Insert standard disclaimer that it wasn't p4's or Tony's fault when it was
down, and reminder that it didn't matter.)

> There are a few other improvements that nobody is mentioning in these 
> discussions that I'd like to make to it that could be considered 
> detriments, but I don't think the level of argument against 
> simpleinit-msb has reached that level of sophistication (yet).
> 
> Maybe the initng maintainer will bring the sophistication up and give 
> reason enough to say that simpleinit-msb is fundamentally flawed.

People make comments and requests around the other shortcomings of
simpleinit all the time.  There are plenty of bugs filed on things our init
system doesn't support.  Yes, the bugs are filed more against init.d than
simpleinit, but the bottom line is the same: we are piling up issues in
this area quicker than we are resolving them, and while that's hardly
unique in the project overall, it's an area where we arguably shouldn't
even be operating.

> I, for one, don't think it is fundamentally flawed.

If you want to pick up simpleinit and make maintaining it your pet project
and see it included as an option here and elsewhere, you're certainly free
to do so, but don't expect the project to agree it's something "we" are
doing.  simpleinit-msb is not a Source Mage component.  The fact is we only
have this discussion and apparent willingness to work on init bugs when
people complain loudly enough that it's flawed, and then they still never
get resolved.  The project needs to move past this so it stops giving us
black eyes.

Attachment: pgpl7Qfk9zq9r.pgp
Description: PGP signature