[GSoC] Draft proposal for an Install Wizard for Guix

[GSoC] Draft proposal for an Install Wizard for Guix

[Thomas Ingram]

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

Hello,

I'm a big fan of the project and I'd like to help write an installer for 
GuixSD this summer for GSoC I'm including a plain text version of my 
draft proposal I'm about so submit to the GNU GSoC page. Any feedback or 
suggestions would be very helpful.

Sorry this comes so late in the application process, I hope I can still 
be considered.

Thanks
Thomas Ingram

[-- Attachment #2: guix-proposal.txt --]
[-- Type: text/plain, Size: 4366 bytes --]

Name: Thomas Ingram
Email: taingram@mtu.edu
Jabber: delimiters@dukgo.com
IRC: adverb (freenode)

Project: Installer Wizard for GuixSD

Summary:

Currently GuixSD is not very easy to install, my goal is to create a
easy to understand ncurses interface that will walk users through
installation. This would be similar to the Debian installer or other
Linux/BSD installers providing options for partitioning and setting up
new users along with other installation options.

Benefits:

Make GuixSD a more appealing to new users who are accustom to other
distributions that come with a graphical installer.

Deliverables:

A nice ncurses installer, written in GNU Guile, that lets users
partition disks and install GuixSD in a clear easy to understand
way. Partitioning will allow for custom setups and also offer several
default "most common" options such as:

  Simple all in one big partition on one disk
  Separate root and home
  LVM/LVM encrypted (this would probably be more difficult to add)

The installer will also include steps on setting up new users
username, passwords, root password, and sudo access.

In addition the installers should be written in such a way that it
could be hooked into different UI's other than the ncurses one (For
example fhmgufs on IRC was talking about perhaps a Gtk+ one). This is
important as I admit ncurses is not the prettiest.

The installer could also give users the option of which desktop
environment they wish installed onto their system by default. This
could be done by giving the user the option to connect to the internet
while installing and then the chosen desktop environment packages
could be downloaded over the network.

Plan:

  Before the summer starts:

I will be reading up on the ncurses documentation and guile writing
small programs to practice and prepare. I've been programming in
scheme for six months so I'm still a relatively novice schemer, but
will work hard to improve in the following months.

I'll look at the source code of other installers like
debian-installer, Ubiquity, and others in order to understand how the
accomplish what the do and what features they offer. This will give me
an idea of where to start and what level of features we will want.

I will also become very familiar with the installation process of
GuixSD as it currently exists in order to better understand how to
automate the process. Also I will become more familiar with the Guix
code base in order to follow the same style and such in my own code.

  Once the summer has started:

I will begin to write tools and a UI in ncurses to walk users through
installing GuixSD onto their machine. I'll start by getting the basic
interface and partitioning done then once that is done I will move on
to adding and setting up new users and setting the root
password/setting up sudo.

Stretch goals: once that is completed and working well adding more
options like picking between different desktop environments.

Communication:

I am subscribed to the GNU Guix mailing list and frequently am hanging
out in the #guix on freenode with the nick adverb. I can also talk
over Jabber my username is delimiters@dukgo.com. I'm open to talking
over any other platforms, preferably free software ones though.

Qualifications:

I have been using GNU Linux and other Unix-like systems since 2013. I
started with Ubuntu and OpenSUSE, then I used Arch Linux for over a
year, and have more recently been using Debian. I distro hopped
frequently in the past three years so I have a lot of experience with
good and bad installers as well as different systems.

I've been programming since 2012 when I started Python programming,
since then I've been programming Java for two years and taken classes
on it in high school and at my University. I have been programming in
C for a little over a year and am currently taking a introductory
course on C. I became interested in Lisp in the fall of last year and
began learning scheme in my spare time. Since I learning Guix would be
participating in GSoC I have been spending much more of my time
learning the ins and outs of GNU Guile in the hopes of getting accepted
to the project.

Although I have not previously contributed to free software I have
always wanted to contribute back to free software. I have run GNU
Linux exclusively for the past three years and care deeply about user
freedoms.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Chris Marusich]

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

Thomas Ingram <taingram@mtu.edu> writes:

> Project: Installer Wizard for GuixSD

