[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 19 Jun 2018 11:32:01 +0200
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.
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
thorwil's design for free software: