Improving the installer?

patson · 2006-08-22 05:53:40

Hi. Searching the forums yielded no discussion about this, so I'll just go ahead and ask: are you guys working on a better installer?

The reason I ask, is because, frankly, I find the current installer a usability nightmare, primarily because of the nature and behaviour of the partitioning and package selection menus. The user gets kicked out of them without warning, and there seems to be no reliable way to undo an erroneous selection, other than restarting the process. First time around it took me five tries to get the partitioning correct, and even then I was a little unsure about wether it was going to nuke my archives or not.. Second time around I got it correct in only seven (when I installed Arch on my laptop)..

The real reason for me asking is because the idea occurred to me, that it'd be unnecessary for me to start writing improvements to the installer, if they're already being worked on by the maintainers. However, if you're not working on improvements, I'd suggest posting it as a TO-DO somewhere accessible from the main page (didn't seem to find that?).

Anyway, I'd like to help out. I should have the time to start coding sometime next week. Alternatively, why not use Anaconda? I know it's a mess, but it'd be an install-time mess at worst (and it works pretty well).

Let me know what you think.

patson · 2006-08-22 06:00:38

Sorry to bump my own post, but I feel I left something out (that just won't fit in the original)..

The particular improvements I'd like to make are

Partitioning:

- Separate display mode for assigned/unassigned partitions (perhaps a brighter colour of text?)
- Display of mountpoints (this one really annoyed me)
- Display of filesystem type of detected partitions
- Back, cancel and undo buttons!

Package selection:

- Back, cancel, undo here also
- A viewable summary of packages to install
- Perhaps support for pre-made configurations? (desktop install, server install, etc.)

Also, I find the editing of configuration options a bit crude, but it'll work for the time being. However, what about using vim instead of vi for that? vim has such large penetration already, that J. Random Hacker is more likely to be comfortable with vim than vi..

My two cents.

Sigi · 2006-08-22 06:04:13

The Arch Way

The Arch Way wrote:

Don't let configure tools / GUIs control the system but be controlled by the user. There is nothing wrong of having GUIs as long as it follows this principle.
...
The core development of Arch Linux will not be providing any "newbie-friendly" GUIs/utilities at any time in the near future.

Dusty · 2006-08-22 06:09:58

Phrakture was talking about rewriting the installer in Python with a modular core that could be used for various frontends including curses, GUI, and automated. I have no idea if they started it or not, but it does indicate the devs were talking about it.

A while back, somebody wrote one in Perl, but I don't think it ever went anywhere.

Phrak's the only dev that comes around here much, but I expect he'll answer the question now that I've said absolutely nothing...

Dusty

Sigi · 2006-08-22 06:10:18

patson wrote:

- Perhaps support for pre-made configurations? (desktop install, server install, etc.)

The right way(tm) to install Arch is to install a set of base packages with the installer and configure the main configuration files by hand. As soon as your system is running a simple "pacman -Sy kde" is enough to turn your PC into a KDE desktop.

patson · 2006-08-22 06:14:23

I'm not suggesting making the installer newbie-friendly, I'm suggesting making it user-friendly. Big difference.

Newbie-friendly would most likely be copying the Windows installer, but making it reboot less.

User-friendly is not making me guess and remember wether or not I already set options for each of my 14 partitions over 8 devices... Or which partition to muck about with on my laptop with five partitions (two extended).

And why is partition 4 visible on a hard drive with extended partitions? Writing to it will lead to lossage.

User friendly. Not newb friendly.

patson · 2006-08-22 06:17:41

Sigi wrote:

patson wrote:
- Perhaps support for pre-made configurations? (desktop install, server install, etc.)
The right way(tm) to install Arch is to install a set of base packages with the installer and configure the main configuration files by hand. As soon as your system is running a simple "pacman -Sy kde" is enough to turn your PC into a KDE desktop.

Yes, true. And now that I think about it, having pre-made package configurations would require a lot more supporting than not having it..
You'd need to get X and a bunch of other stuff configured correctly on every possible desktop architechture... So probably not a good idea. But I never thought it'd be that great to begin with, hence the question mark. I'd say it's pretty safe to rule it out for the forseeable future.

patson · 2006-08-22 06:39:11

Dusty wrote:

Phrakture was talking about rewriting the installer in Python with a modular core that could be used for various frontends including curses, GUI, and automated. I have no idea if they started it or not, but it does indicate the devs were talking about it.
A while back, somebody wrote one in Perl, but I don't think it ever went anywhere.
Phrak's the only dev that comes around here much, but I expect he'll answer the question now that I've said absolutely nothing...
Dusty

Hmm. You bring up a point about choice of language here, with both Perl and Python being tried. I was going to write the thing i C (ncurses all the way ), or possibly C++ (although I doubt its necessity given the nature of the data being handled), which would require, at the very least, recompiles for different architechtures. Still, I doubt it'd be too much troule, given the amount of platforms Arch supports.

I can't say I'd ever used Python extensively, apart from a few small scripts, but all the big projects I've seen using it (YUM, Portage, Frets on Fire come to mind) have all been flaky...

Come to think of it, what's Pacman written in?

Sigi · 2006-08-22 06:45:43

patson wrote:

I'm not suggesting making the installer newbie-friendly, I'm suggesting making it user-friendly. Big difference.

I agree

gradgrind · 2006-08-22 09:03:05

I was also rather unhappy with the Arch installer, which is why I wrote my own for my larch project. It's pretty basic and a bit rough around the edges, but it satisfies my current needs.

I wrote it in python and bash, and would certainly recommend using scripting languages - interactive development is much easier than with C etc., and I don't see any advantages of C for such a project. I chose a 'dialog' front end so that it can also run without X.

Please take a look at it. It won't do everything you want, but suggestions are very welcome.

Sigi · 2006-08-22 09:16:56

btw, gradgrinds installer is included in larch

More info about larch

dolby · 2006-08-22 10:02:10

only thing i "dislike" about the arch installer is that when one mounts the partitions he cant see the changes he made afterwards before pressing Done.

although u can make sure afterwards when editing fstab its possibly a bit late to fix the possible "errors"

patson · 2006-08-22 10:51:03

gradgrind wrote:

I was also rather unhappy with the Arch installer, which is why I wrote my own for my larch project. It's pretty basic and a bit rough around the edges, but it satisfies my current needs.
I wrote it in python and bash, and would certainly recommend using scripting languages - interactive development is much easier than with C etc., and I don't see any advantages of C for such a project. I chose a 'dialog' front end so that it can also run without X.
Please take a look at it. It won't do everything you want, but suggestions are very welcome.

I will certainly check that out, thanks for the tip.

I'd do it in C, as that allows for writing a completely unified UI using ncurses, although Dialog would probably accomplish a large number the very same tasks... Also, even though bash is easily ported, I don't see why we couldn't have a specific installer binary on the disc - it'd require even less dependencies, look better and probably be lighter.

Besides, I just thought about that it could spawn a sub-project - a menu-driven package selector/installer - although there is nothing wrong with using Pacman from the command line, I don't see anything wrong with using a menu either, especially if it comes nearly for free (provided I write the installer ).

Still no word from the arch developers, though. This is not about getting me a better installer, it's about getting everyone a better default with Arch.

You've got a great thing going here. I'm just trying to contribute (fixing the weakest parts ).

BTW, I don't really see C being that much more 'difficult' - it's certainly a hell of a lot easier to debug than long bash scripts. And I like handling data at a byte level

test1000 · 2006-08-22 11:52:16

Although i haven't looked at arch installer in a long while, and although i now feel much more confident in my general computer abilites and know bash, unlike last time i installed arch (was a complete linux noob) -- I remember the installer to be a usability nightmare, yes. Maybe that has changed now that i'm more experienced, or maybe not but it could most certainly require a bit of tweaks here and there to make it better so I welcome you to try it out

patson · 2006-08-22 16:36:08

test1000 wrote:

Although i haven't looked at arch installer in a long while, and although i now feel much more confident in my general computer abilites and know bash, unlike last time i installed arch (was a complete linux noob) -- I remember the installer to be a usability nightmare, yes. Maybe that has changed now that i'm more experienced, or maybe not but it could most certainly require a bit of tweaks here and there to make it better so I welcome you to try it out

I'd wager not being able to correct mistakes or see what you're doing being equally frustrating for newb and expert alike...

(syntactically correct sentance, but a bitch to parse )

Simastrick · 2006-08-22 16:49:10

I agree with patson. The partition-setup part of the installer is kind of scary.

beniro · 2006-08-22 20:09:36

I totally support patson (or anyone) doing work on the installer. It would be nice if the work done was done with modularity and flexibility in mind. Something along the lines of phrakture's project mentioned above.

postlogic · 2006-08-22 20:13:59

I have no trouble using the partitioner or the rest of the installer in any way. It's dead simple and intuitive. Also, the partitioner, cfdisk, is not made by the Arch devs. And it works.

If partition is a mess, just write down the names of what you need to remember. What's hard about that? The package stuff is also simple if you keep to the base. Just leave it all, or perhaps remove the boot loader you don't use. Frankly, I find Anaconda and similar installers pretty crap. They are not simple compared to the Arch installer.

Oh and doing it 5 times over? That's 50 minutes. That's still less than some distros.

patson · 2006-08-22 20:28:31

beniro wrote:

I totally support patson (or anyone) doing work on the installer. It would be nice if the work done was done with modularity and flexibility in mind. Something along the lines of phrakture's project mentioned above.

Hmm, actually, I was thinking of doing a rewrite in C, creating a simple pseudo-module API (modules would still need to be #include'd into the main program), using a fully statically linked binary for the release version. It'd still launch cfdisk, nano/vim and whatnot, so it'd not be like writing a new operating system... ;-)

I'm still going through ideas and trying to think of the best way to go about the whole thing - I mean, I want to do it with a proper programming language, without needing to bundle a heavy interpreter (which rules out both java and python - I'd like the setup program itself to have both small memory and disk footprint). Bash gets pretty tedious to work with if you don't have exact specs from the beginning (and these, sadly, tend to change with any non-trivial project). Also, going with C and ncurses would let me write my own lightweight whiz-bang console interface.. Kind of set it apart from the competition..

By now, I've psyched myself to do the project regardless of developer opinion - if someone's doing something to the installer, it's being done pretty silently. This week's evenings will most likely be spent hacking around with ncurses (haven't touched it in a year or so), and thinking about API specs and such. I know it's not THAT big a project (only needs to provide a menu and run a few short subprograms), but if I'm going to do it I'd rather do it properly from the start. That, and I don't feel like hacking up the original installer (I'll read the source, be it bash or even COBOL), but in my experience modifying someone else's code should be avoided if possible (and if you're not specifically getting paid to do it ).

Also, be aware that, as always, this is not an official announcement or anything, and there's always the slightest chance that the final product may fail to materialize (Duke Nukem Forever, anyone? ), but I'll do my best to find the time to write it. I really like what Arch is, I feel that, with a little polish, it could be the best (polish like, for example, coloured output for Pacman on systems that support it (not the language)).

patson · 2006-08-22 20:38:06

postlogic wrote:

I have no trouble using the partitioner or the rest of the installer in any way. It's dead simple and intuitive. Also, the partitioner, cfdisk, is not made by the Arch devs. And it works.
If partition is a mess, just write down the names of what you need to remember. What's hard about that? The package stuff is also simple if you keep to the base. Just leave it all, or perhaps remove the boot loader you don't use. Frankly, I find Anaconda and similar installers pretty crap. They are not simple compared to the Arch installer.
Oh and doing it 5 times over? That's 50 minutes. That's still less than some distros.

My beef is with the current usability of the installer. Sure, it's simple enough, but (if you'd read the previous comments you'd know this), it's frustrating not being able to cancel out of an operation (such as specifying mountpoint), and not being able to see what you've done.

And yes, I do know that the actual partitioning is done using cfdisk (which is, really, a good program and a good choice) - what I'm talking about is specifying partition mount points - if you've got, say, six partitions with stuff you want to save, and four partitions that you want to wipe, how sure are you that you didn't accidentally select "create filesystem" for one of those critical partitions you wanted to just make accessible? When you press done it may be bye bye to your code lib
I know the simple answer would be not to do that, but then again, it'd be nice to do in the installer since the option is there, wouldn't it?

And besides, I've already decided to do the project regardless of opinion. It'll be done when it's done... Hopefully at alpha/beta before Arch 0.9.x (although I'm not making any promises). It all depends on how much free time I can get.