Sounds useful!  I have a some shell scripts that I use to "reproducibly"
install GuixSD on my laptops, but they're not very elegant at the
moment, and they hard-code marusich-specific things in places.  If you'd
like to see them, I'd be happy to share.  I would love to see them get
replaced with a nice guile-based installer!

> Partitioning will allow for custom setups and also offer several
> default "most common" options such as:
>
>   Simple all in one big partition on one disk
>   Separate root and home
>   LVM/LVM encrypted (this would probably be more difficult to add)

Is this different from LUKS?  I use LUKS today to encrypt my home
partition (but not my root partition), and I use shell scripts to script
the installation process.  It's quite easy with LUKS. For example, if
you made a partition /dev/sda2, and you want to use it as an encrypted
home partition, it's sufficient to do this:

--8<---------------cut here---------------start------------->8---
# cryptsetup luksFormat /dev/sda2
# cryptsetup luksOpen /dev/sda2 encrypted-user
# mkfs.ext4 -L user /dev/mapper/encrypted-user
--8<---------------cut here---------------end--------------->8---

And then include something like this in your operating system
configuration file

--8<---------------cut here---------------start------------->8---
(operating-system
...
  (mapped-devices (list (mapped-device
                         (source "/dev/sda2")
                         (target "home")
                         (type luks-device-mapping))))
...
--8<---------------cut here---------------end--------------->8---

Accomplishing the same thing using guile can't be too hard.

One more thing to consider.  While you write this installer, you might
want to think about how we can make the installation process itself as
reproducible as possible.  One of Guix's features is reproducible
software builds.  Shouldn't GuixSD also make it possible to reproduce
the process of partitioning the system's disks, making its filesystems,
and configuring the system for the first time?

Some existing software attempts to solve this specific problem.  For
example, RedHat's Kickstart installation process provides a way to
automate the installation of RedHat's brand of GNU/Linux.  Something
that solves this same problem for GuixSD would be great!  Even if this
is out of scope for your project this year, it would be great if in the
future we could stand on the shoulders of what you create to add such a
feature with minimal additional effort.

> Although I have not previously contributed to free software I have
> always wanted to contribute back to free software. I have run GNU
> Linux exclusively for the past three years and care deeply about user
> freedoms.

That's wonderful!  Thank you for taking the time to help improve the
world :)

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Ricardo Wurmus]

Chris Marusich <cmmarusich@gmail.com> writes:

>> Partitioning will allow for custom setups and also offer several
>> default "most common" options such as:
>>
>>   Simple all in one big partition on one disk
>>   Separate root and home
>>   LVM/LVM encrypted (this would probably be more difficult to add)
>
> Is this different from LUKS?

No.  LUKS is used at the bottom across the whole device (e.g. /dev/sda)
and LVM is used on top of it.  You’d first unlock the LUKS partition
with

    cryptsetup luksOpen /dev/sda1 root

and then create a PV on /dev/mapper/root, add the PV to a volume group
(VG), and then create one or more logical volumes (LV) inside of the VG,
such as /dev/mapper/vg-{home,root,swap}.

Our problem is that the initrd in GuixSD currently does not have any
support for LVM.  I’m using LUKS+LVM for my home directory and I
manually unlock and mount the home directory after booting.

> One more thing to consider.  While you write this installer, you might
> want to think about how we can make the installation process itself as
> reproducible as possible.  One of Guix's features is reproducible
> software builds.  Shouldn't GuixSD also make it possible to reproduce
> the process of partitioning the system's disks, making its filesystems,
> and configuring the system for the first time?
>
> Some existing software attempts to solve this specific problem.  For
> example, RedHat's Kickstart installation process provides a way to
> automate the installation of RedHat's brand of GNU/Linux.  Something
> that solves this same problem for GuixSD would be great!  Even if this
> is out of scope for your project this year, it would be great if in the
> future we could stand on the shoulders of what you create to add such a
> feature with minimal additional effort.

I like that idea.  It would be great if we could pass a kernel parameter
at boot time to initialise the system from a given “operating-system”
configuration file.  Kickstart is very convenient in this manner, but it
relies on terrible macros that nobody seems to really understand.  With
Kickstart I can boot from a thumb drive or a network image, edit the
kernel boot line to add a line like this:

    ks=http://server/config.ks

to install the system according to the configuration outlined in the
Kickstart file “config.ks”.

