[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Videos

From: Thorsten Wilms
Subject: Re: Videos
Date: Tue, 19 Jun 2018 11:32:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 18.06.2018 22:47, Ricardo Wurmus wrote:
What are good first topics that we could introduced in self-contained
videos?  The goal is to show a useful feature (one or two closely
related features per video) without making things confusing.

We don’t need to start with this abstract topic.  Maybe
it’s better to show features first.

If the videos are supposed to not only be of help to those who already decided to give Guix a spin, but also to encourage others to do so, they should perhaps be scenario [/ use case / problem / story] based.

With a flow like this:
-> the What of a set of helpful features
-> the How

As starting point, we may assume the viewer isn't even aware of issues with package management ala .deb. Even worse, if they are more accustomed to Windows, OSX, IOS, Android, they might not even see the advantages of typical Linux package management.

However, the comparison to other systems comes with the risks of becoming long-winded and to appear to disparage the efforts of others.

Topics should likely start on a per-package level, then move to the system level. Likewise from user to developer.

If a user doesn't already know which piece of software they are interested in, there's a step even before installation ... let's call it discovery. Seems all that could be mentioned here is `guix package -s term`. I just tried to come up with a nice example, but even knowingly aiming at Inkscape, `guix package -s svg` or `... "vector graphics"` speaks more of a problem than a solution. If only one could filter for library / cli tool / graphical application.

With protagonist P and software S:

    P wants to accomplish Thing and looks for matching Free Software.
    P wants to use S and thus installs it, without worrying about any
    dependencies. P may lack root privileges. Not even a power outage
    can faze P.
  Updates and rollbacks
    P updates S, then finds out something about S doesn't work as
    desired anymore. P rolls S back to the previous version without
    skipping a beat
    P doesn't use S anymore. P removes S and it is as if it was never

  Global updates and rollback
    P likes to keep all the software up-to-date and secure. P doesn't
    have to do much to accomplish this. If P tinkers with system
    configuration and ends up with its currents state broken, a rollback
    is not far.
  Garbage collection
    Rollback are nice, a full HD isn't ...
  Multiple versions side by side
    S1 needs library L version 1.2, S2 needs L at 2.1. No sweat!
  Duplication/Migration (system configuration and manifest)
    P bought a new computer. Getting it ready won't take long ...

  Watertight handling of dependencies
  Inheriting and modifying packages

Thorsten Wilms

thorwil's design for free software:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]