patson · 2006-08-22 20:44:42

...Now that my original question is sort of answered ("should I do this?"), I'd like to know your opinions about what a good installer should have (and, by extension, shouldn't). As long as there is no code written, suggestions and wishes are easy to incorporate (not so easy once the API has been specced out), provided they are simple and sane. And before you begin: no, I will not do autoconfiguration/autodetection stuff, it's not within the project's scope. So don't even bother asking...

Dusty · 2006-08-22 21:07:47

Even though you've got the "Should I do This" answer, I'll give you a little more. If you do the project and do a good job (where the definition of good job means: Judd likes it), it will probably get incorporated into Arch proper.

Now, rather than posting here for dev feedback, I'd go to the mailing list, they're a bit more active over there than here. But you're doing the right thing to just go ahead and do it. The devs don't put much stock in people who say "I'm gonna do this". They like people who say "I did this" a lot more. :-)

As for what the installer should do... Its been ages since I did an arch install. I just run pacman -Syu and my machine is happy. Don't remember what the old one did. I think it should be less buggy than the current ubuntu installer though which I happily gave up on in frustration!

Dusty

gradgrind · 2006-08-23 05:51:20

I'd like to know your opinions about what a good installer should have (and, by extension, shouldn't)

Look at what the larch installer does and you will have most of my answer.

