Hi, 2012/7/27 Jeremiah Dodds <jeremiah.dodds@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)