Improving the installer?

beniro · 2006-08-23 13:31:16

patson: Are you signed up for the Arch mailinglist? Sometimes, the conversations there are bit mroe involved...though I'll admit I haven't been on the list in a bit...a year.

You might be able to have a higher-level conversation there.

test1000 · 2006-08-23 14:21:15

I have just done some thinking, and i'm thinking i rather like the installer. I mean, maybe include qtparted/gparted in addition to cfdisk for people who doesn't feel like deleting their windows partition, and provide some sane standards for windows and arch etc commented out in the grub menu.lst for ppl who haven't fineread the grub manual.

I don't really want python as that is the 1# program language which have bombed out on me most when testing random apps/games from the net, but maybe this is not so much of an issue when one includes the python interpreter on the disc...

other than that i can't remember, the installer is a bit hardcore now isn't it? It's not like one can't be a bit friendly to the noobs by including some hints while not destroying the installer for nerds.

phrakture · 2006-08-23 14:57:01

Holy hell, lots of posts... let me try and sort through this:

Re:I was working on something
It's still in the "planning" stages. I have a pseudo python setup, but ncurses in python is overly complex (not pythonic). Read more below for other "stuff"

Re:Choice of language
The choice of language is moot in this case. Everything will be dependant on user input and will be passed off to ready-bake apps (cfdisk?) as there is no way I'm writing my own disk partitioning. Python makes modularity much easier than C or C++, and believe me, I'd be the first one to pimp C++.
The real point here is that, unless someone else provides something, the devs, as a whole, are more comfortable working with a python installer than a C one.

As of right now, I seem to have fallen into the "installer guy" role, so if you'd like to "back-and-forth" about it, you can always email me (aaron at archlinux dot org). I have a progression I'm going for at the moment and haven't gotten to the installer portion of this yet.

apeiro · 2006-08-23 23:33:58

Poor phrakture, he's up to his eyeballs in Arch stuff right now (btw, kudos for the mkinitcpio stuff -- you've done a helluva job)

A new installer would be right cool. No developers have the time to really take on that behemoth of a task right now, so we've been stoically ignoring it. I will shower you with praise if you can pull it off, patson.

As for choice of language, Phrak brings up a couple good points. Modularity will probably be less hairy in a scriptable environment, as well as the communication back and forth between external utility programs (mkfs, cfdisk, pacman, etc) simply because string work in C/C++ is not fun.

Code maintainability is one to think about as well. You may write a super cool installer, but then if you fall off the face of the planet, someone else will have to pick up where you left off if the installer ever needs to evolve to support new things. If it's an unruly mess of C/C++ code, then no one's going to want to go near it.

My two shiny pennies.

- J

deficite · 2006-08-24 00:42:04

I don't consider myself to be a n00b at all, yet I feel that Arch's installer is less than optimal. I personally find archbootstrap to be the best, fastest, and easiest way to set up Arch, IMHO of course.

patson · 2006-08-25 16:53:51

Thanks for the replies, devs.

I don't really have aspirations to become the "arch installer guy", but I would like to provide you guys with a better installer, so I'll definitely be documenting every aspect of the project (design and implementation), so that the guy who decides to make changes to the installer wouldn't need to OD on aspirin.

I, personally, think C is the way to go, at least for the installer core, as ncurses and big data handling is easy and fast to do with it. Also, I'm not put off by "hard string handling" - it can be tough sometimes, and java style string and array handling does have its benefits, but for the sake of the project, it'll not be too overkill. Adding scripting support to the project at any stage should not be too hard, as both python and perl plug nicely into C apps. Anyway, this is quite a project to undertake, and I'm still trying to figure out the best ways to attack the problem. That, and it seems I need to do some intensive-developing of a game next week, but let's hope I also get some time to work on the installer UI code. I'll check back here when I have something to show.

Anyway, thanks for making a great distro.

paranoos · 2006-08-25 17:13:47

i think arch already has a great installer on the cd: the quickinst script. no hassles or anything. it's just a bash script calling pacman to install each of the base packages to your mounted arch partitions. either from the cd or via ftp.

basically, you partition, format, and mount everything by hand, get your net connection up if you're doing an ftp install, then run quickinst, edit all the neccessary configs, and reboot. happy computer.

phrakture · 2006-08-25 17:17:57

patson wrote:

I, personally, think C is the way to go, at least for the installer core, as ncurses and big data handling is easy and fast to do with it.

Every other language supports ncurses as well, and there is no "big data handling" - installed packages are managed by pacman, partitioning is managed by something else (cfdisk? maybe a UI to collect info, then popen a fdisk process?), config files are edited by any editor.