With GuixSD we would append something like this to the kernel line:

    guix=http://server/config.scm

to fetch “config.scm” over HTTP and instantiate the operating system
configuration it contains.

~~ Ricardo

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Danny Milosavljevic]

> One more thing to consider.  While you write this installer, you might
> want to think about how we can make the installation process itself as
> reproducible as possible.  One of Guix's features is reproducible
> software builds.  Shouldn't GuixSD also make it possible to reproduce
> the process of partitioning the system's disks, making its filesystems,
> and configuring the system for the first time?

Yeah, personally I'd like to have an emacs form which just displays config.scm (and stores it as a normal file) and has some inline documentation on what is what and maybe a treeview instead of visible S-Expression parens - and a validation process whether the stuff makes sense. When you exit, it just instantiates the system.

The partitioning & file system type should also be specified in a declarative way in the config [and arguably it already is].

Basically not a lot different from now but just more user-friendly and catching more mistakes before instantiation.

ncurses actually isn't as flexible - although it has the benefit that the average user is familiar with how it looks.

But it's just my preference, of course.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Ludovic Courtès]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> I like that idea.  It would be great if we could pass a kernel parameter
> at boot time to initialise the system from a given “operating-system”
> configuration file.  Kickstart is very convenient in this manner, but it
> relies on terrible macros that nobody seems to really understand.  With
> Kickstart I can boot from a thumb drive or a network image, edit the
> kernel boot line to add a line like this:
>
>     ks=http://server/config.ks
>
> to install the system according to the configuration outlined in the
> Kickstart file “config.ks”.
>
> With GuixSD we would append something like this to the kernel line:
>
>     guix=http://server/config.scm
>
> to fetch “config.scm” over HTTP and instantiate the operating system
> configuration it contains.

Ah yes, that’d be quite easy to implement and surely useful.  Other bits
of information would be needed though, such as the target root partition
and possibly partitioning and formatting instructions.

Ludo’.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

>> One more thing to consider.  While you write this installer, you might
>> want to think about how we can make the installation process itself as
>> reproducible as possible.  One of Guix's features is reproducible
>> software builds.  Shouldn't GuixSD also make it possible to reproduce
>> the process of partitioning the system's disks, making its filesystems,
>> and configuring the system for the first time?
>
> Yeah, personally I'd like to have an emacs form which just displays config.scm (and stores it as a normal file) and has some inline documentation on what is what and maybe a treeview instead of visible S-Expression parens - and a validation process whether the stuff makes sense. When you exit, it just instantiates the system.

That’d be nice.

> ncurses actually isn't as flexible - although it has the benefit that the average user is familiar with how it looks.

Yeah, and it’s probably more lightweight as well.

Ludo’.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Chris Marusich]

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

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>>> Partitioning will allow for custom setups and also offer several
>>> default "most common" options such as:
>>>
>>>   Simple all in one big partition on one disk
>>>   Separate root and home
>>>   LVM/LVM encrypted (this would probably be more difficult to add)
>>
>> Is this different from LUKS?
>
> No.  LUKS is used at the bottom across the whole device (e.g. /dev/sda)
> and LVM is used on top of it.  You’d first unlock the LUKS partition
> with
>
>     cryptsetup luksOpen /dev/sda1 root
>
> and then create a PV on /dev/mapper/root, add the PV to a volume group
> (VG), and then create one or more logical volumes (LV) inside of the VG,
> such as /dev/mapper/vg-{home,root,swap}.
>
> Our problem is that the initrd in GuixSD currently does not have any
> support for LVM.  I’m using LUKS+LVM for my home directory and I
> manually unlock and mount the home directory after booting.

I see.  Thank you for clarifying that!

