since last update system does not boot any more

[Richard Ryniker]

Al Dunsmuir <al.dunsmuir at sympatico.ca> wrote on Tue, 12 Apr 2011 12:36:53 -0400:
>I  think  these [file names such as "multi-user.target"] should be
>viewed more as keywords, or reserved phrases
>and not subject to translation.
>
>This is similar to a C program, where one has 3 cases:
>- Comments and literal string can have nearly any value.
>- Variable names are only restricted in the character set that can be
>  used.
>- Language keywords must conform exactly.
>
>Having  them  be  NLS-sensitive  in a global subsystem in a multi-user
>environment  (where  each  user  (or  even  process)  is able to use a
>different locale) seems to me a recipe for disaster.

More like variable names than keywords.  Keywords usually are from a
small, fixed set.  Sometimes they have a prescribed syntax (e.g. a
distinctive character, such as the initial colon that denotes a Common
Lisp keyword) that permits a vast number of keywords.  Systemd targets
are ordinary file names.  They come from no enumerable set; there is no
syntax that identifies a target name.

English users are likely to find the standard target names descriptive.
Other users will find them opaque, and the larger (more flexible) set of
target names will be a challenge compared to single digits from 1-6.

I have had experiences where I sought to understand C programs written by
programmers not fluent in English.  Despite a lot of C program experience
and a good understanding of the C language, this was enormously more
difficult than examination of similar programs written by English-
speaking authors.  This experience suggests the burden of systemd will be
heavier for those not fluent in English.  This is true for many aspects
of Linux that derive from its English roots and development.

I concur with your view it is unwise to undertake some sort of
internationalization of systemd target names.  I believe the flexibility
that systemd provides is valuable, and I do not want to discard systemd.
My point is systemd makes Fedora a little more difficult for a large
number of people.  A little times a large enough number can be a
significant cost, especially if this scenario is repeated with other
features.

It seems possible that we can make a substantial number of sound
decisions that "This feature is well worth the small breakage it costs."
and fail to realize the aggregate cost may not be simply additive, but
grow (for at least some users) beyond the total benefit these choices
deliver.

Fedora, with its leading-edge ambition, is a good vehicle to explore
these issues, though I doubt we spend enough effort in retrospection.
There have been many instances where Fedora replaced a facility with
something new, a smaller number of cases where a feature was deemed "too
broken to fix" and dropped, but few where a feature is successful but is
abandoned because its cost is higher than expected.  Maybe Red Hat Linux
is the place for that, while Fedora chases the new, latest, and greatest.