IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
https://tools.ietf.org/html/draft-knodel-terminology-02https://lwn.net/Articles/823224/
This gets rid of most but not occasions of these loaded terms:
1. scsi_id and friends are something that is supposed to be removed from
our tree (see #7594)
2. The test suite defines an API used by the ubuntu CI. We can remove
this too later, but this needs to be done in sync with the ubuntu CI.
3. In some cases the terms are part of APIs we call or where we expose
concepts the kernel names the way it names them. (In particular all
remaining uses of the word "slave" in our codebase are like this,
it's used by the POSIX PTY layer, by the network subsystem, the mount
API and the block device subsystem). Getting rid of the term in these
contexts would mean doing some major fixes of the kernel ABI first.
Regarding the replacements: when whitelist/blacklist is used as noun we
replace with with allow list/deny list, and when used as verb with
allow-list/deny-list.
In order to allow applications to detect the host OS version or other
metadata, ask container managers to expose the os-release files as
read-only bind mounts.
For systemd-nspawn, we will also expose ID, BUILD_ID, VERSION_ID and
VARIANT_ID as lowercase environment variables prefixed by the
container_host_ string.
One problem found with the current draft specification is we can't have
an application provide a non-transient systemd service file in a way
that is spec compliant as the service name currently needs to end in a
random token defined by the launcher.
This came up when trying to put DBus activated services into the correct
cgroup. There isn't enough metadata in the DBus service file to know the
correct application ID, and the most intuitive fix is for those
applications to just specify the SystemdService file in the existing
system. They're generally unique for a given user session anyway so
don't need a separate cgroup identifier.
This changes the spec for RANDOM to be optional for services.
It also changes the separator between in services to act like templates.
Ultimately that's what we're trying to recreate with the RANDOM token of
the systemd service and it's a better fit. It's needed as otherwise with
launcher and the random ident being both optional it would be impossible
to get the application ID reliably.
Scopes are unchanged as they don't support templates.
The old version of this command will delete everything under the new home directory (including `.identity`), rendering the directory unusable with homed.
We need both a slice name and a prefix for application units. For
consistency we tried to use the same name and ended up standardising on
"apps.slice" and and "apps-" prefix for the units.
However, "app-" would be a more natural prefix for applications. And it
is no problem to simply also name the slice "app.slice" for consistency
rather than keeping the current "apps.slice".
It's not that I think that "hostname" is vastly superior to "host name". Quite
the opposite — the difference is small, and in some context the two-word version
does fit better. But in the tree, there are ~200 occurrences of the first, and
>1600 of the other, and consistent spelling is more important than any particular
spelling choice.
This is work in progress and not finished yet. However, I hope to have
captured some of the key points that came up in previous discussions
with appropriate notes about things that still need to be defined.
I may revisit it later. Also, feel free to completely rewrite if the
format is not quite right.
I assume it’s supposed to be “see Home Directories for details” and not
“… and embeds these JSON records directly in the home directory images …
for details”, but the previous text suggested the latter reading to me.
According to the designer of the page layout a page only should have one
h1 header, and everything else should be h2, h3, … I think that makes a
ton of sense, hence let's downgrade some headers here.
This way we can use libxcrypt specific functionality such as
crypt_gensalt() and thus take benefit of the newer algorithms libxcrypt
implements. (Also adds support for a new env var $SYSTEMD_CRYPT_PREFIX
which may be used to select the hash algorithm to use for libxcrypt.)
Also, let's move the weird crypt.h inclusion into libcrypt.h so that
there's a single place for it.
I think it makes sense to keep the "The" in place for the actual page's
title, but let's drop it from the categorization header, to make it
easier to find stuff, as the "The" isn't helpful to that.
In particular as we sometimes do it this and sometimes the other way so
far, hence let's stick to one common rule.
In the wiki, this was a separate page. I don't think this split is useful,
since the information about what is stable and what not seems randomly split
between the two pages.
Links are adjusted for our own pages. Some external links to gentoo and other
projects seem to be broken, but it's a chore to fix them.
Instead of saying that patches for portability are not accepted, say that this
is decided case-by-case. This is what happens in practice, and we tend to
discuss each patch on its own merits.
Some sentences are reworded a bit where they sound awkward.
The only non-stylistic change is to replace descriptions of how we are
encouraging people to use PrivateTmp= and such, because now they are widely
used.