>> One more thing to consider.  While you write this installer, you might
>> want to think about how we can make the installation process itself as
>> reproducible as possible.  One of Guix's features is reproducible
>> software builds.  Shouldn't GuixSD also make it possible to reproduce
>> the process of partitioning the system's disks, making its filesystems,
>> and configuring the system for the first time?
>>
>> Some existing software attempts to solve this specific problem.  For
>> example, RedHat's Kickstart installation process provides a way to
>> automate the installation of RedHat's brand of GNU/Linux.  Something
>> that solves this same problem for GuixSD would be great!  Even if this
>> is out of scope for your project this year, it would be great if in the
>> future we could stand on the shoulders of what you create to add such a
>> feature with minimal additional effort.
>
> I like that idea.  It would be great if we could pass a kernel parameter
> at boot time to initialise the system from a given “operating-system”
> configuration file.  Kickstart is very convenient in this manner, but it
> relies on terrible macros that nobody seems to really understand.  With
> Kickstart I can boot from a thumb drive or a network image, edit the
> kernel boot line to add a line like this:
>
>     ks=http://server/config.ks
>
> to install the system according to the configuration outlined in the
> Kickstart file “config.ks”.
>
> With GuixSD we would append something like this to the kernel line:
>
>     guix=http://server/config.scm
>
> to fetch “config.scm” over HTTP and instantiate the operating system
> configuration it contains.

Yes, something like that might be useful.  By the way, I didn't mention
Kickstart because I think it's a good example that we should follow
(although I'm sure we can learn from the way Kickstart and other
existing software solves the problem); it's just the first example that
came into my head.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Mark H Weaver]

Hi Thomas,

Thomas Ingram <taingram@mtu.edu> writes:
> I'm a big fan of the project and I'd like to help write an installer
> for GuixSD this summer for GSoC I'm including a plain text version of
> my draft proposal I'm about so submit to the GNU GSoC page.

Sounds great!

> Deliverables:
>
> A nice ncurses installer, written in GNU Guile, that lets users
> partition disks and install GuixSD in a clear easy to understand
> way.

Another important component would be a wizard to help users configure
their network interface, either wired or wireless.

       Mark

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Ludovic Courtès]

Hi!

(Removing summer-of-code@gnu.org.)

Thanks for your proposal!

Thomas Ingram <taingram@mtu.edu> skribis:

> Plan:
>
>   Before the summer starts:
>
> I will be reading up on the ncurses documentation and guile writing
> small programs to practice and prepare. I've been programming in
> scheme for six months so I'm still a relatively novice schemer, but
> will work hard to improve in the following months.
>
> I'll look at the source code of other installers like
> debian-installer, Ubiquity, and others in order to understand how the
> accomplish what the do and what features they offer. This will give me
> an idea of where to start and what level of features we will want.
>
> I will also become very familiar with the installation process of
> GuixSD as it currently exists in order to better understand how to
> automate the process. Also I will become more familiar with the Guix
> code base in order to follow the same style and such in my own code.
>
>   Once the summer has started:
>
> I will begin to write tools and a UI in ncurses to walk users through
> installing GuixSD onto their machine. I'll start by getting the basic
> interface and partitioning done then once that is done I will move on
> to adding and setting up new users and setting the root
> password/setting up sudo.
>
> Stretch goals: once that is completed and working well adding more
> options like picking between different desktop environments.

I like the goals you’re proposing for this installer.

How would you go implementing it?  The proposal does not explicitly
mention a UI library that would be used, and how the UI code would
interact with Guix and GuixSD code.

I know we’re super close to the deadline, but it would be nice to have a
clearer picture of this.

Thanks!

Ludo’.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Thomas Ingram]

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


On 03/25/2016 09:09 AM, Ludovic Courtès wrote:
> I like the goals you’re proposing for this installer. How would you go 
> implementing it? The proposal does not explicitly mention a UI library 
> that would be used, and how the UI code would interact with Guix and 
> GuixSD code. 
I think most of the installer can be done by generating a config.scm 
with the  operating-system declaration that includes the users input 
settings, and I was planning on writing the installer's UI with the 
guile-ncurses library. How does that sound?

Also included a copy of my final proposal with this.

Thomas Ingram

[-- Attachment #2: guix proposal final.pdf --]
[-- Type: application/pdf, Size: 45238 bytes --]

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[myglc2]

Thomas Ingram <taingram@mtu.edu> writes:

> Hello,
>
> I'm a big fan of the project and I'd like to help write an installer
> for GuixSD this summer for GSoC I'm including a plain text version of
> my draft proposal I'm about so submit to the GNU GSoC page. Any
> feedback or suggestions would be very helpful.
>
> Sorry this comes so late in the application process, I hope I can
> still be considered.
>
> Thanks
> Thomas Ingram

Hey Thomas, this is a very cool proposal.

You said, "I distro hopped frequently in the past three years so I have
a lot of experience with good and bad installers as well as different
systems."

Yeah! Being able to recognize a bad thing is a good thing!

Reading your proposal and another on installation prompted me to write
some general thoughts about Guix installation which you might find
interesting:

http://article.gmane.org/gmane.comp.gnu.guix.devel/18206

Best of luck - George

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Ludovic Courtès]

