Public SourceMage Discussion List

[David Kowis <dkowis AT shlrm.org>]

On 01/27/2013 08:12 PM, flux wrote:
> David Kowis (dkowis AT shlrm.org) wrote [13.01.28 06:07]:
>>> <snip>
>>>> Updated init system:
>>>> --------------------
>> It's *far* easier to build initscripts for systemd than it is for
>> simpleinit-msb or any other init system I've used. I am generally
>> inclined to agree that systemd isn't traditional UNIX philosophy, but I
>> really like how easy systemd makes it to build complicated and powerful
>> init systems. Simpleinit-msb doesn't do any of those things, and us as a
>> distro will have to reinvent all that stuff. Primarily, however, I would
>> like to move to something that's more common, and used by other distros,
>> so we can leverage the users of other distros.
> 
> While it may be easier to create init scripts for systemd, you still
> haven't pointed out what simpleinit cannot do that systemd can (if we
> aren't looking at how easy it is to do so). You claimed that
> "simpleinit-msb doesn't do any of those things", but you failed to
> clarify what "those things" refers to. If you meant building complicated
> and powerful init systems, then neither simpleinit-msb or systemd do
> this: they don't *build* init systems, they *are* init systems. If you
> meant building init setups, then both allow for this. You can use any
> language you want to write init scripts for simpleinit, since all it
> cares about is whether a file in a given "runlevel" directory is
> executable or not. This means that your init script can be written in C,
> python, Lua, Java, etc. If you are unable to build something complicated
> and powerful given that, then perhaps you are doing things wrong. If
> your argument is that we don't necessarily supply something more
> powerful/complicated out of the box, then you'd be right, but I'd argue
> that's not a problem since ultimately that should be up to the admin.

As another has mentioned, simpleinit-msb does not parallelize
initialization, it does not handle resource management (cgroups), it
does not persist logs for syslog (like, before syslog is started), it
does not restart daemons.

You can also write init scripts in any languagewith systemd as  well.

> 
> Again, I'm not arguing against systemd. You seem to be focusing your
> argument a little more on pro-systemd and anti-simpleinit. I'm just
> looking to clarify anti-current_setup vs. pro-new_setup, regardless of
> what new system we end up going with. Change is fine, as long as we have
> clear goals and targets for the change.

I'll be honest, I am pro systemd. I find it to be exceptionally easy to
build init scripts for, to do whatever custom anything I could imagine.
I like that a whole lot.

> 
> Also, although it's harder to implement, I'd like to see IMP get more
> fully implemented. The philosophy and spirit of our distro is choice for
> the user/admin, and not to get in the admin's way. I'd prefer for a user
> to be able to use whatever init system he/she wants. There are
> consequences for that, both for the user and for us as developers, but I
> think it's worth it. Compare it with the choice of udev vs. manual /dev
> tree management. Many distros have thrown away this choice for the user
> and force udev, but we allow the choice, and I think we're better for
> it.

I'm concerned we don't have the developer bandwidth to make it happen,
but your points are well taken. I don't think udev is the evil or
anything like that, and sometimes one has to make decisions in order to
move forward. I don't know if we'll be able to do both udev based
systems and static systems and not have lots of bugs and work to do.

> 
>>>
>>> <snip>
>>>> Chroot based build process:
>>>> ---------------------------
>>> However, there is a issue for doing *all* installs via chroot: you will
>>> be casting spells over and again even when they are already installed,
>>> unless you first graft them in from the host system. This can get
>>> complicated, but it is possible to do it, except you will only be able
>>> to do so when the version in the host system matches the options
>>> requested by the chrooted spell cast. You'll also need a smarter way to
>>> handle conflicts/merges/updates between versions in the chroot vs.
>>> versions in the host system. I.e., if you have gcc without g++ in the
>>> host system, and cast a spell in a chroot that forces/requests gcc with
>>> g++, you'll likely need the g++ enabled version in the host system (for
>>> libstdc++ at runtime). That means updating the host gcc. In this case,
>>> there's probably no issue and you can just do it, but in some other
>>> cases it might cause existing spells in the host system to break due to
>>> library changes (especially if a spell forces a dependency without a
>>> feature that's enabled in the host). This can be done smartly, but will
>>> need to be planned out and accounted for.
>>
>> I plan that storing the spell config in the binary tarball will indicate
>> that you need something specific installed.
> 
> How is storing spell config in the binary tarball related to the
> pitfalls of building in a chroot?

If it's already built, and the config matches exactly, I can just
extract the binary tarball and call it done, I won't have to build the
entire package again. Storing the config in the single file gives me a
single atomic item that contains all the information I need to verify
these things.

>>>
>>> <snip>
>>>> Declarative spell config:
>>>> -------------------------
> I believe I see where you were going with this argument, so I will
> attempt to clarify it here. Please correct me if I am mistaken. What you
> meant by "deal with configurations" was pointed not at creating the
> configuration initially (i.e. getting user input in the first place
> during an actual cast), but in verifying prior configurations so that
> they can be repeated. In this case, declarative clearly wins over
> procedural.
> 
> The menu system could, theoretically, be implemented in sorcery as it is
> now though. The menu system would just have to also be procedural and
> dynamic, so that it can update menu options as needed to reflect the
> logic followed in the spell's configuration. We actually had just such a
> menu system in the older ISOs (0.9.5 for example).

I gather my inspiration from things like the kernel's menuconfig. It's
got a declarative config file, and when you toggle things in the menu,
trees are added or removed. That's what I'd like to see for our spell
config. It'd be even better if we could just leverage the kernel style,
as they've got built in graphical stuff already, or you can do it in the
oldconfig way and just answer questions similar to how we're doing it now.

> Please reread. I stated explicitly that my list was unordered.

Derp.

--
David Kowis

Attachment: signature.asc
Description: OpenPGP digital signature