An installer actually has very little data. It should be just a UI on top of different concepts, which are easilly handled by other applications.

Personally, the reason I wanted to do this in python is two-fold. First off, is the ease with which you can drive another app via code (popen/subprocess). Using other applications to do specialized tasks _should_ play a large part in the installer, as this is the core arch philosophy (KISS) and one of the rules of unix programming as a whole (do one thing, and do it well).

The second reason is that, in essence, an installer is just a UI. Including package installation routines in the installer is dumb, as pacman handles that far better than any code I could concoct without including the whole pacman source in the app. Including config editing capability is equally as inane as there are 100 editors out there which do a far better job than I could do in a few months of making an editor. Partitioning? Do _you_ want to use largely untested code I wrote to partition your drive, or would you rather use an app that has been around for 10+ years?

The installer is mostly a set of rules with a UI on top of it.

Because of this, and because of the dynamic-ness of python, it would be rather easy to replace the same UI with a different "toolkit" on the fly. By this, I mean, that the same installer code-base could be used with a "CLI interface" or a "ncurses interface" or even "gtk interface" or a "config file interface". The same code gets used with a slightly different appearance to the end user.

Sure this is doable in any language, but python based code will be much more maintainable.

gradgrind · 2006-08-26 07:41:41

Hear, hear! I'm with phrakture all the way on this one.

Simastrick · 2006-09-04 19:31:19

I think the worst part of arch installation is during the setting of mount points. For every mount point you set, you get asked:

Do you want to create a filesystem?

(or something like that), and 'OK' is highlighted by default. An extra accidental enter is all you need to totally wipe away a preexisting partition.

That is so fucking nerve-wracking.
(That is, if I remember things correctly.)

Romashka · 2006-09-11 13:40:15

IMHO adding cdspeed would be usefull for some users.

tomfitzyuk · 2006-09-11 17:21:32

Simastrick wrote:

I think the worst part of arch installation is during the setting of mount points. For every mount point you set, you get asked:
Do you want to create a filesystem?
(or something like that), and 'OK' is highlighted by default. An extra accidental enter is all you need to totally wipe away a preexisting partition.
That is so fucking nerve-wracking.
(That is, if I remember things correctly.)

Also, I don't think you can setup partitions upon installation without creating a filesystem on them (i.e. a home directory).

I like how the installation has a proper main menu so you can choose to ignore certain steps. For example, I use the Arch CD to install GRUB if ever I write over my MBR (like after installing Windows).

I do agree that the installer should use existing tools rather than implementing its own... cfdisk, pacman, vi, etc.

deficite · 2006-09-11 23:37:53

I think I'd be happy with the installer if it had ndiswrapper on the CD where all I'd have to do is switch out the disc in the drive (I can't remember if Arch's install disc allows this), load up the inf file, and then swap back to the install disc. (Of course, if the devers want to do the arduous task of collecting a bunch of wireless drivers and sticking them on there; all the better. I use the rt2570 driver )

Also, I've never ever been able to get USB flash drives to work. I don't know why. It doesn't even create the device for it and when it does (by random) it'll say that there isn't really a flash drive and that it's just my imagination (There is no spoon)

phrakture · 2006-09-12 14:33:59

deficite wrote:

I think I'd be happy with the installer if it had ndiswrapper on the CD where all I'd have to do is switch out the disc in the drive (I can't remember if Arch's install disc allows this), load up the inf file, and then swap back to the install disc. (Of course, if the devers want to do the arduous task of collecting a bunch of wireless drivers and sticking them on there; all the better. I use the rt2570 driver )

Yeah, it's also easy to scan for all inf files, and just install them one by one until one succeeds. Adding real wireless drivers is also an option.

Eliatamby · 2006-09-13 13:59:21

I hope you go through with this and it's successfull, and I hope you ignore the jokers quoting Arch's policy on GUIs, because

1) The lack of proper usability and functionalty doesn't imply KISS. The Arch install is an example of KIP (painful).

2) The installed already has a gui anyway!! what is ncurses? It's a a text based graphical user interface. A gui less install would have to be done from the command line..

Once again, I hope you can do this well

phrakture · 2006-09-13 14:49:20

Eliatamby wrote:

2) The installed already has a gui anyway!! what is ncurses? It's a a text based graphical user interface. A gui less install would have to be done from the command line..

I agree 100%, but I also don't feel that the "no gui" policy is the same as you see it - I see GUI configuration as a "helper", but an end user should not be _required_ to use the GUI.

Lone_Wolf · 2006-09-13 18:00:29

