Do we really need our own installer?

Do we really need our own installer?

[Hartmut Goebel]

[-- Attachment #1: Type: text/plain, Size: 3759 bytes --]

Hello,

I would like to bring this topic to discussion: Do we really need our
own installer? No offense meant, I strongly appreciate John's and
Danny's work on the installer. I just have some doubts if this is the
way to follow further.

Foreword: One of the really cool things about guix is that everything is
at hand: Building packages, VM, disk-images, even the iso-images for
installation. Where for other distributions you need additional tooling,
for guix you need just to type a command. That's really great.

But do we really need our own installer? Why can't we "just" adopt an
existing one to our needs? Does the installer need to be part of the
"guix system" command?

As you may have read the last days, I tried installing GuixSd from the
installation medium the first time – and had quite some trouble let
alone the partitioning. Because of this I demanded the graphical installer.

Today I tried the graphical installer and got a bit shocked. Not about
the installer being in a quite early stage (that's what I'd expected),
but about the enormous pile of stuff still need to be implemented: LVM,
encrypted disks, a partitioning-tool friendly to beginners, filtering
unusual keyboards, pre-setting the keyboard based on language selection,
setting up the graphic display, and so on. And after this is done, we
still have a old-fashioned ncurses installer, not a GUI. This is not
attracting people.

A possible solution would be to adopt an existing installer to our
needs. This *may* not allow to fully leverage the features of guix
within the installer (but IFAIR guile can be accesses from C), but my
assumption is we only need parts of it.

On the pro-side we may get a much more capable installer much quicker.

On the down-side, we can no longer integrate the installer into "guix
system". Which brings me to the next question: Should there be something
like "guix system installer"?

IMHO there should not be something like "guix system installer" for
these reasons:

- To complete the installer (to be par with other tools), a lot of code
needs to be added. But this stuff is only used for installing a system,
which means a very short time in the life-time of a system. It is not
used for disk-images, virtual machines and containers.

- It adds ncurses to the requirements and thus increases the minimal
system footprint of guix.

- If we (later) want to implement a X11-based installer, we can not
include this into "guix system installer", so we need to implement
something different – which will either lead inconsistency and trouble.

What do you think?


FYI: I *briefly* looked at Anaconda [1] (used by RH/Fedora, implemented
in Python3, C, and GTK+, which also as a text-based interface, and
Clamares [2] ("a distribution-independent system installer", implemented
in C++, Python and Qt). There also are * Ubiquity [3] (used by Ubuntu,
written in Python and GTK+) and the Debian installer [4] (written in C
and *may* still have a ncurses interface).

Calamares seems to be most actively developed, supports branding and
seems to have a nice design, splitting between "Vies" and "Jobs".
Anaconda as a text-ui, which is a good thing, but documentation is
terse. From the Debian installer I would retire since C IMHO is too low
level – and I mind to remember Debian is lagging a lot.

[1]https://en.wikipedia.org/wiki/Anaconda_installer
[2] https://calamares.io/
[3] https://en.wikipedia.org/wiki/Ubiquity_(software)
[4] https://en.wikipedia.org/wiki/Debian-Installer

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |


[-- Attachment #2: 0xBF773B65.asc --]
[-- Type: application/pgp-keys, Size: 14855 bytes --]

Re: Do we really need our own installer?

[Ricardo Wurmus]

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> But do we really need our own installer? Why can't we "just" adopt an
> existing one to our needs? Does the installer need to be part of the
> "guix system" command?

The reason why we have a draft curses installer is because John actually
wrote it.  We may be able to adopt an existing graphical installer, but
to my knowledge nobody has investigated this closely enough yet.

The curses installer currently is the closest we have to an installer.
If you feel motivated to take on the work to explore existing GUI
installers, do not let us stop you :)

Originally, we wanted to have an installer that does not hide the Scheme
configuration and lets users play with it.  We wanted to have something
that is a step up from manually following the steps outlined in the
manual.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Do we really need our own installer?

[Ludovic Courtès]

Hi Hartmut,

I think your arguments hold, but it’s just one side of the story.

The other side of the story is that having our own installer, while
being an additional burden, also means we can adapt it more easily and
offer better integration—for instance, the fact that it knows about
‘operating-system’ declarations and services means that it could perform
sanity checks, offer users to “browse” their OS declaration, and so on.

And last but not least: the installer exists now, which makes the
question kinda moot IMO.  :-)

Ludo’.

Re: Do we really need our own installer?

[Hartmut Goebel]

Am 22.09.2017 um 16:26 schrieb Ludovic Courtès:
> And last but not least: the installer exists now, which makes the
> question kinda moot IMO.  :-)

The question was more about in which direction will the project go
further: Continue to develop the current one or build on an existing
full-featured one. Following the pure tenets or attracting more users by
compromise.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Do we really need our own installer?

[Ricardo Wurmus]

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> Am 22.09.2017 um 16:26 schrieb Ludovic Courtès:
>> And last but not least: the installer exists now, which makes the
>> question kinda moot IMO.  :-)
>
> The question was more about in which direction will the project go
> further: Continue to develop the current one or build on an existing
> full-featured one. Following the pure tenets or attracting more users by
> compromise.

This is not a binary choice.  We can do both.

Since the custom installer already exists and there are people who
continue its development I don’t see why we should give it up.

This will never be a graphical installer, though, so motivated people
are very welcome to explore ways to adapt existing graphical installer
frameworks so that we can use them with Guix.

This is not a question of “purity”.

I for one would like to be able to let people install GuixSD with a
simple graphical installer.  Personally, though, I don’t think that’s as
urgent as making GuixSD installable via PXE in managed environments.
Installation makes up only a tiny amount of the lifetime of a GuixSD
system, so in my opinion the project doesn’t really need a large scale
effort on this end.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Do we really need our own installer?

[Hartmut Goebel]

Am 25.09.2017 um 16:35 schrieb Ricardo Wurmus:
> This is not a binary choice.  We can do both.

I agree, but porting an installer is a lot of work and Ludo's answer was
not quite encouraging for me. (No offense meant). So I might spend my
time on other projects :-)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

GuixSD on PXE (was: Do we really need our own installer?)

[Adonay Felipe Nogueira]

Should we really have instructions to do so?

There are two possibilities:

- One uses GuixSD with PXE to access his own computer. No services like
  "Internet caffe" or "thin clients" are provided *to* third-parties.

- Someone decides to use GuixSD in PXE to provide the services described
  in the previous item.

One option would also involve discouraging the second item, with a link
to the address given in the next paragraph.

For more detail, see
<https://www.gnu.org/philosophy/who-does-that-server-really-serve.html>.

Ricardo Wurmus <rekado@elephly.net> writes:

> Hartmut Goebel <h.goebel@crazy-compilers.com> writes:
>
>
> This is not a binary choice.  We can do both.
>
> Since the custom installer already exists and there are people who
> continue its development I don’t see why we should give it up.
>
> This will never be a graphical installer, though, so motivated people
> are very welcome to explore ways to adapt existing graphical installer
> frameworks so that we can use them with Guix.
>
> This is not a question of “purity”.
>
> I for one would like to be able to let people install GuixSD with a
> simple graphical installer.  Personally, though, I don’t think that’s as
> urgent as making GuixSD installable via PXE in managed environments.
> Installation makes up only a tiny amount of the lifetime of a GuixSD
> system, so in my opinion the project doesn’t really need a large scale
> effort on this end.
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, use o GNU Ring ou o Tox.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.