[arch-releng] Helping with AIF

[Alexander Rødseth]

Hi,

2012/7/27 Jeremiah Dodds <jeremiah.dodds at gmail.com>:
> 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.

I've encountered a lot of machine-specific issues, setting up (Arch)
Linux on several computers. Especially laptops often need extra
modules loaded to make the sound card, network card or video camera to
work, possibly with a couple of firmware-packages thrown into the mix.
Specifying all it takes to set up a machine in a single, easy to read,
text file, shared among Arch Linux users in the same fashion as
AUR-packages is shared, would be an improvement, IMO.


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

I think this approach would work too.


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

As far as I can tell, not that much information is needed in order to
specify what it takes to configure a computer. A list of packages to
install, a few changed configuration options and perhaps the addition
of a few lines in a few configuration files should do the trick. This
could be expressed either as a regular shell script or as some sort of
list of declarations. Both could work, but it we imagined there was a
webpage with hundreds of these configurations, it would be easier
compare configurations and base new configurations on old ones if the
file format was declarative. Also, it would be easier to parse for the
web-system. The AUR web page struggles to parse the non-declarative
PKGBUILD textfiles.


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

My vision is that an install would consist of three parts. The machine
configuration should be auto-detected or specified and downloaded with
an AUR-like system. The personal configuration, like time zone, locale
and keyboard layout should only need to be specified once ever and
stored as a short string or as some sort of id. I can't could how many
times I've specified the same settings, and it should not be needed in
our day and age. Once should be enough. The third and last part would
be the information that is specific to the installation in question.
Which disk should the installation be on? Is this supposed to be a
media server? Should the filesystems handle small files well? Is
wireless network preferred? In my opinion, this third part is what
users _should_ be worrying about when installing Arch, not selecting
keyboard layout for the n'th time and not go hunting for forum posts
about how to get the soundcard to work on this particular brand of
laptop.
Hope this answered your question.


> 3. Why go?

This is subjective: I love the Go programming language. The code has
clarity, it has better modularity than both Python and C++. Code
compiles quickly, unlike for C++. Code feels sturdy and like you can
actually build a fortress instead of a tent, like in Python (even
though you can build really big tents in Python. I love Python too.).
It's easy to do web-related programming and concurrency, unlike C. And
the execution speed is approaching C and C++, as the compiler matures.
(And yes, the garbage collection can be turned off, or one can manage
memory yourself). In addition to this, the pointers are safe. In
short, you avoid all the major pains that comes with a C++ projects
over N lines long (say 100000). Code is a lot quicker to write than
compared to Haskell, but it still feels solid. That was the subjective
reasons.

The non-subjective reason for choosing Go, in this connection, is that
it easily compiles to a static binary that does not need any
dependencies (packages). For an installer, this is great. Also, the
execution speed is fast. If there are several developers involved,
there are no arguments about tabs vs spaces, since the standard (and
tool that formats the code) is clear and it has good modularity.


My next plan is to rewrite the code I wrote for the web-interface for
machine configurations, but in Go. I'm in the process of moving this
to a server that makes this possible.
Either that or use the PHP-code for AUR as a basis. Or some other
solution. Time will tell. (The current PHP-code is bad, but crappy
prototypes keeps the momentum up).


In either case: no matter the approach and no matter the authors, I'm
looking forward to the next generation of installers.


-- 
Cordially,
 Alexander Rødseth
 Arch Linux Trusted User
 (xyproto on IRC, trontonic on AUR)