kojq / gal Goto Github PK

We can do a selection menu. It should be lean in selection and have an efficient layout for mass deployment.

While we could have an optional configuration file, it is a bad practice for this project because information such as credentials and location data are more accessible (regardless of if the harm is statistically negligible). Even a partial configuration file consisting of only technical choices would be obsolete due to having more for all parties to manage. A configuration file would be desirable for tuning hefty amounts of technical choices. At that point, this project would become an interactive install guide, and that is not the goal. Thus, it's best to not have a configuration file for security, privacy, safety, and development. Instead, an interactive selection menu can be provided.

Cases of undesirable information gain:

1. Someone can access the variables
2. Someone can access it when the environment variables are displayed in plain text

• systemd timer for /home
• pacman hook for /root
• 8 entries max (corresponding to a day of the week)
• Works on limited disk space

Remove NVIDIA proprietary drivers in favor of NVK once NVK is stable.

Check in 1 to 2 weeks at a minimum and within several weeks at a maximum to determine whether the distrobox package has moved from the AUR to community to reflect the change here.

This allows the install to already have network information. We will probably use nmcli in chroot.

Why is this baseline configuration ideal for ALL desktop users for long-term use?

• Eliminate desktop environment bias through stability and feature criteria
• Eliminate use of popular dated packages such as sudo, mkinitcpio, and coreutils
• Evaluate and rate each package's reliability

Does every decision have a clear intention that positively influences the end goal?

• Rewrite to incorporate archinstall or its components
• Detect hardware for components such as firmware and drivers
• Implement automatic btrfs snapshots with advanced universal configuration

Is it very easy to use?

• Maximize elimination of race conditions
• Catch and guarantee automatic fixes for internal, external, and upstream failures without user input
  • Examples: hardware failure, Secure Boot (Microsoft keys desired?), package installation errors

Do some nuanced features work as expected?

This will likely be chaotic due to too many factors. Consequently, postpone implementation unless a solution is certain to be canonical.

• Ensure hotspot functions (to and from the device)
• Ensure IME functions
• Ensure NTFS partitions can be mounted with the ability to read and write
• Ensure notification icons exist

Consider POSIX sh and following other standards.

The reason the script does not always follow standards is for easier script maintenance while maintaining other best practices.

The script is only intended to work on the official Arch Linux ISO, so we don't need to worry about reproducibility.

Ensure upstream's signing for the repository.

when booster supports.

For 6.7 kernel:

• Compare bcachefs with btrfs

• Use NVK

Use /efi as the mount point with mkinitcpio on a test branch for helpful error messages.

Then, replace it with booster.

This will be on hold until upstream (systemd and booster) makes it easier to use /efi as the mount point.

sudoedit
pkgexec su doas
mpv vlc xine-ui kodi tvtime xjadeo gst-plugins-base-libs gstreamer ffmpeg