Thomas Ingram <taingram@mtu.edu> skribis:

> On 03/25/2016 09:09 AM, Ludovic Courtès wrote:
>> I like the goals you’re proposing for this installer. How would you
>> go implementing it? The proposal does not explicitly mention a UI
>> library that would be used, and how the UI code would interact with
>> Guix and GuixSD code. 
> I think most of the installer can be done by generating a config.scm
> with the  operating-system declaration that includes the users input
> settings, and I was planning on writing the installer's UI with the
> guile-ncurses library. How does that sound?

Sounds good!

Personally, I would like to view the “wizard” as a helper, and not as
something that hides everything and turns people into “end users.”

I don’t know how this could translate in the design of the tool.
Perhaps showing the ‘operating-system’ declaration as you suggest is one
thing, and making it easy to view the section of the manual that
corresponds to a particular item, or to jump to the code that defines a
specific service (say), would be helpful too.

Thanks,
Ludo’.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Thomas Ingram]

On 03/26/2016 07:39 AM, Ludovic Courtès wrote:
> Personally, I would like to view the “wizard” as a helper, and not as
> something that hides everything and turns people into “end users.”
>
> I don’t know how this could translate in the design of the tool.
> Perhaps showing the ‘operating-system’ declaration as you suggest is one
> thing, and making it easy to view the section of the manual that
> corresponds to a particular item, or to jump to the code that defines a
> specific service (say), would be helpful too.
Yes as much as it is an installer it should also be an introduction. 
Something that not only lets a user easily input their options but also 
shows them how their settings will be put into config.scm, I'm trying to 
come up with some clever ideas of how to do this in a graceful way.

Thinking about this has lead me to think more about Danny 
Milosavljevic's suggestion
> Yeah, personally I'd like to have an emacs form which just displays config.scm (and stores it as a normal file) and has some inline documentation on what is what and maybe a treeview instead of visible S-Expression parens - and a validation process whether the stuff makes sense. When you exit, it just instantiates the system.
>
> The partitioning & file system type should also be specified in a declarative way in the config [and arguably it already is].
>
> Basically not a lot different from now but just more user-friendly and catching more mistakes before instantiation.
>
> ncurses actually isn't as flexible - although it has the benefit that the average user is familiar with how it looks.
Basically I was thinking of doing that with an ncurses UI that shows the 
user their config.scm with some documentation and then walks users 
through changing each option. But maybe an emacs installer makes more 
sense as this is the type of interface emacs does very well.

The reason I had avoided proposing an emacs installer previously is I 
worry about confusion from users who are unfamiliar with emacs and how 
to use it. Should we be concerned with that when so many of Guix's great 
features that can be accessed through emacs. Perhaps there could be a 
simple introduction to emacs in the installer as well? On the other hand 
if a user has no experience with emacs throwing that at them along with 
config.scm could be overwhelming.

Anyways just some thoughts I had, any more feedback would be greatly 
appreciated.

Thanks
Thomas Ingram

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[myglc2]

Thomas Ingram <taingram@mtu.edu> writes:

> On 03/26/2016 07:39 AM, Ludovic Courtès wrote:
>> Personally, I would like to view the “wizard” as a helper, and not as
>> something that hides everything and turns people into “end users.”

Wow, Ludo, what do you have against "end users"?

>> I don’t know how this could translate in the design of the tool.
>> Perhaps showing the ‘operating-system’ declaration as you suggest is one
>> thing, and making it easy to view the section of the manual that
>> corresponds to a particular item, or to jump to the code that defines a
>> specific service (say), would be helpful too.
> Yes as much as it is an installer it should also be an
> introduction. Something that not only lets a user easily input their
> options but also shows them how their settings will be put into
> config.scm, I'm trying to come up with some clever ideas of how to do
> this in a graceful way.

I disagree about teaching config.scm. When I install Debian all I care
about is:

1) does it let me do what I want?
2) how long does it take?
3) does it leave my machine in a "good" state?