Just out of curiosity : where can an end user find instructions to install arch from the commandline WITHOUT using any UI.

phrakture · 2006-09-13 18:32:04

Lone_Wolf wrote:

Just out of curiosity : where can an end user find instructions to install arch from the commandline WITHOUT using any UI.

http://wiki.archlinux.org/index.php/Usi … Arch_Linux

quickinst is included on the installation cds

Eliatamby · 2006-09-14 01:26:07

phrakture wrote:

Eliatamby wrote:
2) The installed already has a gui anyway!! what is ncurses? It's a a text based graphical user interface. A gui less install would have to be done from the command line..
I agree 100%, but I also don't feel that the "no gui" policy is the same as you see it - I see GUI configuration as a "helper", but an end user should not be _required_ to use the GUI.

Yeah you're right, but I often see people implicity provide this interpretation when we talk about updating various interfaces (like the install). But yes, what you say is the correct way of looking at the "GUI policy"

Romashka · 2006-10-05 08:51:38

For me, there are several choices of possible UI toolkits for installer:dialog
ncurses
newt
GTK+ on DirectFB (used in new Debian's installer)
FLTK on DirectFB
LiTEI discovered LiTE only recently and it seems very interesting.

phrakture · 2006-10-05 14:46:11

I dislike directfb - if I was going that route, I'd use svga.

Romashka · 2006-10-05 17:14:19

Why do you dislike DirectFB? I didn't tried it yet, but I want, so I would like to know your opinion about it.

As for SVGAlib - it's looks simlper but as I see it is not actively maintained (no new dev snapshot more than a year). And it has a bit outdated drivers (only old cards tested).

There are also GGI and KGI. ;-)

Oh, and SDL can be used with framebuffer too. And it has already available GUI toolkits. I like SDLtk the most.

Romashka · 2006-10-06 09:00:15

BTW, have you seen the installer in Underground Linux (LUDOS)? (It's larch-based Arch Live CD with KDE packages already on it.) It has some improvements over current installer.

rawfuzz · 2006-10-09 04:15:55

I'm not even using linux anymore, but I'm looking forward on installing "Voodoo" whenever it'll get released. I did tried it once tho, and I've found the installer to be too basic. It didn't allow me to do any customization whatsoever (eg: filesystem tuning). I ended up switching VTs to do the partitions & tune2fs 'em. To stay on topic, the installer needs to be simple in design and rich in features. Also, if the distro is not based in the States, you could add CFS to the CD and allow users to encrypt their partitions. Oh, is LVM2 in the current installer?
Gonna go to sleep and come up wih fresh ideas tomorrow morning.. that's if anybody is interested in 'hearing' them

Romashka · 2006-10-23 16:32:51

BTW, phrakture, here's a nice library written in Python for creating text UI in console. It even supports UTF-8! Maybe you should take a look at it.

http://excess.org/urwid/

Arch Linux

#26 2006-08-23 13:31:16

Re: Improving the installer?

#27 2006-08-23 14:21:15

Re: Improving the installer?

#28 2006-08-23 14:57:01

Re: Improving the installer?

#29 2006-08-23 23:33:58

Re: Improving the installer?

#30 2006-08-24 00:42:04

Re: Improving the installer?

#31 2006-08-25 16:53:51

Re: Improving the installer?

#32 2006-08-25 17:13:47

Re: Improving the installer?

#33 2006-08-25 17:17:57

Re: Improving the installer?

#34 2006-08-26 07:41:41

Re: Improving the installer?

#35 2006-09-04 19:31:19

Re: Improving the installer?

#36 2006-09-11 13:40:15

Re: Improving the installer?

#37 2006-09-11 17:21:32

Re: Improving the installer?

#38 2006-09-11 23:37:53

Re: Improving the installer?

#39 2006-09-12 14:33:59

Re: Improving the installer?

#40 2006-09-13 13:59:21

Re: Improving the installer?

#41 2006-09-13 14:49:20

Re: Improving the installer?

#42 2006-09-13 18:00:29

Re: Improving the installer?

#43 2006-09-13 18:32:04

Re: Improving the installer?

#44 2006-09-14 01:26:07

Re: Improving the installer?

#45 2006-10-05 08:51:38

Re: Improving the installer?

#46 2006-10-05 14:46:11

Re: Improving the installer?

#47 2006-10-05 17:14:19

Re: Improving the installer?

#48 2006-10-06 09:00:15

Re: Improving the installer?

#49 2006-10-09 04:15:55

Re: Improving the installer?

#50 2006-10-23 16:32:51

Re: Improving the installer?

Board footer