I can understand you not wanting a bulky interpreter involved (in larch I didn't see this as a problem as it is integrated into a 'real' Arch system, where one might expect to find python anyway). But I would still see a script language as a better choice than C (readability, ease of modification, maintenance, etc., as well as speed of development - speed of execution should be irrelevant). What about lua or newlisp, for example? They are very small. I can understand you not wanting to use bash, I find it pretty difficult to read, and annoyingly awkward for some quite basic operations.

benplaut · 2006-08-23 07:41:19

i really like the partitioner/fstab creator in the debian and older (curses) ubuntu installs.

Anyone know what it's called, and if it's a standalone program that could be integrated into the installer?

patson · 2006-08-23 09:56:24

gradgrind wrote:

I'd like to know your opinions about what a good installer should have (and, by extension, shouldn't)
I can understand you not wanting a bulky interpreter involved (in larch I didn't see this as a problem as it is integrated into a 'real' Arch system, where one might expect to find python anyway). But I would still see a script language as a better choice than C (readability, ease of modification, maintenance, etc., as well as speed of development - speed of execution should be irrelevant). What about lua or newlisp, for example? They are very small. I can understand you not wanting to use bash, I find it pretty difficult to read, and annoyingly awkward for some quite basic operations.

This question boils down to personal preference.. I agree, that certain scripting languages are faster to develop with than C - however, this is more due to the scripting language providing its own feature-complete API. I have used neither lua nor lisp, sadly, and I'd rather not use an unknown language in an important project without first being aware of its capabilities and limitations (things which you only learn by stumbling over them). As for ease of readability, I must say I prefer cleanly written and properly documented C and Java source over any alternatives. But then again, pretty much any source looks readable to people who use the language..

benplaut wrote:

i really like the partitioner/fstab creator in the debian and older (curses) ubuntu installs.
Anyone know what it's called, and if it's a standalone program that could be integrated into the installer?

I happen to like the way Debian's installer does things, as well. I believe it's done mostly in perl and bash scripts, however I've never actually looked at the partitioning part. I'll see if it can be merged into the project (meaning I'd only take bits and pieces from it, not just bolt it on, as that rarely provides satisfactory results).

Arch Linux

#1 2006-08-22 05:53:40

Improving the installer?

#2 2006-08-22 06:00:38

Re: Improving the installer?

#3 2006-08-22 06:04:13

Re: Improving the installer?

#4 2006-08-22 06:09:58

Re: Improving the installer?

#5 2006-08-22 06:10:18

Re: Improving the installer?

#6 2006-08-22 06:14:23

Re: Improving the installer?

#7 2006-08-22 06:17:41

Re: Improving the installer?

#8 2006-08-22 06:39:11

Re: Improving the installer?

#9 2006-08-22 06:45:43

Re: Improving the installer?

#10 2006-08-22 09:03:05

Re: Improving the installer?

#11 2006-08-22 09:16:56

Re: Improving the installer?

#12 2006-08-22 10:02:10

Re: Improving the installer?

#13 2006-08-22 10:51:03

Re: Improving the installer?

#14 2006-08-22 11:52:16

Re: Improving the installer?

#15 2006-08-22 16:36:08

Re: Improving the installer?

#16 2006-08-22 16:49:10

Re: Improving the installer?

#17 2006-08-22 20:09:36

Re: Improving the installer?

#18 2006-08-22 20:13:59

Re: Improving the installer?

#19 2006-08-22 20:28:31

Re: Improving the installer?

#20 2006-08-22 20:38:06

Re: Improving the installer?

#21 2006-08-22 20:44:42

Re: Improving the installer?

#22 2006-08-22 21:07:47

Re: Improving the installer?

#23 2006-08-23 05:51:20

Re: Improving the installer?

#24 2006-08-23 07:41:19

Re: Improving the installer?

#25 2006-08-23 09:56:24

Re: Improving the installer?

Board footer