I don't really care how it does it. config.scm is a thing of beauty, but
how important is it really for a GuixSD user to learn? Once GuixSD is
installed, will they ever look at it again? Won't they be using package
management to install the software they want?

A more fundamental issue you need to think about is that the Debian
installer installs packages globally for all users whereas "Guix-style"
is to not address the user-level package needs in config.scm. This means
that a GuixSD installer needs to get the machine up and running on
GuixSD and then come back for a second pass to help the user install
some packages.

> Thinking about this has lead me to think more about Danny
> Milosavljevic's suggestion
>> Yeah, personally I'd like to have an emacs form which just displays
>> config.scm (and stores it as a normal file) and has some inline
>> documentation on what is what and maybe a treeview instead of
>> visible S-Expression parens - and a validation process whether the
>> stuff makes sense. When you exit, it just instantiates the system.
>>
>> The partitioning & file system type should also be specified in a
>> declarative way in the config [and arguably it already is].
>>
>> Basically not a lot different from now but just more user-friendly
>> and catching more mistakes before instantiation.
>>
>> ncurses actually isn't as flexible - although it has the benefit that
>> the average user is familiar with how it looks.
> Basically I was thinking of doing that with an ncurses UI that shows
> the user their config.scm with some documentation and then walks users
> through changing each option. But maybe an emacs installer makes more
> sense as this is the type of interface emacs does very well.

I encourage you to pursue the emacs approach.

> The reason I had avoided proposing an emacs installer previously is I
> worry about confusion from users who are unfamiliar with emacs and how
> to use it.

People are unfamiliar with emacs, but have you used aptitude? No one
started out familiar with aptitude, but it is happily used by Debian
admins (many of which, by the way, hate emacs).

> Should we be concerned with that when so many of Guix's
> great features that can be accessed through emacs.

IMO the Guix emacs interface already exceeds aptitude's, so leverage it
rather than re-inventing any of it.

> Perhaps there could be a simple introduction to emacs in the installer
> as well?

Don't try to teach emacs to the user. And what ever you do, DO NOT tell
them to type C-h!

Instead create a top-level menu that drops them into various guix-
functions to get the job done. An example of this is the notmuch emacs
interface.

Then, make sure each "guix-<function>" you use supports typing "?" to
figure out what the heck is going and and how to get stuff done.

By going this route, you will leverage what is already developed,
enhance the usablity of the Guix emacs interface, and probably end up
with a dynamite installer. - George

> On the
> other hand if a user has no experience with emacs throwing that at
> them along with config.scm could be overwhelming.

Agreed. An IMO not necessary as stated above.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Jookia]

On Sun, Mar 27, 2016 at 02:30:22PM -0400, myglc2 wrote:
> Wow, Ludo, what do you have against "end users"?

I think what Ludovic's getting at is that we'd rather have people know their
tools and experiment, much like Emacs.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[myglc2]

Jookia <166291@gmail.com> writes:

> On Sun, Mar 27, 2016 at 02:30:22PM -0400, myglc2 wrote:
>> Wow, Ludo, what do you have against "end users"?
>
> I think what Ludovic's getting at is that we'd rather have people know their
> tools and experiment, much like Emacs.

OK. But there is a huge community of free software users that suffer
daily from issues that are beautifully addressed by Guix.  Once Guix is
installed and they learn how to select and install software they may not
need, or want, to know anything else.

Don't we want these people to use Guix?

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Leo Famulari]

On Sun, Mar 27, 2016 at 02:30:22PM -0400, myglc2 wrote:
> Thomas Ingram <taingram@mtu.edu> writes:
> 
> > On 03/26/2016 07:39 AM, Ludovic Courtès wrote:
> >> Personally, I would like to view the “wizard” as a helper, and not as
> >> something that hides everything and turns people into “end users.”
> 
> Wow, Ludo, what do you have against "end users"?

Speaking for myself, one thing that I like about Guix and GuixSD are
that they make it relatively easy to learn and alter the system, at
least compared to some other GNU / Linux operating systems.

By encouraging users to learn how to alter their system, they will
unwittingly become computer programmers, which I think is beneficial for
software freedom. I'd prefer that to a world where only 1% of people
have the ability to effect change in software (the current situation).

I understand the situation is not a dichotomy; our system should not be
unnecessarily difficult to use.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Chris Marusich]

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

