[arch-releng] Helping with AIF

[Jeremiah Dodds]

Alexander Rødseth <rodseth at gmail.com> writes:

> Hello,
>
> I would also like to help out with AIF. How about we try to
> collaborate on something, Jeremiah?

It's totally a possibility!

> The last couple of days, I've started working on "acu":
> https://github.com/xyproto/acu
> And created a webpage for submitting and browsing "machine
> configuration bundles": http://www.roboticoverlords.org/

It looks like it could be an interesting project, some extrapolation
below.

> This is all work in progress and not in any way "officially blessed",
> but my aspiration is that it might be some day.
>
> My main idea is that if the installation process issplit into
> "personal configuration, like keyboard and timezone", "machine
> configuration bundles, crafted per type of computer setup" and
> installation-specific instructions like partition and network
> settings, the installations would be simpler and cost less work
> (especially for experienced users).

I find the "configuration bundles" idea interesting, but I wonder how
much of it is needed on a per-machine basis. I haven't run into many
machine-specific issues, but then again I'm sure they exist.

The end-result I'm working toward is providing a service that allows
people to generate linux live and install images that have what they
want on them already -- I've written a proof-of-concept webapp that
installs a package on a live and install cd that I intend to start a
kickstarter with[1]. My goal is to allow college kids and newer linux
users to create something that will give them access to the system
they need or want in case of failure or circumstance, and allow it to
perform (if desired) unattended installs.

My app at this point isn't much more than a pretty thin wrapper over
aif, it does successfully generate images though.

Assuming I can manage to get that off the ground, there are a lot of
neat things to be done with enabling people to share configs.

A couple of questions on acu based off the github page:

1. Why create a configuration file format? There are many standard
   formats ranging from simplistic to very complex, and even if go
   didn't have an implementation of one laying around, it'd probably be
   simpler (and less confusing/more reliable/quicker) to write a parser
   for one.

2. What, exactly would you have machine-specific configs entail? There's a
   difference between purpose-specific and hardware-specific ... I feel
   that the former has more common use cases, but on the other hand a
   *lot* of the configs and specific packages that I can think of for a
   "purpose" machine are going to vary wildly from user to user. 

3. Why go? 

Footnotes: 
[1]  I know this can be a controversial thing, but to develop what I want to
     in full I need to be able to cover hosting costs and living costs
     for a couple of months. I happen to be poor, and would seriously
     prefer to be able to work on something like this full-time, and I
     feel that if the community decides it's awesome enough, I'll be
     able to do so.

-- 
Jeremiah Dodds

github: https://github.com/jdodds
irc   : exhortatory