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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In particular, NixOS has changed somewhat, and Conda is worth
looking at. Also it seems reasonable to mention rpm-ostree /
Gnome Continuous.
Closes: #331
Approved by: cgwalters
1 is a better choice than 0 because some programs use 0
as a special value; for example, GNU Tar warns of an
"implausibly old timestamp" with 0.
Closes: #330
Approved by: cgwalters
A few links in the docs had the Markdown syntax swapped like:
(link title)[link url]
Just cleaned up those. Verified via `mkdocs serve`
Closes: #297
Approved by: cgwalters
Just keeping my promise to write more documentation. There could be a
lot more to write here, but I'm trying to get a start done.
Closes: #222
Approved by: jlebon
I'd like to encourage people to make OSTree-managed systems more
strictly read-only in multiple places. Ideally everywhere is
read-only normally besides `/var/`, `/tmp/`, and `/run`.
`/boot` is a good example of something to make readonly. Particularly
now that there's work on the `admin unlock` verb, we need to protect
the system better against things like `rpm -Uvh kernel.rpm` because
the RPM-packaged kernel won't understand how to do OSTree right.
In order to make this work of course, we *do* need to remount `/boot`
as writable when we're doing an upgrade that changes the kernel
configuration. So the strategy is to detect whether it's read-only,
and if so, temporarily mount read-write, then remount read-only when
the upgrade is done.
We can generalize this in the future to also do `/etc` (and possibly
`/sysroot/ostree/` although that gets tricky).
One detail: In order to detect "is this path a mountpoint" is
nontrivial - I looked at copying the systemd code, but the right place
is to use `libmount` anyways.
This content currently lives here:
<https://wiki.gnome.org/Projects/OSTree/RelatedProjects>. Moving it
into the manual in Markdown:
- Makes it look better
- It's more useful alongside the rest of the docs
- Is much less crummy in general than the GNOME wiki
I was going through the new version of the docs and noticed a few
problems. Mostly URLs that aren't linked, extra whitespace, and a few
mis-spellings.
I ran the files through `aspell check` and made some manual changes
myself.
These changes were tested locally with `mkdocs serve`
I don't much like Docbook (and am considering converting the man pages
too), but let's start with the manual.
I looked at various documentation generators (there are a lot), and
I had a few requirements:
- Markdown
- Packaged in Fedora
- Suitable for upload to a static webserver
`mkdocs` seems to fit the bill.