Leo Famulari <leo@famulari.name> writes:

> On Sun, Mar 27, 2016 at 02:30:22PM -0400, myglc2 wrote:
>> Thomas Ingram <taingram@mtu.edu> writes:
>> 
>> > On 03/26/2016 07:39 AM, Ludovic Courtès wrote:
>> >> Personally, I would like to view the “wizard” as a helper, and not as
>> >> something that hides everything and turns people into “end users.”
>> 
>> Wow, Ludo, what do you have against "end users"?
>
> Speaking for myself, one thing that I like about Guix and GuixSD are
> that they make it relatively easy to learn and alter the system, at
> least compared to some other GNU / Linux operating systems.
>
> By encouraging users to learn how to alter their system, they will
> unwittingly become computer programmers, which I think is beneficial for
> software freedom. I'd prefer that to a world where only 1% of people
> have the ability to effect change in software (the current situation).
>
> I understand the situation is not a dichotomy; our system should not be
> unnecessarily difficult to use.

I couldn't agree more!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Christopher Allan Webber]

myglc2 writes:

> Jookia <166291@gmail.com> writes:
>
>> On Sun, Mar 27, 2016 at 02:30:22PM -0400, myglc2 wrote:
>>> Wow, Ludo, what do you have against "end users"?
>>
>> I think what Ludovic's getting at is that we'd rather have people know their
>> tools and experiment, much like Emacs.
>
> OK. But there is a huge community of free software users that suffer
> daily from issues that are beautifully addressed by Guix.  Once Guix is
> installed and they learn how to select and install software they may not
> need, or want, to know anything else.
>
> Don't we want these people to use Guix?

I don't think it has to be one or the other.

I've been greatly inspired by how Blender has turned artists into
programmers.  You have all sorts of buttons and an interface that's
optimized around artists, but if you hover over a button, the tooltip
displays not only a textual description, but also what the python
equivalent would be.  Thus you have an interface that exposes the
underlying machinery to users who want to use it.

 - Chris

I guess the downside to the Blender comparison is I'm not sure it's the
easiest software to learn, but I think that's a domain issue (3d
graphics, no matter what software you use, are a tough subject to
learn).

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Ludovic Courtès]

Thomas Ingram <taingram@mtu.edu> skribis:

> On 03/26/2016 07:39 AM, Ludovic Courtès wrote:
>> Personally, I would like to view the “wizard” as a helper, and not as
>> something that hides everything and turns people into “end users.”
>>
>> I don’t know how this could translate in the design of the tool.
>> Perhaps showing the ‘operating-system’ declaration as you suggest is one
>> thing, and making it easy to view the section of the manual that
>> corresponds to a particular item, or to jump to the code that defines a
>> specific service (say), would be helpful too.
> Yes as much as it is an installer it should also be an
> introduction. Something that not only lets a user easily input their
> options but also shows them how their settings will be put into
> config.scm, I'm trying to come up with some clever ideas of how to do
> this in a graceful way.

Awesome.

> Basically I was thinking of doing that with an ncurses UI that shows
> the user their config.scm with some documentation and then walks users
> through changing each option. But maybe an emacs installer makes more
> sense as this is the type of interface emacs does very well.
>
> The reason I had avoided proposing an emacs installer previously is I
> worry about confusion from users who are unfamiliar with emacs and how
> to use it. Should we be concerned with that when so many of Guix's
> great features that can be accessed through emacs. Perhaps there could
> be a simple introduction to emacs in the installer as well? On the
> other hand if a user has no experience with emacs throwing that at
> them along with config.scm could be overwhelming.

I understand your concern.

I think that in this case, Emacs should be viewed as a UI toolkit: just
like someone using an ncurses program doesn’t have to learn the ncurses
API, someone using an Emacs-based UI doesn’t have to learn Emacs.

It just happens that Emacs is a full-featured UI toolkit, especially
when it comes to Guix things.  For instance, it already has all we need
to display and navigate source code (from an ‘operating-system’
configuration, one can contextual documentation, jump to
procedure/variable definitions, etc.), to navigate packages, and so on.

Having said that, I think that if you’re more comfortable writing Guile
and ncurses code than Emacs code for this project, then that’s perfectly
fine, of course.

Thanks,
Ludo’.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Ludovic Courtès]

