01/01: services.txt: Em dashes, not en dashes.

[Ludovic Court�s]

civodul pushed a commit to branch master
in repository maintenance.

commit 0e5f0c281efc559e2175476e0b960c6036f76638
Author: Ludovic Courtès <address@hidden>
Date:   Thu Nov 19 14:04:50 2015 +0100

    services.txt: Em dashes, not en dashes.
---
 doc/announcements/savannah/services.txt |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/announcements/savannah/services.txt 
b/doc/announcements/savannah/services.txt
index e4f1bcf..4bca129 100644
--- a/doc/announcements/savannah/services.txt
+++ b/doc/announcements/savannah/services.txt
@@ -6,7 +6,7 @@ GuixSD provides a declarative, stateless approach to operating 
system configurat
 
 GuixSD is not like your parents’ distro.  Instead of fiddling with 
configuration files all around, or running commands that do so as a side 
effect, the system administrator _declares_ what the system will be like.  This 
takes the form of an 
[https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html
 operating-system declaration], which specifies all the details: file systems, 
user accounts, locale, timezone, system services, etc.
 
-If you’re familiar with it, this may remind you of what deployment tools like 
Ansible and Puppet provide.  There is an important difference though: GuixSD 
takes a stateless–or “purely functional”–approach.  This means that 
instantiating the system with 
[https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html 
guix system] always produces the same result, without modifying the current 
system state.  This is what makes it possible to test new system 
configurations, roll [...]
+If you’re familiar with it, this may remind you of what deployment tools like 
Ansible and Puppet provide.  There is an important difference though: GuixSD 
takes a stateless—or “purely functional”—approach.  This means that 
instantiating the system with 
[https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html 
guix system] always produces the same result, without modifying the current 
system state.  This is what makes it possible to test new system 
configurations, roll [...]
 
 In GuixSD, operating-system declarations are first-class objects in the 
[https://www.gnu.org/software/guile/ host language].  They can be inspected at 
the REPL:
 
@@ -27,7 +27,7 @@ It is also possible to write functions that take or return OS 
configurations.  F
 
 System services are specified in the services field of operating-system 
declarations, which is a list of service objects.  As a user, we want to be 
able to ideally add one line specifying the 
[https://www.gnu.org/software/guix/manual/html_node/Services.html system 
service] we want to add, possibly with several instances of a service, and have 
GuixSD do the right thing.
 
-Before 0.9.0, GuixSD had a narrow definition of what a “system service” is.  
Each service in the operating-system configuration had to map to exactly one 
dmd service–[https://www.gnu.org/software/dmd GNU dmd] is the init system of 
GuixSD.  This would work well in many cases: an SSH server or a log-in daemon 
is indeed a service that dmd has to take care of, even a file system mount is 
an operation that can be usefully inserted into dmd’s service dependency graph.
+Before 0.9.0, GuixSD had a narrow definition of what a “system service” is.  
Each service in the operating-system configuration had to map to exactly one 
dmd service—[https://www.gnu.org/software/dmd GNU dmd] is the init system of 
GuixSD.  This would work well in many cases: an SSH server or a log-in daemon 
is indeed a service that dmd has to take care of, even a file system mount is 
an operation that can be usefully inserted into dmd’s service dependency graph.
 
 However, this simple mapping failed to capture more complex service 
composition patterns.  A striking example is “super-daemons”—daemons that can 
spawn other daemons, such as dbus-daemon or inetd.  From the user viewpoint, it 
does not matter whether a daemon is started by dmd, or by dbus-daemon, or by 
inetd; this should be transparent.  If it’s a D-Bus service, then dbus-daemon’s 
configuration file should be told about the service; if it’s an inetd service, 
then inetd.conf should be augm [...]