- Update download URLs
- Replace "USB stick"/"USB Drive" with "USB flash drive" as that seem more correct
https://en.wikipedia.org/wiki/USB_flash_drivehttps://elementary.io/docs/installation#choose-operating-system
- Don't mention CD as easiest option anymore,
as all modern systems should be able to boot from USB,
but many don't have a CD drive. Burning CDs is also usually wasteful as you
can't burn them again.
- Remove link to NixOS Wiki (Making_the_installation_media) as it is not needed
- Add Etcher and USBImager as graphical tools to create install drive
- Make dd command consistent and use block size of 4 MB for faster flashing
- More consistent text
- Add instructions for "Booting from the install medium"
Inspired by 9a91b0f495/docs/installation.md (booting-from-the-install-drive-booting-from-the-installation-medium-clear-float-2)
- Add instructions for "Graphical Installation"
- Restructure headings and anchors for "Manual Installation"
- Adding legacy anchors for "Manual Installation" to not break links
Co-authored-by: j-k <dev@j-k.io>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Co-authored-by: Robert Schütz <github@dotlambda.de>
Co-authored-by: Jörg Thalheim <Mic92@users.noreply.github.com>
Co-authored-by: Thiago Kenji Okada <thiagokokada@gmail.com>
This will add `passthru.schema_version` to be used as default value for
the adguardhome module.
It will also update the `update.sh` to keep the `schema_version` in sync
with the version by inspecting the sourcecode.
This might break existing configs, if they use deprecated values that don't
appear in newer schema_versions and schema_version wasn't set explicitly.
Explicit declarations of schema_version always have higher priority.
This also removes the `host` and `config` settings in favour of using the
appropriate `settings`.
Fixes#173938
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
- Previously PolyMC's removal was counted as a release highlight
- It probably shouldn't be, as it's more a notable change rather than a
highlight
- Thanks @Ma27 for noticing this
This commit refactors `services.grafana.provision.datasources` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
This commit refactors `services.grafana.provision.dashboards` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
- Previously PolyMC was the suggested replacement for MultiMC
- As PolyMC is marked as insecure and prismlauncher is a replacement,
this commit suggests using it instead
The actual p4 command is open-source software released under the
2-clause BSD license, so we can build it here (for pretty much every
architecture we support!) and include it in the cache.
This change removes the server-side commands from this package, but they
are now available as part of a separate p4d package instead. (The server
package remains unfree.)
As an added bonus, we can also include the libraries and headers for the
C/C++ API, which will allow us to package any software that uses
Perforce as a library in the future.
This binary was provided by the `cosign` package until now but it is in
the process of being removed, see https://github.com/sigstore/cosign/pull/2019
Since it might be removed during the 22.11 cycle we drop it
preventively. This will make possible security backports easier if we
need them.
Deprecate haskell.lib{,.compose}.generateOptparseApplicativeCompletion*
in favor of the newly added
haskell.packages.*.generateOptparseApplicativeCompletions (plural!)
which takes into account whether we are cross-compiling or not. If we
are, generating completions is disabled, since we can't execute software
built for a different platform.
The move is necessary, so we can receive the /same/ stdenv as the
package we are overriding in order to accurately check whether we can
execute produced binaries.
Resolves#174040.
Resolves#49648.
This caused too many downstream projects to break, so we are reverting
this change for now, until further transition fixes are in place.
See discussion in https://github.com/NixOS/nixpkgs/pull/191171
This reverts part of 6762de9a28
Optional functionality of AusweisApp2 requires an UDP port to be opened.
The module allows for convenient configuration and serves as documentation.
See also https://github.com/NixOS/nixpkgs/issues/136269
deprecate literalDocBook by adding a warning (that will not fire yet) to
its uses and other docbook literal strings by adding optional warning
message to mergeJSON.
Because of long standing bugs and stability issues & an
uncollaborative upstream there has been talk on the emacs-devel
mailing list to switch the default toolkit to
Lucid (https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00752.html).
The GTK build also has issues with Xinput2, something that both we and
upstream want to enable by default in Emacs 29.
This situation has prompted me to use both Lucid an no-toolkit (pure X11) Emacs
as a daily driver in recent weeks to evaluate what the
advantages/drawbacks are and I have concluded that, at least for me,
switching the toolkit to Lucid is strictly an upgrade.
It has resulted in better stability (there are far fewer tiny UX
issues that are hard to understand/identify) & a snappier UI.
On top of that the closure size is reduced by ~10%.
In the pure X11 build I noticed some unsharpness around fonts so this
is not a good default choice.
As with everything there is a cost, and that is uglier (I think most
would agree but of course this is subjective) menu bars for
those that use them and no GTK scroll bars.
For anyone who still wants to use GTK they could of course still
choose to do so via the new `emacs-gtk` attribute but I think this
is a bad default.
A note to Wayland users:
This does not affect Wayland compatibility in any way since that will
already need a PGTK build variant in the future.
- Replace misleading docs.
- Add new assertions to let configurations make more sense.
- Add clusterInit flag.
- Add some more docs about HA and non-HA modes setup.
- Improve multi-node tests for HA mode.
Fix https://github.com/NixOS/nixpkgs/issues/182085