myglc2 <myglc2@gmail.com> skribis:

> Thomas Ingram <taingram@mtu.edu> writes:
>
>> On 03/26/2016 07:39 AM, Ludovic Courtès wrote:
>>> Personally, I would like to view the “wizard” as a helper, and not as
>>> something that hides everything and turns people into “end users.”
>
> Wow, Ludo, what do you have against "end users"?

I think that for people to enjoy their computing freedom, they must be
empowered rather than treated as “end users.”

I believe that the scheme under which experienced programmers write
intricate C/C++ code providing super-high-level wizards for “end users”
does not contribute to the emancipation of individuals.  When that code
is free, of course it benefits programmers (and so, indirectly, “end
users”) and allows society to have collective control over it.  But it
still leaves too high a barrier for many individuals to get into
programming and exert Freedom #1.

Now, I’m not saying that Guix{,SD} or Emacs are trivial for anyone to
hack on either, but I think their design where everything is exposed in
a unified way lowers the barrier to hacking.

I think a number of people here started contributing packages without
knowing Scheme, because they didn’t have to, and eventually became
almost fluent in Scheme as they hacked on it.  :-)

There was a talk last year by Mako on this topic:

  https://mako.cc/copyrighteous/access-without-empowerment-libreplanet-2015-keynote

I hope this clarifies things!

Ludo’.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Ludovic Courtès]

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> I've been greatly inspired by how Blender has turned artists into
> programmers.  You have all sorts of buttons and an interface that's
> optimized around artists, but if you hover over a button, the tooltip
> displays not only a textual description, but also what the python
> equivalent would be.  Thus you have an interface that exposes the
> underlying machinery to users who want to use it.

That’s a very good example.

Ludo’.

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[myglc2]

ludo@gnu.org (Ludovic Courtès) writes:

> myglc2 <myglc2@gmail.com> skribis:
>
>> Thomas Ingram <taingram@mtu.edu> writes:
>>
>>> On 03/26/2016 07:39 AM, Ludovic Courtès wrote:
>>>> Personally, I would like to view the “wizard” as a helper, and not as
>>>> something that hides everything and turns people into “end users.”
>>
>> Wow, Ludo, what do you have against "end users"?
>
> I think that for people to enjoy their computing freedom, they must be
> empowered rather than treated as “end users.”

OK, how about this thought experiment:

Let's say you are making software that empowers users to do anything
they like. You also have the choice between a "user friendly" interface
design and a "hacker friendly" design. The overall functionally is the
same in both versions.

Lets say the "user friendly" version structures the interface to provide
bite-sized entry points so that novices can easily start using it.  The
"hacker friendly" version has a more complex user interface that hackers
like better.

Now, if 100,000 people will adopt the "user friendly" version, and
10,0000 users will adopt the "hacker friendly" version, which will
empower more people?  Which version would you want to build?

This is why user interface decisions are so important. It is why, in a
traditional software company, such big battles are fought between the
marketing and engineering departments over usability.

[...]

> Now, I’m not saying that Guix{,SD} or Emacs are trivial for anyone to
> hack on either, but I think their design where everything is exposed in
> a unified way lowers the barrier to hacking.

Yes Guix is brilliant for hacking. That's why I have blown the last
three months playing with it ;-)

But I assure you, Guix complexity will be off-putting to non-hackers,
just as emacs is. Guix was off-putting to me, and I use emacs 24x7.

So, IMO, if you do nothing, your user base will be largely limited to
Guix hackers. Is this what you want?

[...]
>
> There was a talk last year by Mako on this topic:
>
>   https://mako.cc/copyrighteous/access-without-empowerment-libreplanet-2015-keynote

Watched this talk. The primary measure of success Mako cites is the
number of users. Whether we like it or not, at the end of the day, this
is the most important metric to most people. It drives credibility,
resources, and acceptance.

There is no doubt in my mind that the number of Guix users will be
dramatically enhanced by making Guix easier for a novice to understand
and use.

You are entering the stage of the process where interface and
documentation decisions will be set in stone and these will have a
strong effect on downstream Guix adoption.

IMO, if you do nothing you will emerge with a hacker-friendly solution
with self limiting adoption. That is why I think you should turn your
focus toward usability and actively make compromises toward novice
users.

- George