I'll get straight to the point.
When I started Pop!_Planet, I launched it because I saw a need for a centralized community for Pop!_OS. To be frank, I never expected the level of popularity it has achieved. Over the last year, we have gone from under 50 users, to almost 400 users. That's awesome! However... it also comes with a downside. We are rapidly running out of disk space on our server, and the bandwidth costs go up every month.
Pop!_Planet is not affiliated with System76 in any way, and is funded completely out of pocket. From day one, I said that I'd never use on-site ads (I hate them as much as you do), so the only monetization we get is through donations. Right now, the donations we receive don't even cover our overhead.
I know that most users will ignore this message, and that's ok. However, if even a few of our users are willing and able to donate a few dollars to help offset our expenses, it would be greatly appreciated.
Thank you for your time,
Because the vast majority of Pop!_Planet contains indications that may need clarification for users new to Pop!_OS (or GNU/Linux in general), this rundown of basic procedures was written both to avoid confusion in the assimilation of the articles and to deter repetition in the content itself.
Most articles on the Pop!_Planet do not attempt to provide a holistic introduction to a single topic; they are instead written in adherence to the DRY principle, under the assumption that the user will seek out and read any supporting material that they do not yet understand. Where possible, such supporting material is indicated in the article via special formatting, see #Formatting.
Because of this organization, it may be necessary to examine several related sources in order to fully understand a Pop!_Planet article. In particular, users who are new to Pop!_OS (or GNU/Linux in general) should expect to end up reading a great number of articles even when solving simple problems. It is especially important to study the supporting material before seeking additional help from other users.
Some lines are written like so:
# mkinitcpio -p linux
Others have a different prefix:
$ makepkg -s
The numeral or hash sign (
#) indicates that the command needs to be run as root, whereas the dollar sign (
$) shows that the command should be run as a regular user.
#are intended to be executed from a root shell, which can for example be easily accessed with
sudo -i. Running
sudo commandfrom an unprivileged shell instead of
commandfrom a root shell will also work in most cases, with some notable exceptions such as redirection and command substitution, which strictly require a root shell. See also sudo.
A notable exception to watch out for:
# This alias makes ls colorize the listing alias ls='ls --color=auto'
In this example, the context surrounding the numeral sign communicates that this is not to be run as a command; it should be edited into a file instead. So in this case, the numeral sign denotes a comment. A comment can be explanatory text that will not be interpreted by the associated program. Bash scripts denotation for comments happens to coincide with the root PS1.
After further examination, "give away" signs include the uppercase character following the
# sign. Usually, Unix commands are not written this way and most of the time they are short abbreviations instead of full-blown English words (e.g., Copy becomes cp).
Regardless, most articles make this easy to discern by notifying the reader:
# This alias makes ls colorize the listing alias ls='ls --color=auto
When prompted to append to, add to, create, or edit one or more files, it is implied that you should use one of the following methods.
# nano /etc/bash.bashrc
To create or overwrite a file from a string it may be simpler to use output redirection. The following example creates or overwrites the contents of the file
/etc/hostname with the text
# echo myhostname > /etc/hostname
Output redirection can also be used to append a string to a file. The following example appends the text
deb http://my.repo.org/ubuntu/ bionic main to the file
# echo "deb http://my.repo.org/ubuntu/ bionic main" >> /etc/apt/sources.list
# mkdir /mnt/boot
After creating a file, if it is meant to be run as a script (whether manually or called by another program) it needs to be set as executable, for example with:
$ chmod +x script
Some applications, notably command-line shells, use scripts for their configuration: after modifying them, they must be sourced in order for the changes to be applied. In the case of bash, for example, this is done by running (you can also replace
$ source ~/.bashrc
When the wiki will suggest to modify such a configuration script, it will not explicitly remind you to source the file, and only in some cases it will point you to this section with a reminder link.
When an article invites to install some packages in the conventional way, it will not indicate the detailed instructions to do so, instead it will simply mention the names of the packages to be installed.
The subsections below give an overview of the generic installation procedures depending on the package type.
For packages from the official repositories you will read something like:
This means that you have to run:
# apt install foobar
The apt article contains detailed explanations to deal with package management in Pop!_OS proficiently.
When an article invites to start, enable, stop or restart some systemd units (e.g. a service), it will not indicate the detailed instructions to do so, but instead you will read something like:
This means that you have to run:
# systemctl start example.service
It is important to remember that there are two different kinds of configurations on a GNU/Linux system. System-wide configuration affects all users. Since system-wide settings are generally located in the
/etc directory, root privileges are required in order to alter them. For example, to apply a Bash setting that affects all users,
/etc/bash.bashrc should be modified.
User-specific configuration affects only a single user. Dotfiles are used for user-specific configuration. For example, the file
~/.bashrc is the user-specific configuration file. The idea is that each user can define their own settings, such as aliases, functions and other interactive features like the prompt, without affecting other users' preferences.
$HOMEare shortcuts for the user's home directory, usually
Bash and other Bourne-compatible shells, such as Zsh, also source files depending on whether the shell is a login shell or an interactive shell. See Bash#Configuration files and Zsh#Startup/Shutdown files for details.
Some code blocks may contain so-called pseudo-variables, which, as the name says, are not actual variables used in the code. Instead they are generic placeholders and have to be manually replaced with system-specific configuration items before the code may be run or parsed. Common shells such as bash and zsh provide tab-completion to auto-complete parameters for common commands such as systemctl.
In the articles that comply with Help:Style/Formatting and punctuation, pseudo-variables are formatted in italics. For example:
dhcpcd@interface_name.servicefor the network interface identified from the output of the
In this case
interface_name is used as a pseudo-variable placeholder in a systemd template unit. All systemd template units, identifiable by the
@ sign, require a system-specific configuration item as argument. See Systemd#Using units.
dd if=data_source of=/dev/sdX bs=sector_size count=sector_number seek=partitions_start_sectorcan be run as root to wipe a partition with the specific parameters.
In this case the pseudo-variables are used to describe the parameters that must be substituted for them. Details on how to gather them are elaborated on in the section Securely wipe disk#Calculate blocks to wipe manually, which features the command.
In case of file examples, pasting pseudo-variables in real configuration files might break the programs that use them.
In most cases ellipses (
...) are not part of the actual file content or code output, and instead represent omitted or optional text that is not relevant for the discussed subject.
HOOKS="... encrypt ... filesystems ..." or:
Section "InputClass" ... Option "CircularScrolling" "on" Option "CircScrollTrigger" "0" ... EndSection
Be aware though that, in a few instances, ellipses may be a meaningful part of the code syntax: attentive users will be able to easily recognize these cases by the context.