1
0
mirror of https://github.com/systemd/systemd.git synced 2024-12-22 17:35:35 +03:00

tree-wise: use "lightweight" spelling

Both spellings were used, but the dictionary says that "lightweight"
is the standard spelling.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2024-10-15 18:54:28 +02:00
parent 9b1a5bc365
commit 487d412327
7 changed files with 10 additions and 10 deletions

6
NEWS
View File

@ -14075,7 +14075,7 @@ CHANGES WITH 218:
or are not older than the specified time.
* A new, native PPPoE library has been added to sd-network,
systemd's library of light-weight networking protocols. This
systemd's library of lightweight networking protocols. This
library will be used in a future version of networkd to
enable PPPoE communication without an external pppd daemon.
@ -14922,7 +14922,7 @@ CHANGES WITH 214:
have been added. When enabled, they will make the user data
(such as /home) inaccessible or read-only and the system
(such as /usr) read-only, for specific services. This allows
very light-weight per-service sandboxing to avoid
very lightweight per-service sandboxing to avoid
modifications of user data or system files from
services. These two new switches have been enabled for all
of systemd's long-running services, where appropriate.
@ -15631,7 +15631,7 @@ CHANGES WITH 209:
activation files automatically into native systemd .busname
and .service units.
* sd-bus: add a light-weight vtable implementation that allows
* sd-bus: add a lightweight vtable implementation that allows
defining objects on the bus with a simple static const
vtable array of its methods, signals and properties.

View File

@ -80,7 +80,7 @@ _With all vendor-supplied OS resources in a single directory /usr they may be sh
**Myth #4**: The /usr merges only purpose is to look pretty, and has no other benefits
**Fact**: The /usr merge makes sharing the vendor-supplied OS resources between a host and networked clients as well as a host and local light-weight containers easier and atomic. Snapshotting the OS becomes a viable option. The /usr merge also allows making the entire vendor-supplied OS resources read-only for increased security and robustness.
**Fact**: The /usr merge makes sharing the vendor-supplied OS resources between a host and networked clients as well as a host and local lightweight containers easier and atomic. Snapshotting the OS becomes a viable option. The /usr merge also allows making the entire vendor-supplied OS resources read-only for increased security and robustness.
**Myth #5**: Adopting the /usr merge in your distribution means additional work for your distribution's package maintainers

View File

@ -651,7 +651,7 @@ node /org/freedesktop/machine1/machine/rawhide {
<para><varname>Leader</varname> is the PID of the leader process of the machine.</para>
<para><varname>Class</varname> is the class of the machine and is either the string "vm" (for real VMs
based on virtualized hardware) or "container" (for light-weight userspace virtualization sharing the
based on virtualized hardware) or "container" (for lightweight userspace virtualization sharing the
same kernel as the host).</para>
<para><varname>RootDirectory</varname> is the root directory of the container if it is known and

View File

@ -21,7 +21,7 @@
<refnamediv>
<refname>systemd-nspawn</refname>
<refpurpose>Spawn a command or OS in a light-weight container</refpurpose>
<refpurpose>Spawn a command or OS in a lightweight container</refpurpose>
</refnamediv>
<refsynopsisdiv>
@ -43,7 +43,7 @@
<refsect1>
<title>Description</title>
<para><command>systemd-nspawn</command> may be used to run a command or OS in a light-weight namespace
<para><command>systemd-nspawn</command> may be used to run a command or OS in a lightweight namespace
container. In many ways it is similar to <citerefentry
project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry>, but more powerful
since it virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems, and

View File

@ -601,7 +601,7 @@
<command>systemd</command> (and other UIs) as a user-visible label for the unit, so this string
should identify the unit rather than describe it, despite the name. This string also shouldn't just
repeat the unit name. <literal>Apache2 Web Server</literal> is a good example. Bad examples are
<literal>high-performance light-weight HTTP server</literal> (too generic) or
<literal>high-performance lightweight HTTP server</literal> (too generic) or
<literal>Apache2</literal> (meaningless for people who do not know Apache, duplicates the unit
name). <command>systemd</command> may use this string as a noun in status messages (<literal>Starting
<replaceable>description</replaceable>...</literal>, <literal>Started

View File

@ -320,7 +320,7 @@ static int help(void) {
return log_oom();
printf("%1$s [OPTIONS...] [PATH] [ARGUMENTS...]\n\n"
"%5$sSpawn a command or OS in a light-weight container.%6$s\n\n"
"%5$sSpawn a command or OS in a lightweight container.%6$s\n\n"
" -h --help Show this help\n"
" --version Print version string\n"
" -q --quiet Do not show status information\n"

View File

@ -2007,7 +2007,7 @@ static int create_directory_or_subvolume(
if (r == 0)
/* Don't create a subvolume unless the root directory is one, too. We do this under
* the assumption that if the root directory is just a plain directory (i.e. very
* light-weight), we shouldn't try to split it up into subvolumes (i.e. more
* lightweight), we shouldn't try to split it up into subvolumes (i.e. more
* heavy-weight). Thus, chroot() environments and suchlike will get a full brtfs
* subvolume set up below their tree only if they specifically set up a btrfs
* subvolume for the root dir too. */