Public SourceMage Discussion List

[seth AT swoolley.homeip.net]

On Wed, Feb 28, 2007 at 10:13:16PM -0600, Jeremy Blosser wrote:
> 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.

What messages?  It was a lack of messages.

If you find an announcement for that interface change beyond a patch to 
lkml, then perhaps, however that change was more fundamental than for an 
init system.

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

The distraction I vocally said was probably a meaningless distraction 
on first read?  They didn't distract me.

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

We're all happy to maintain bash code against bash-interface-changing 
bit-rot, but a small set of C files is too hard?

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

You've fallen into the replacement versus complement hole with this 
paragraph.  I thought the consensus was on complementing the init system 
with choices, not replacing it.  That's all I'm vocal for.

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

You filed one bug requesting proper respawn support and gave a 
workaround.

That's all that shows up filed against simpleinit.

I think a good audit of just where you think simpleinit is deficient is 
necessary for this discussion so we can ensure the new setups will also 
support them.

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

I'd rather rewrite it more cleanly, which I may do.  I'll go far as to 
say that if a bug shows up in simpleinit-msb again, I'll put my best 
effort in to fix it with what time I have available.  I'm going to setup 
a Xen testbed at home just for situations like this that involve init.

It's not designed the way I would like.  The problem is that the 
replacements that exist now and that are developing are adding 
complexity.  I want to reduce it even further and move non-essential 
items out of it.

If somebody has a potential init system that looks like that, let me 
know and I'll probably try it out and abandon simpleinit-msb (then do 
what you want with it).

I'm more a fan of blackbox-style minimalism.

Seth