[NOTE]Unix-like systems are such as Mac OS (some portions) and just about any distro of Linux with bash.

- This guide is a whole list to improve performance, improve security, and fix problems users have when using Linux for anything.

- Please have backups of your storage, installation media onto a USB key or similar, your kernel, your bootloader and their configuration files, and anything important I may have not listed specifically here.

- Make sure you have the root password in case any commands we use here require to run as root. When running commands as root, take caution and be familiar with what they do!

- Do NOT run any of these commands while logged into the `root` user as this is a huge security risk and you could damage your file system from mistakes.

- You also need to be apart of the `wheel` group and allow users in the wheel group to be sudoers. To add yourself to the wheel group, you can add your current user account in by this command: `sudo usermod -G wheel <username>`
If you need to create a user: sudo useradd -m -g users -G wheel -s /bin/bash <username>

(Some distros like Debian will use 'sudo' instead of 'wheel'. The process is the same. Just instead, you add your username and copy the rest above 'root'.)

After creating your user or adding yourself, we need to change the sudoers file in /etc/sudoers.
You can simply edit with nano, but it won't do syntax checks. If you want to edit it with the default editor, just do `sudo visudo`
If you want to edit it using nano: `sudo EDITOR=nano visudo`

Now, find the line that says: #%wheel ALL=(ALL) ALL
Simply uncomment that line and save the file. You may need to relog for the changes to take effect.

- If you are not sure of something, feel free to search up the fix or tweak.

- I will 95% of the time list any warnings about a certain tweak or fix. Please read them carefully. I am not responsible for whatever happens if you don't read or take consideration into these warnings. But I'm assuming since you're using Linux, you're an advanced user so I am hoping you know how to recover from it.

- Not all fixes are for the same distro. If there is a fix or tweak that you want to do but isn't listed for your distro, please look it up and I can ensure that you will find the same or similar tweak for your distro.

- Please consider your distro's respective Wiki's if you're unsure or stuck on something. They're a lifesaver and it's what I used when I had a problem and 99/100 times the instructions helped.

- And most importantly, any scripts should be overlooked carefully in case I provide a place to one. Don't trust every single person you meet. ^~^

- This guide is slightly focused towards Arch and a little of Ubuntu, but I will try my best to consistently update it for other distros. (If you have any tips, tricks, tweaks or anything I should add, PM me!)

I can't stress this enough, you NEED to check your distro for updates and upgrades.

Arch users: `sudo pacman -Syu` (updates repositories and checks for updates)

Ubuntu users: `sudo apt update && sudo apt upgrade && sudo apt dist-upgrade`
(updates repositories, checks for package upgrades, and checks for distro upgrades)

These are pretty huge in CS:S and some of CS:GO.

First off, disable in-game mouse acceleration.
These commands pretty much disable in-game acceleration as well as Windows acceleration, but since we're on Linux, it shouldn't make a difference.

Now, raw input. This command differs for a lot of people. For me, I can't stand using it and I love having it disabled. Pretty much, this command gets your mouse data directly instead of getting it from let's say a driver, Windows, a software, etc and THEN your mouse.

According to some sources, raw input adds some smoothing to your mouse movement which for some players like me, don't like. I can't verify this but it seems like this command is related to the CS:S and 1.6 command `m_filter`. The best I can tell you is to try using it with and then without it and see which suits you better:
`m_rawinput "0" or "1"`

Now, let's set our pitch, yaw side, and forward values to their proper ones.

These are the default and should be left alone. People for some reason say to "change your yaw if you play on stretched" or whatever. Please don't change it. It does not help you at all and usually the people who say this don't even know what mouse events are.

Finally, set your zoom_sensitivity_ratio to "1". This makes scoping in almost the same as your sensitivity. If you want it to be exactly your sensitivity, it's a long list of numbers and I don't see why it matters with you.

If you're playing CS:S or 1.6, these commands should be very similar. Here is one more extra command in case you play on those games as this command was removed in GO:
`m_filter "0"` This removes mouse movement smoothing and filtering.

-Launch options-
These apply for many Source engine and maybe GoldSrc games:
-noforcemparms (Does not allow enforcing of mouse parameters from the system)
-noforcemaccel (Disables enforcing of mouse acceleration, sometimes this works, sometimes it doesn't for different people)
-noforcemspd (Not sure what this does but it's related to the mouse. If you know what it is, be sure to tell me so I can add it here!)
--------------------------------------------------------------------------

If you use GNOME and you have this "sloppy" and mouse focusing window mode effect, this is an issue with GNOME. It's known to cause issues with a variety of games, causing a "click-through" effect as if the game isn't even there. To overcome this issue, you can switch the focus mode to "click" with a tool such as gnome-tweaks (package name) or gnome-tweak-tool (this may be broken.). You can also play in a different desktop environment. Or spawn their game in a separate X-session.

--------------------------------------------------------------------------

In short. Plug in your mice to a USB 2.0 port.

Long explanation; for whatever reason, the majority of mice perform worse when plugged into a USB 3.0 (or 3.1) port. Though, some mice perform the same such as mine. But I would want to plug it into a 2.0 port to save the 3.0 port for a higher-grade device which natively supports it and benefits from it such as a USB drive.
Not sure why this happens but I suggest plugging in your mice into a 2.0 port.

This is a little weird when it comes to keyboards. With keyboards, there is no difference when it comes to different ports, except for PS/2 keyboards. PS/2 keyboards support N-key rollover so you can press however many keys at once and it wouldn't be limited by the CPU or hardware. USB Keyboards, on the other hand, they're hardware limited when it comes to key rollover. Some say plugging it into a 3.0 or 3.1 port allows you to press more at once, I'm not sure but I have no difference in 2.0, 3.0 and 3.1 ports except for PS/2. If you have a cheap keyboard that won't let you press many keys at once (like me), buy a USB to PS/2 adapter and plug it into your motherboard. If you don't and can press many keys, just stick to 2.0 USB.

Since PS/2 is very old and legacy, why do we still have it? It's for debugging purposes when your USB ports don't work while generic drivers work just fine and well with PS/2 devices. This can get pretty complicated and legacy so I'm not going to continue this c:

--------------------------------------------------------------------------

Your mouse is limited to a certain polling rate. Most mice are 500hz and 1000hz which are both good for gaming as there is no real difference between 500 and 1000hz.
If you still need that extra millisecond, you can overclock it to 1000hz but I genuinely don't see why you would need to as there's just a two ms delay with 500hz.

As this method is not recommended since you may potentially brick your motherboard (super rare), fry your USB port, or fry the device.
I'm going to leave this up to you to figure out as I don't condone this as from my personal experience, was not good.

But the best I can tell you is to get a new mouse if you don't have a default hardware polling rate of 500 or 1000hz.

--------------------------------------------------------------------------

As always, these can be found in your wikis.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
For applications/games that use OpenAL (CSGO is an example), if you use headphones, you can get better positional audio using OpenAL's new HRTF filters. To enable, it's pretty simple:
Run this command: `echo "hrtf = true" >> ~/.alsoftrc`
This adds "hrtf = true" in OpenAL's config.

An alternative is to install the package `openal-hrtf` (Arch users, this is found in the AUR) and edit the options found in `/etc/openal/alsoftrc.conf`

For Source engine games, you must set `dsp_slow_cpu` to "1" in order to use OpenAL's HRTF feature. In CSGO, this command is cheat protected and already features an HRTF feature which can be enabled in Audio Settings of the game so this is not required. In other games which don't feature a built-in HRTF setting or command, you must set that command to "1". You will also most likely need to set up Steam to use their native runtime, or link its copy of openal.so to your own local copy. To complete this all, also use these commands:

--------------------------------------------------------------------------
--------------------------------------------------------------------------
Assuming most users use PulseAudio, you can tweak some default settings in their respective configs to make it run optimally.

PulseAudio is built to be run as a daemon with real-time priority. However, because of the security risks of it locking up your system, it is scheduled as a regular thread by default. To adjust this, first, make sure your user account has the `audio` group and you are logged into the user account with it. Next, uncomment and edit the following lines in `/etc/pulse/daemon.conf`:
And restart PulseAudio.

If you're fine with a small CPU usage increment and assuming your audio card can handle it, you can change the default resample method PulseAudio sets.
By default, PA on Arch at least and maybe other distros, use speex-float-0 to remix channels. This is considered `medium-low` quality remixing. Again, if your system can handle it which it normally should, you could benefit from it by setting it to `speex-float-10` in `/etc/pulse/daemon.conf`:

And then restart PA.

--------------------------------------------------------------------------
--------------------------------------------------------------------------
If you experience/notice stuttering and audio interruptions (small hiccups of no audio), it may be an issue with PA.

If you have a low-power machine, you can try adding/changing this to your `/etc/pulse/daemon.conf`:
Then restart PulseAudio server.

--------------------------------------------------------------------------
--------------------------------------------------------------------------

Try using the "glitch-free" or the system-timer based model.
If you have a creative sound card or professional sound card or just simply have issues with audio distortion and CPU usage, try using the old timer that was better.
Add this line or uncomment it:

First off, make sure you properly read your distro's wiki about installing Steam and Steam games.
If the Steam client or game is not starting and/or you have an error message about a library, check if you have Steam runtime and Steam native. Try running both and take a look at the error message that comes up.
If it's about missing libraries, usually it's because you didn't enable multi-lib and it couldn't install the i386 libraries. To fix this differs from your distro but for the most part, it's one command:

Arch Linux users; go into /etc/pacman.conf as root and find these two commented lines:
If they aren't commented or they aren't in the config file, simply uncomment them or add those two lines and uncomment them. Then run `sudo pacman -Syu` to update your repositories and check for system updates.

Ubuntu users and others similar, this is pretty easy.
Simply run the command as root: `sudo dpkg --add-architecture i386`
Or if you're running i386 and you need amd64: `sudo dpkg --add-architecture amd64`
Then update APT and your system: `sudo apt-get update && sudo apt-get upgrade`

Then simply reinstall Steam.

Arch Linux users, I strongly suggest you install Steam from the repositories. If pacman doesn't have it, install an AUR helper and simply install the package `steam` and it should do the rest for you.

Somewhat similar with Ubuntu (haven't used Ubuntu for a long time), but if installing it from a repository doesn't work, try manually installing it from the official Steam website.

--------------------------------------------------------------------------

If you experience a slow download speed through Steam client, but browsing websites and Steam store, and streaming videos, etc are unaffected from a slow speed, you should install a DNS cache program like dnsmasq.

To install dnsmasq, simply download and install the package however way you want.
Next, enable and start the daemon service.
Arch users:
It should work immediately from there.
If you use DHCP, you need to restart your computer or the network so the DHCP client can create a new resolv.conf.

I also suggest you configure it so it will work better.
First, get your network interface name.
The command for Ubuntu users is `ifconfig` (should be).
Arch users, `ifconfig` works but you may need to download a package to use it. Or you can simply do `ip addr` and it will do the same.
For example my interfaces are enp3s0 (my ethernet card) and `lo` (loopback interface). Yes, if you have any loopback interfaces, get those too. Traditionally, they'll be named simply `lo`.

Go into the config (/etc/dnsmasq.conf) as root and we'll tweak it a little.

`cache-size`. Find this and set it to a higher value than 150. I set mine to 1440, but 1000 works too.

If you host a web server and have a domain configured for it, enable it at the following lines that are similar. (Some lines look similar, find the one that looks like this!)
For example I set the domain to `catcomp.cf` as that's my domain and my web server.
This isn't required, but it helps if you host a web server and own a domain.

Now find the line that says `interface=`. This is where your interfaces come in. Here's an example of my config:
As you can see, I added the loopback interface and my ethernet interface. If you have more than one, add another line of the same shown above similar.
[WARNING/NOTE] Adding your interfaces here opens up ports TCP/UDP 53 and UDP 67 to the WAN. Just a heads up in case you don't like ports being opened.

Now find `bind-interfaces`. Go ahead and uncomment this. Don't add anything. Just uncomment it.

Then you can go ahead and write that config.
To test your config for errors, type in your terminal `dnsmasq --test`
If everything is good, it will tell you.
Then you can go ahead and restart dnsmasq. (sudo systemctl restart dnsmasq.service)

To test your lookup speed, choose a website that you have not visited SINCE dnsmasq has been started. For example, reddit.com.
Type this command along with the website you choose:
For me, Reddit took 58 ms to lookup.

Now, type the same exact command in and compare the timings.
Now Reddit took 18 ms to lookup.

This all seems complicated, but you should notice it in Steam.

If drill comes out as an unknown command, install the package: `ldns`.
--------------------------------------------------------------------------
This is a pretty simple error to fix as you'll most likely notice it before you even install Steam.
This is an issue with name resolving. The easiest way to fix it is to install the package `nss-mdns`.
Also, check your hostname file (/etc/hostname) and hosts file (/etc/hosts) and make sure they're properly configured. An incorrect hosts file is usually the main cause for this issue and can be easily fixed by changing up a few things.
--------------------------------------------------------------------------
Reinstall (or install) the package `steam-fonts` or manually downloading https://support.steampowered.com/downloads/1974-YFKL-4947/SteamFonts.zip directly from Steam.
Also, be sure to install your Arial fonts as Steam relies on these and if they can't find them, it falls back into a bitmap font named Helveticia and Steam doesn't render this and potentially other bitmap-based fonts correctly.

After doing this, check if you have Arial fonts by this command (assuming you're using font-config):
`fc-match -v Arial`

If Arial fonts exist and Steam still doesn't render fonts properly, try rebooting. If problem persists, try flushing font cache:
Arch users can simply do `fc-cache` (might require root) and maybe other distros can do the same.
Here's the last solution I have for you: disable bitmap fonts:
Create a new file located at: `~/.config/fontconfig/conf.d/20-no-embedd.conf`
In there, copy and paste this XML content:

To disable bitmap fonts for only a specific font:
Change "font" and "family" to the font info you want disabled.

If you want to disabe bitmap font scaling, delete `/etc/fonts/conf.d/10-scale-bitmap-fonts.conf`.
Deleting this file can fix bitmap fonts looking blurry.
--------------------------------------------------------------------------

Much of these fixes can be found in many Wikis of your distro [!]

This is probably the most generic, but efficient method of fixing any problems you have.
This is especially useful if a huge update was released and you're having issues with it. Simply verify your game cache.

To verify your game cache, right-click the Steam game in the client -> Properties, Local Files -> Verify Integrity of Game Files

Let that process run. This will depend on your hard drive speed and the size of the game.

Once finished, you will be alerted to how many files were redownloaded.

--------------------------------------------------------------------------
This fix is for Source engine games that support the use of joysticks or controllers. Some people have an issue with starting up the game from crashing or running out of memory. Their fix was to go into their launch options and add two parameters: "-nojoy -novid". Joystick support in these games seem to be buggy, specifically CSGO, so this could be a fix if you can't start up the game.
-novid removes the in-game startup intro movie for games that feature them.
-nojoy removes all joystick support when launching the game. This saves up RAM and also solve a startup crash a user had.

[NOTE]This is confirmed to be a bug in CS:GO Linux+OSX: https://github.com/ValveSoftware/csgo-osx-linux/issues/1757

--------------------------------------------------------------------------
These are a list of launch options NOT to use and why.
Having bad, deprecated, and useless launch options is a common reason for crashes and frame rate drops.

`-high` - This isn't necessarily bad for the majority, but I suggest steering away from this. What this launch option is meant to do is to set the game process to high priority. If your CPU is overclocked, this may potentially raise temperatures as well as the fan speed.
Just use caution with this launch option.

`-threads <X>` - This one is bad. Period. This option is supposed to enforce the game to use more CPU threads. Sounds like a good idea right? Wrong... at least in this game engine as well as other old engines.
Enforcing the use of more threads than the current maximum amount the engine, process, and hardware architecture is a bad idea as this will cause major crashes, frame rate drops due to improperly using the enforced excess of threads, memory leaks, system crashes, and higher temperatures.
This is a deprecated launch option.
Please don't for the love of God use this.

`-heapsize <KB>` - This one is also super bad to use. This originated from a memory leak in a few GoldSrc and Half-Life 2 games. This option was removed from future Source engine games, although it seems to still exist in some games. Valve has fixed the issue and advise users NOT to use it. This option is meant to enforce the amount of RAM to use. The same applies above; it's not good to use it and can cause problems.
This is a deprecated launch option.
Quote from Valve in 2010: "This command made sense in Half-Life 1’s memory manager. The current engine manages memory in a way that doesn’t need it specified. Under some circumstances, specifying a non-optimal heap size causes crashes and/or reduced performance"

`-processheap` - This command was very popular back then. Now it's not needed and should be avoided. The reason for this command was HL2/Source engine-based games were _very poorly optimised_ and this command fixed many issues. Now they have optimised it a LOT and using this will only hurt FPS.
This is a deprecated launch option.

This is pretty simple. Make the game windowed, drag it onto the correct screen, go back into full screen.
--------------------------------------------------------------------------
I'll get straight to the point.
`-novid` - This removes the starting game intro movie from showing. Just a QoL.
`-nojoy` - Don't use this if you use any sort of controller with a joystick. This removes joystick support, saving up some RAM.
`-freq <refresh rate in HZ>` - This sets your refresh rate. This isn't generally needed, but for NVIDIA users, this may be required.
[NOTE]: `-refresh <Hz>` and `-refreshrate <Hz>` are both the same. Just use one.
`-console` - Starts the console when the game loads into the main menu.
`-usemparms` - This is only needed if you use any mouse parameters such as `-noforcemaccel`, etc.
`-noforcemaccel`, `-noforcemparms`, `-noforcemspd`, etc. These are explained in the mouse section.
`-noaa` - Removes anti-aliasing of fonts. This is really only if you need every single bit of FPS you can get.
`-tickrate <server tickrate>` - Allows you to set the server tickrate locally. This command is used in dedicated servers too. In CSGO: tickrate is calculated by 16 multiplied by two. e.g.: 32 tickrate, 64 tickrate, and 128 tickrate.*
In CS Source and other pre-CSGO games, it's pretty much custom. 16, 32, 33, 66, 67, 100, 101, etc.

*The math:
16 * 2 = 32 tick.
32 * 2 = 64 tick.
64 * 2 = 128 tick.
There is also 102.4 tick (approx.), although for the best compatibility of clients, use tickrates multiplied by two shown above.

There are other launch options such as -windowed, -full, etc which are safe as well.
--------------------------------------------------------------------------
This differs from which sound daemon you are using. Here are a few fixes for users who are using PulseAudio:

Highly unlikely you'll be using analog surround for gaming but if you do, here's a fix.

You need to enable the low-frequency effects (LFE) and the Subwoofer remixer. To enable it, open up PA config in /etc/pulse/daemon.conf
Find "enable-lfe-remixing" and set it to " = yes "
Also, you should consider setting a proper crossover frequency for the LFE channel. The crossover frequency is the frequency up to which the audio signal is rerouted to the LFE sink. This value can be set from 40 to 200. To find the optimal value, it depends on the size of your speakers.
Find "lfe-crossover-freq" and find the optimal value via testing: " = 40-200 (choose a number)"
Once you made your changes, restart the PulseAudio server by the following commands:
pulseaudio -k (kills the server)
pulseaudio --start (starts the server)
If you had any applications open that were playing sound, be sure to close them and start them back up. Had this issue with Spotify. Music was playing while I restarted the PA server and I had to restart Spotify to get the music back. Just a small heads up!

This happened to me along with distortion and choppy sound and this fixed it for me. This is mainly due to incorrect buffer sizes. To find the problem, first check if the variables for the settings "default-fragments" and "default-fragment-size-msec" are NOT being set to non-default values in the PA daemon.conf file. If the issue still persists, try setting them to these values:
/etc/pulse/daemon.conf
default-fragments = 5
default-fragment-size-msec = 2

After making these changes, restart the PulseAudio server.

This is usually the result of an incorrectly set sample rate. Try changing the sample rate to these values in the daemon.conf file:
avoid-resampling = yes
default-sample-rate = 48000
Another small tip is uncomment "alternate-sample-rate" and set it to 44100 as a fallback in case 48000 is not supported by some programs such as Counter-Strike games.
Then restart the PA server.

If you have OpenAL and experiences choppy sound in applications, change the current sample rate in /etc/openal/alsoft.conf
frequency = 48000

Had this issue for some reason. Fixed it by this: If you use ALSA and hear some small static coming from your headphones, it may be ALSA's loopback mixing. One of the fixes for this is to disable loopback mixing. To disable it, traditionally, install the package `alsa-utils` and disable loopback mixing.

Also had this issue. To fix it, we need to know a tiny bit about the new PulseAudio implementation. The new PA sound server uses timer-based audo scheduling instead of the normal standard interrupt-driven approach. Using this, it may cause problems with a few ALSA drivers while some could still be problematic without this enabled. To figure out if you need it, test with it disabled and then enabled.

To turn it off, you need to put it in the right place.
Open up /etc/pulse/default.pa and find this comment along side with this line:
Once you found that EXACT line, right after `load-module module-udev-detect`, add this to it: tsched=0
It should look like this: `load-module module-udev-detect tsched=0`

Then restart the PulseAudio server.
If you need it enabled, simply take it off and restart PA.

Also, try out a few commands in game to see if this fixes the issue if it still persists:
snd_mixahead "0.025" (If it still persists, or it created more problems, raise it to the default value back then: "0.05" or even "0.1" if it's that bad.)
snd_pitchquality "1"

Pretty simple... depending on your installation.

If you use a Desktop Environment, for me it's Deepin, simply configure your microphone in your audio settings properly which fixed it for me.

If you don't or you do but that didn't help, be sure to check your Audio Settings in the game for a microphone tab. For me, I for some reason didn't have one.

If you still don't have your microphone working, try a few of these commands in game:

Try enabling `m_rawinput` to "1". I usually hate and try to not use raw input, but for some reason mouse acceleration is forced to 2/1 according to Xorg and regardless of what I do, it's enforced, making it crazy unplayable. Enabling raw input fixed this for me. Also, be sure to disable some other commands such as:
and make sure your m_yaw and m_pitch values are set to default: 0.022

If this doesn't fix it, go into your launch options and add this entry:
According to the Arch wiki, it "works with almost any other game." *claps*
No but seriously, try that.
Also, go into NVIDIA X Server Settings -> OpenGL Settings and untick "Sync to VBlank". If something bad happens after disabling it, enable it back and let it be.

First, try changing the Input Device w/pavucontrol (download the package `pavucontrol` and start it up). If that doesn't work, let's look at alsamixer. Sometimes Pavucontrol does not always set the correct input source.
Start up alsamixer in terminal `alsamixer`.
Press F6 and choose your sound card. Example: HDA Intel.
Press F5 to display all items and try to find the item: `Input Source`. Select that and with your arrow keys up and down, you can select the correct input source.

After doing that, check if your microphone records now.
--------------------------------------------------------------------------

This really depends on how you're connected. As I have no experience with WiFi on Linux (my drivers aren't compatible ;c), but a lot of experience with Ethernet on Linux, I'll do my best.
--------------------------------------------------------------------------
This applies to any form of networking and Internet access

We've all heard this generic but efficient method of changing your DNS servers.
Well, this works... depending on your situation.

~ If you have trouble loading websites.
~ Websites don't load properly
~ "clunky" web-browsing experience
~ Connecting takes longer than expected
You may need to change your DNS servers.

When not to change your DNS servers.
~ Your Internet speed is slow.
~ Your ping is high.
~ You're experiencing packet loss or choke.

This is based on other factors. DNS servers would not change these as this is domain lookup servers and not your ISP.

[WARNING] If you have a DNS cache provider like dnsmasq or even DNSSEC that modifies your DNS servers (resolv.conf), you _might_ want to refrain from modifying your resolv.conf or DNS servers in general. Check if your resolv.conf (located in /etc/resolv.conf) was modified by a DNS program. If it wasn't you should be safe to modify it. If it was, skip this section. If it was modified by "resolvconf" you can still modify it. This is probably just a DHCP service.

To change your DNS servers on _most_ distros, it's as simple as modifying your resolv.conf.
Open up your resolv.conf in /etc/resolv.conf as root.
Comment out your ISP's DNS servers (normally they will be 192.168.xyz.xyz as XYZ are numbers) in case this doesn't help you or you can't browse anymore so you can simply swap out the comments.
And add the following:

Here's my config in case you're confused:
Once you made your changes, write your config and the changes will take effect instantly.

Another way to change your DNS servers is if you have a program in your desktop environment for example `wicd` or `network-manager`. You can simply open your network manager app and change your DNS servers and the changes should take effect instantly.

[NOTE] You may notice browsing being slower than usual once you changed your DNS servers. This is normal. Since you changed your DNS servers, it has to look up many domain names and IP addresses. It's like an AI. When you first get the AI, it's weird and slow. But as you use it more often, it gets better. It's the same when changing DNS servers. It's slow at first, but faster as you use your machine normally. If your browsing issues don't resolve or got worse after a few hours, revert them back and move on.

--------------------------------------------------------------------------

This applies to Ethernet cards that support Jumbo frames and high MTU values

Paraphrase from Wikipedia:
"In computer networking, Jumbo frames are Ethernet frames with more than the traditional value of 1,500 bytes of payload (commonly known as MTU). Conventionally, jumbo frames can carry up to 9,000 bytes of payload, but variations exist and some care must be taken when using the term. Many, but not all, Gigabit Ethernet switches and Gigabit Ethernet network interface cards support jumbo frames, but all Fast Ethernet switches and Fast Ethernet network interface cards support only standard-sized frames."

To simplify it, most regular Ethernet cards support an MTU of 1500. But this is different if you have a Gigabit Ethernet card. Many Gigabit Ethernet cards support Jumbo frames which allows you to have the ability to use a larger MTU at the small cost of CPU usage and you can potentially significantly increase your network transfer rates. I use this and I have noticed a huge improvement in overall network performance in games and regular use as well as speed tests.
Your MTU value if your card supports JFs, can have an MTU value up to 9,000.

[NOTE] If you use an Intel CPU and have Intel C-State technology (essentially power saving features on your CPU), some Ethernet kernel drivers such as the e1000e can prevent the CPU from entering C-states lower than C3 with non-standard MTU sizes by design.

[REQUIREMENTS]
1. Must have a Gigabit backbone (example 1000baseT)
2. Your Ethernet card must support Jumbo Frames (JFs)
3. If you use a switch, switches must support JFs.
Simplified, just google your network card and check for Gigabit support and JFs support.
You do not need to be using Gigabit Internet. Just check for support for it.

There are a few ways to change your MTU value. If you use a network manager app such as wicd or network-manager, it's preferred that you use that to change your MTU as it stores it permanently until you modify it again. Otherwise, continue.

To change your MTU to a higher value, you must get your current NIC name. Simply do `ifconfig` on Ubuntu based machines or `ip addr` on Arch and other machines to get your NIC names. Find your current NIC you use, for example, mine is enp3s0.
And change it with this command:
`ip link set <interface name> mtu <size>`
Here's my example:
`ip link set enp3s0 mtu 4250`

To check if it's been changed, run `ifconfig` or this command:
`ip link show | grep mtu`
And check your NIC's MTU value.

If you changed your MTU value via the terminal, we need to create a systemd unit (or a service) to make it permanent.
This was found on the Arch wiki and should be similar on other distros.
Create a new file in /etc/systemd/system/setmtu@.service
Paste the contents into the new file you made:
Don't change anything.
Write that file and we'll move on to the next step.

Now create a configuration file for the new service:
/etc/conf.d/setmtu
In there, simply write this:
Your interface name being your NIC name and yourmtuvalue being your MTU value.

Here's mine in case you're curious:
Write that and now enable and start the service:
`sudo systemctl enable setmtu@<yourinterfacename>.service && sudo systemctl start setmtu@<yourinterfacename>.service`
Here's mine in case you're confused:
`sudo systemctl enable setmtu@enp3s0.service && sudo systemctl start setmtu@enp3s0.service`

If you want to change your MTU value again, modify /etc/conf.d/setmtu with your new MTU value and type in:
`sudo systemctl restart setmtu@<interfacename>.service` and it will set your new MTU value.


If your NIC is configured by netctl, another way to set your MTU permanently is to use ExecUpPost environment variable in the network profile:

From doing this tweak, I was able to not only lower my ping in games but increase my transfer rates and fix some small packet loss.

--------------------------------------------------------------------------

This applies to anyone with packet loss or ping spikes.

So you have packet loss which I hate so much and people always give you the generic answer "USE ETHERNET". They're... partially right, but not all the time.
We need to understand Ethernet. If you don't want to read this part, skip it.

I could use ethernet and still have packet loss. This can be caused by many different factors.
Let's make a few scenarios say you're using ethernet and using a Realtek Ethernet card that does NOT support Gigabit Ethernet and you're having packet loss. Let's also say you're using a Cat5 standard ethernet cable and your cable is NOT shielded and you're MTU is set to 1500. This user's Ethernet cable is about 94 feet and is routed through a few walls from downstairs to upstairs. And you have many wireless radios in your house. Let's understand the issues here:
Wireless Bands and a non-shielded ethernet cable.
You've seen those ethernet cables with metallic shields around their ends. Why do they have those? In short, it's to protect against many factors such as wireless radios and bands that are around the cable, protect against damage to the connector which can cause packet loss as one of the small wires inside the cord could be leading to nowhere or out of order which then causes faulty packet management/order sequences which is related to packet loss but a hard one to figure out the issue to. Shielded ethernet cords protect against many things and are very good to have on a cord. There are better articles which explain the good use of a shielded cord so I suggest googling those.
Next, MTU rate of 1500.
This isn't bad, but if you're having packet loss, one of the factors which were my issue in the past was my MTU was too high. Since this user's card does NOT support Gigabit Ethernet, they should not raise their MTU anything 1500 or above unless specifically required to.
A common and efficient fix is to simply lower your MTU rate if you experience ping spikes or packet loss. To lower your MTU, look at the section above which tells you how to increase it, but instead do the same and lower it.
Finally, the extremely long length of an ethernet cable.
I actually just learned this and am surprised to know this. But if you use a _very very_ long ethernet cable, speeds tend to gradually get slower because it can't handle the extreme length and can lead to transmission delays. For the most part, you shouldn't expect this issue at a length up to 146 feet (approx.) but as it gets longer, you could start seeing delays and lower speeds.
To overcome this, either buy a higher-grade ethernet cable (Cat5e, Cat6, Cat7) or simply use a shorter one when possible. I have the router next to me and I'm using a shielded Cat5e cable that's only four feet long.
You could also purchase a switch which is a good idea if you need long-distance travel cords and have many users who use ethernet.


So if you skipped that small writing about Ethernet and MTU, here are some quick suggestions:

Lower your MTU if you experience packet loss or ping spikes. (To do that, check the section above. The same instructions should apply to wireless users.)
Use a better ethernet card and ethernet cable. Fun fact, we're starting to roll out Cat8 and Cat7 cables which provide maximum speeds at 100 meters of 10,000+ Mbps and can, of course, be used for Gigabit Ethernet.
If you don't have the money for a Cat6 or higher cable, I suggest a Cat5e cable as that seems to be very common as well as Cat6 cables. I also suggest getting a shielded version of the cord you intend to purchase to protect it.
Use a shorter or higher-grade ethernet cable when possible to avoid delays from long-distance travel.

--------------------------------------------------------------------------

So say you're kind of forced to use WiFi. Don't worry, I was in your situation. And I hated it. Here are a few suggestions:

-Using a better wifi standard
If you don't understand, connect using a better version of the 802.11 wifi standard.
There are different types of wifi connections: 802.11a, .11b, .11g, .11n and .11ac, being 11n and 11ac the best out there at this moment.
As wifi got slowly better, we mostly used 11a, 11b, and 11g which... are very very slow and old compared to today's standards.
Most high-profit ISPs are now releasing 802.11n and 802.11ac routers to their customers providing high speeds with wifi connections.
Now, why did I mention all those different types of wifi connections? Because if one user decides to connect using an old method such as .11b, it slows EVERYONE else down.

You can't really control this if you're not the administrator of the router and use an old wifi card. But if you are the administrator and can log in to the router administrator panel, you can prevent connections of older versions. This prevents people from using old versions from slowing the whole network down, but older hardware may not be able to connect to the wifi network. Though, this is unlikely.

- Use a better wifi frequency
Many high-profit ISPs release dual-band routers. These routers support two different frequencies: 2.4GHz and 5Ghz. They're both quite different, but both have their own separate wifi access point. Here are some pros and cons of using both frequencies:

Pros and Cons of 2.4GHz frequency:
- Has a wider signal coverage area.
- Better penetration through walls and physical barriers that could be blocking signals.
- Supports Wifi b/g/n protocols.

Cons of using it are:
- If there are many devices using this frequency, it could be congested with a lot of interference.
- It only supports up to 13 (12 if you're in the US) wifi channels while only channels 1, 6, and 11 do not overlap each other.
- Since microwaves, ovens, Bluetooth devices, wireless keyboard and mice, cordless phones, etc ALL run on 2.4GHz (some devices use 5GHz frequency if they're high quality, but are kind of rare) and it could cause interference with each other.

Pros and Cons of 5GHz frequency:
- Few devices use this frequency, so it is less congested and less interference.
- Has many channels while 23 different channels don't overlap each other.
- Supports higher network speed with 802.11AC standard.

Cons:
- Has a smaller coverage area.
- Poor penetration power through walls and physical barriers.
- Older devices won't work with this frequency well.
- Might get interference from radars such as helicopters, airplanes, etc as these operate on 5GHz band.

If you're quite close to your router and can't use Ethernet, 5GHz should be your option.
If you're pretty far from it, I suggest 2.4GHz.

--------------------------------------------------------------------------
[WARNING] This section is about modifying your kernel settings. If you are not comfortable with modifying your kernel boot options, skip this section. Although, it's pretty hard to mess it up since it's just copying and pasting in lines of text into your Sysctl bootloader.

Assuming most people are using Sysctl, here are some parameters for your bootloader to improve performance.
[WARNING] Please note that this works best with Ethernet. Your card and hardware should be able to handle these options as these could prevent power-saving features, slightly higher CPU usage, and slightly higher RAM usage.

These settings came from the Arch Linux wiki but should be very similar to your other distros as long as you use Sysctl:

--How to modify your sysctl config--
Open up the following text file as root:
`/etc/sysctl.conf`

When adding options, you just need to simply create a new line, add the EXACT line in, and do the same thing. It's pretty simple.

-Increasing the size of the receive queue-
The received frames will be stored in this queue after taking them from the ring buffer on the network card.

Increasing this value for high-speed cards could prevent losing packets:


[NOTE]This option may require a high-speed CPU otherwise the data in the queue will be out of order.

-Increase maximum connections-
This one is pretty common and simple; allow more connections. The default setting is 128 which may not be enough:
[WARNING]Increasing this value may only increase performance on high-loaded servers and may cause as slow processing rate (e.g. a single-threaded blocking server) or an insufficient number of worker threads/processes.

-Increase the memory dedicated to the network interfaces-
The default Linux network stack is not configured for high-speed large file transfer across WAN links. (e.g handle more network packets) and setting the correct values could save memory resources:

-Increase UDP connection limits-
Pretty straightforward, you can increase the default `4096` UDP limits:

If you're unsure about some of these values, read these articles for more information:
http://www.nateware.com/linux-network-tuning-for-2013.html
https://blog.cloudflare.com/the-story-of-one-latency-spike/

-Enable TCP Fast Open-
TCP Fast Open is an extension to the transmission control protocol (TCP) that helps reduce network latency by enabling data to be exchanged during the sender’s initial TCP SYN. Using the value 3 instead of the default 1 allows TCP Fast Open for both incoming and outgoing connections.

-tcp_tw_reuse-
tcp_tw_reuse sets whether TCP should reuse an existing connection in the TIME-WAIT state for a new outgoing connection if the new timestamp is strictly bigger than the most recent timestamp recorded for the previous connection.

This helps to avoid from running out of available network sockets:

-tcp_slow_start_after_idle-
tcp_slow_start_after_idle sets whether TCP should start at the default window size only for new connections or also for existing connections that have been idle for too long.

This setting kills persistent single connection performance and could be turned off:
In other words, this allows TCP to start faster after the system has been idled for an extended period of time.

-Change TCP keepalive parameters-
~ TCP keepalive is a mechanism for TCP connections that help to determine whether the other end has stopped responding or not.
~ TCP will send the keepalive probe contains null data to the network peer several times after a period of idle time. If the peer does not respond, the socket will be closed automatically.
~ By default, TCP keepalive process waits for two hours (7200 secs) for socket activity before sending the first keepalive probe, and then resend it every 75 seconds. As long as there are TCP/IP socket communications going on and active, no keepalive packets are needed.

[NOTE]Note: With the following settings, your application will detect dead TCP connections after 120 seconds (60s + 10s + 10s + 10s + 10s + 10s + 10s)


-Enable MTU probing-
The longer the MTU the better for performance, but the worse for reliability.

This is because a lost packet means more data to be retransmitted and because many routers on the Internet can't deliver very long packets:


See https://blog.cloudflare.com/path-mtu-discovery-in-practice/ for more information.

-Ignore ICMP Requests-
Straightforward, disables replying to ICMP echo `ping` requests:
[NOTE]Note: Beware this may cause issues with monitoring tools and/or applications relying on ICMP echo responses.

I have filtered some of these parameters as some can cause security issues. If you would like to add those, I have provided the link here, beginning at TCP Timestamps and ending at ICMP requests:
https://wiki.archlinux.org/index.php/Sysctl#TCP_Timestamps

If you want my Sysctl kernel parameters:
If you're wondering what the Watchdog options are, we'll get to that in a separate section related to hardware.

--------------------------------------------------------------------------

Using a DNS cache resolver.
If you have installed `dnsmasq`, you already have a DNS cache resolver! Although, there are a few alternatives if you would like to look up a few. Here's a chart of the pros and cons of certain DNS resolvers from the Arch Linux Wiki: https://wiki.archlinux.org/index.php/Domain_name_resolution#Resolvers

--------------------------------------------------------------------------

Samba users: improve throughput.

It may be unlikely that you're using Samba, but if you are, here are some tweaks from the Arch wiki: https://wiki.archlinux.org/index.php/Samba#Improve_throughput

--------------------------------------------------------------------------

I'll get to the point and clear up some myths about some commands.

"Use cl_interp 0 and cl_interp_ratio 1!!!!"
Stop. Do NOT. These commands aren't bad, but it's bad to use the lowest value. Here's why:
Interpolation (speaking in game engine terms) is a very old (but super useful) feature to make models of NPCs, players, etc NOT skip, glitch and break around, making it easier to aim at players and properly place hitboxes. Although this helps with aiming, there is a small delay. Depending on your interpolation values determines this delay while having a high interp value could cause hitbox displacement as the model may be slightly ahead or behind the server-side hitbox. While having a super low interp value will cause models to skip, glitch or break around and making it hard to aim.
In CS:GO, client-side lag compensation pretty much runs this game and the interp feature. hence, how sometimes we feel like we got "back-tracked" after being behind a wall on your client while another player's client may still have seen you a split second and shot at you.

1. Using the LOWEST interp rates will just cause player models to glitch and skip around, depending on the server. (For the majority).
2. It's super unrecommended to calculate the interp rate yourself. CSGO's game engine calculation for interp ratios are a lot better nowadays and should be left alone. Should you find yourself accidentally messed with it, simply set your cl_updaterate to the servers tickrate. Set cl_interp to the default value. And we'll explain cl_interp_ratio.
3. What does cl_interp_ratio do and what's the "best setting for it"?.
It's pretty much a factor for how the game will calculate interpolation rates. Here's a small chart for the proper setting:
`cl_interp_ratio "1"` - ONLY use this IF, you don't drop a SINGLE packet, you're connected by Ethernet, and your game ping is less than 40. And you don't get ping spikes as well as have a stable high frame rate. Pretty much, use if your connection is super good. This should be used only on LANs.
`cl_interp_ratio "2"` - The recommended value for the majority of the players. Use this if you sometimes experience packet loss and ping spikes or none at all. Use if you have a semi-high ping such as 55, 65, 76, etc. And you're connected by ethernet or wifi. This should be used if you play online frequently.
`cl_interp_ratio "3"` - Highly unlikely you'll use this assuming you have even a standard decent connection. Use this if you have a high ping of 140+ constant and you occasionally drop packets.

So what's the "best interp setting"?
Leave the `cl_interp` setting alone while changing `cl_interp_ratio` based on your connection and update rate.

This is a lot more complicated if you're playing on pre-CS:GO games such as DOD:S, CS:S, etc as server tickrates and update rates weren't enforced very well like CS:GO does.

--The "rate" command--
This command isn't that useful if you have an internet connection of 8Mbps or above. If you do, simply set this to the maximum.
For poor connections, setting this too high will cause you to drop packets and have ping spikes as your connection can't handle it. Setting this too low, on the other hand, will cause delays and a higher ping as well as shots not registering.
If you have a poor connection, here's a chart for you to determine the proper value for it:

.5 Mbps – rate 62500
1.0 Mbps – rate 125000
1.5 Mbps – rate 187500
1.57 Mbps – rate 196608 (New Default)
2.0 Mbps – rate 250000
2.5 Mbps – rate 312500
3.0 Mbps – rate 375000
3.5 Mbps – rate 437500
4.0 Mbps – rate 500000
4.5 Mbps – rate 562500
5.0 Mbps – rate 625000
5.5 Mbps – rate 687500
6.0 Mbps – rate 750000
6.2 Mbps – rate 786432 (New Max)

--net_maxroutable--

IIRC, this command is set to the maximum already. If you have a stable internet connection that doesn't drop packets frequently, set this to 1200 as this allows you to send more packets. Lower this if you drop packets occasionally.

--The remaining commands--
cl_lagcompensation "1"
cl_predict "1"
cl_predictweapons "1"

Set these to one so that way in case you experience ping spikes or packet loss, the server will compensate for you, making it marginally better and easier to play.

So you have an SSD and would like to improve the performance of it? I am the same! I love having the fastest and newest hardware, especially since my distro is installed on my SSD. So here are some tweaks I've made to many things!

--------------------------------------------------------------------------
[NOTE] Know how to modify your fstab file just in case:
-Modifying your fstab-

So just about all distros create a fstab file which lists your disks and their purposes. There are some options that we can add to improve the performance of the SSD.
To modify your fstab, open the text file as root:
/etc/fstab

-TRIM your SSD-

As an SSD owner, you should know not to defrag your SSD but instead to TRIM it. There are a few ways to TRIM it but we're going to show you a few ways to TRIM your SSD.
These came from the Arch Linux wiki

--Verifying your SSD supports TRIM--
This is super important. If your SSD doesn't support TRIM, you can expect massive data loss.

To verify your SSD supports it, run this command as root:
`sudo lsblk --discard`

Find the values of DISC-GRAN (discard granularity) and the values of DISC-MAX (discard max bytes). If they are non-zero values (e.g. 512 and 2G, your SSD supports TRIM). If they're set to zero, your SSD does NOT support TRIM and should skip this section.

--Continuous TRIM-
This is my personal favourite as I use it all the time.
You can modify your fstab to continuously TRIM. The main benefit from this is an SSD can perform more efficient garbage collection[arstechnica.com]. However, results can vary from certain SSDs. I use a Western Digital 256GB Green SSD and this improved performance for me.
[WARNING] If you use an old generation of an SSD, this option can reduce performance.
[WARNING] If you use anything below SATA version 3.1, continuous TRIM would cause frequent system freezes. If you use SATA 3.1 or higher, you're fine. If you use less than SATA 3.1, Periodic TRIM would suit you better.
[NOTE] If you use fstrim periodically as a way to TRIM, there's no need to enable this.

Add the following option to your fstab file:
`discard`
In case you're confused, this is how you add options to your fstab file going forward:
Steam doesn't show this in a straight line, but this should be all in one line. And do NOT add spaces in between commas. (Except for the comment, that goes above the line.)

--Periodic TRIM--
Install the package `util-linux` which provides the services fstrim.service and fstrim.timer. Enabling the timer will trim weekly. fstrim.service actives TRIM on all mounted file systems that support the discard option.

Simply install the package `util-linux` and enable the services `fstrim.service` and `fstrim.timer`. The SSD will TRIM every week.

--Completely wipe and TRIM your SSD--
[WARNING] ALL data will be lost on this device.

This is used if you're selling your SSD or setting it up for a new install. This instantly discards ALL blocks on the device.

Use this with care!
`sudo blkdiscard /dev/sdX` while X being the device. (e.g. /dev/sda)

--LVM users--
Open the config file as root in /etc/lvm/lvm.conf and change the value of `issue_discards` to "1".

[NOTE] Enabling this option will "issue discards to a logical volumes' underlying physical volume(s) when the logical volume is no longer using the physical volumes' space (e.g. lvremove, lvreduce, etc)" (see inline comments in /etc/lvm/lvm.conf). As such it does not seem to be required for "regular" TRIM requests (file deletions inside a filesystem) to be functional.
--------------------------------------------------------------------------


Open up your fstab file as root and we'll talk about two options that can improve performance.

--Disabling access time update `noatime`--
The ext4 file system records information about when a file was accessed and there is a slight performance cost when recording it. With the option `noatime`, the access timestamps are not updated.
[NOTE]If an application requires when a file was accessed, this may make the apps not work.

Here's my example:

If you have `relatime` in there, remove that, but add a comment above telling you to put it back if there are issues as relatime is the opposite of noatime.

--Increasing commit intervals--

Your SSD is constantly syncing and preparing for any power outage. To reduce this to a specific value, you can change the commit value.

A further explanation: Say my commit time is set to 120 seconds. If I experience a power outage, I will lose exactly 120 seconds or two minutes of work. If my commit time is set to 5 seconds, exactly 5 seconds of work will be lost when restoring. The file system will NOT be damaged at all thanks to journaling. The higher the value the better but at a small work cost.

Add the following to your fstab partition:
`commit=xyz` xyz being whatever time you want. I use `commit=60`.

--Turning barriers off-
[WARNING] Disabling barriers for disks that do NOT have battery-backed cache is not recommended at all as data loss and severe file system corruption can occur if a power outage occurs.

Ext4 enables write barriers by default. It ensures that file system metadata is correctly written and ordered on disk, even when write caches lose power. This goes with a performance cost especially for applications that use fsync heavily or create and delete many small files. For disks that have a write cache that is battery-backed in one way or another, disabling barriers may safely improve performance.

To turn barriers off, add the option barrier=0 to the desired filesystem. For example:
--------------------------------------------------------------------------

I'm going to rewrite this section as I accidentally have put out some misinformation, I'm dearly sorry! >.>

Swap partitions are meant for a "fallback" / overflow area when your RAM gets full and processes need that extra few megabytes. Some users choose (like me) not to use a swap partition based on our needs and hardware. If you choose NOT to use a swap partition, when you run out of memory, Linux will start killing processes to free up memory. This can be pretty bad for some users. If you choose to use swap and run out of memory, your applications will simply become slower instead of being killed.

For SSDs, Swap uses write cycles and some users don't need those wasted write cycles and life expectancy. So since I don't ever use swap or have even used/needed it, I'm going to leave it up to you to determine whether you need swap or not. If you want my opinion, use swap whenever you can.
--------------------------------------------------------------------------

So you have a mechanical spinning hard drive and want to improve performance on it? This is pretty common with regular HDD users as the speed is a lot slower than an SSD.

As I don't use HDDs that much except for the 2TB HDD that I don't use too often, I'm going to be trying my best to help.


Remember how you had to partition your hard drives to install our distro? Well, there's a pretty huge tip I just recently found it.

So say you're dual booting Windows and Arch like me. (even though I don't even touch Windows anymore). When you were partitioning your hard drives, you had a few partitions that were at the very front of the partition layout scheme and were pretty much locked. Why does this matter?

According to the Arch Wiki, if you run a spinning mechanical HDD, your partition layout scheme can influence the system's performance. Sectors at the very front of the drive tend to be a lot faster than those at the end which is what you might be doing.

It's also a good idea to divide up your hard drive into many different sectors based on what you intend to use them for as smaller partitions require fewer movements from the drive's head which speed up disk operations.
For example, I have a 500GB hard drive.
It's good practice to divide all that up into different needs and uses.

It's a good idea to have a small partition of 10GB or less being your system partition and as near to the beginning of the drive as possible.

Then you can create another partition of, let's say 50GB, for your home directory. This can be achieved by separating the home directory (/home/user) from the system (/).

Then you can continue dividing up the remaining amount for whatever use you want.

--------------------------------------------------------------------------


There are a few kinds of file systems; Ext3, Ext4 (most common and preferred), JFS, XFS, Btrfs, and ZFS.

As there are many different kinds of file systems, I'll assume you're using Ext4 and these tweaks will most likely apply to Ext4 file systems.

--Disabling access time update--
(This works for SSDs too)

When you access a file, the ext4 FS (file system) records that information. There's a speed cost with this. You can modify your fstab file to prevent this.

Open up your fstab file as root: (/etc/fstab)
Find the partitions you want to apply this to.
[NOTE]Don't apply anything funny or fancy to your boot partition just to be safe.

For this example, mine is /dev/sda6

Right before the end, you see a few parameters such as relatime,rw, etc.
Find relatime and replace relatime with `noatime`.

[NOTE]Any applications that rely on when a file was accessed may not work properly. This is unlikely though.

Write that file and reboot once you're done.

--Increasing commit intervals--
(This works for SSDs too)

Your HDD is constantly syncing and preparing for any power outage. This costs some speed as it's continuously writing and reading. You can increase this value to reduce the amount of time it has to read and write, but at a small cost in case a power outage occurs as depending on the value you set will be how many seconds of work you will lose.

A further explanation: Say my commit time is set to 120 seconds. If I experience a power outage, I will lose exactly 120 seconds or two minutes of work. If my commit time is set to 5 seconds, exactly 5 seconds of work will be lost when restoring. The file system will NOT be damaged at all thanks to journaling. The higher the value the better but at a small work cost.

Add the following to your fstab at the partition parameters which you want to add this:
`commit=xyz` xyz being what ever time you want. I use `commit=60`.

[NOTE] Please check your EFI/boot partition to see how much space you have currently and the maximum amount as installing a new kernel will require some space depending on the kernel you intend to install.

[NOTE] I strongly suggest backing up your old kernel files just in case something goes wrong and you want to restore back. I have my old Linux kernel on a USB drive along with my Arch live installation.

This is my favourite as I love tinkering and messing with the kernel. Just about all Linux-based distros come prepackaged with the standard `linux` kernel. There are a few things that I don't like about this.

There are many kernels but we will talk about two for now. The standard Linux kernel and the `linux-lts` kernel.

`linux` kernel updates every few days or weeks. And sometimes, there are updates which make your system unstable, unbootable, etc. And we can't predict when this will happen as this happens to everyone and the best of us.

The `linux-lts` kernel, says it all. It's a Linux kernel that instead of receiving updates frequently, you only get shipped security updates and major updates every few months or so. This provides better stability and reliability for your system.

But then there are other kernels. I'll talk about `linux-ck` and `linux-zen` as those seem pretty mainstream and both are my favourite.

Linux-ck kernel is kind of like the standard Linux kernel. It receives semi-frequent updates. It's not always reliable. But there's something special with this kernel. This kernel is more focused towards performance. This kernel is focused towards tuning your system.

Linux-zen is pretty much similar but I haven't been able to use it successfully for some reason as it fails to compile NVIDIA drivers.

So which kernel SHOULD you use?

Linux-lts if you're wanting reliability and stability.

Linux-ck if you're like me who want higher system performance and responsiveness (assuming your hardware can handle it)

And what is this kernel headers thing?
Your kernel is missing headers for it to run optimally. Most of the time, they won't come shipped default so this is why when you pick out your kernel, you need to install the headers too. Don't worry, it's pretty simple. Usually, it's just `linux-kernelname-headers` being -headers at the end of the kernel name.
[NOTE] Be sure to do a little research on your kernel. Some kernels have specific versions of it depending on your graphics card and/or CPU. Linux-ck, for example, has the standard build for supporting all CPUs and they have other builds such as `linux-ck-skylake` for Intel CPU Skylake users and such.

--------------------------------------------------------------------------

So you finally picked out your kernel. We need to install it now. Assuming you have enough space in your boot partition, we can set it up. The process slightly differs from your bootloader.

--GRUB users--

Install your kernel. Usually, they'll be in your default repositories but if not, you may need to add them in. Arch users, download an install an AUR helper and you can find them.

Arch Users:
`sudo pacman -S linux-ck linux-ck-headers` to download and compile the kernel and headers. Remember, replace linux-ck and linux-ck-headers with the kernel of your choice.

Linux distros with APT:
`sudo apt install linux-ck linux-ck-headers` to download the kernel and headers. Remember, replace linux-ck and linux-ck-headers with the kernel of your choice.

Once it has finished, check the compilation and download logs in your terminal for any errors. If there are errors, be sure to google them before using your kernel to save yourself some headaches. If there are any warnings, don't worry about them unless they specify something you use for example NVIDIA or LVM.

When you verified everything went through smoothly, we now need to change your boot loader's config!

GRUB users, you can simply generate a new config and check it that it's using your new kernel. If not, simply change the old kernel to the new one.

--Systemd users--
I use a lightweight boot loader so this is pretty easy.

Download and compile your kernel as shown above.

Open up your boot loader's config. For me it's, /boot/loader/entries/arch.conf

Find the line that starts with `linux`. This is pretty self explanatory. Change the default `vmlinuz-linux` to your new kernel. For example, here is mine:
Next, find the line that says `initrd`. Do the same thing. Change the default one to your new kernel. Here's mine:

If you use Intel's Microcode, you need to add a new line, saying you want to use Intel's microcode, assuming you installed it:

After doing this, your Systemd bootloader config should look something similar to mine:

You can change the title if you want.

--Other bootloaders--
You need to google your boot loader's config.


If you installed your kernel's headers, you don't need to do anything. They're automatically added into your system.

Once you're finished, write your config and reboot!

If everything worked as it should, you should be back into your system.
If something didn't work as it should replace your new kernel with the old kernel you should have backed up.

--------------------------------------------------------------------------
Quote from Arch Wiki:

Processor manufacturers release stability and security updates to the processor microcode. While microcode can be updated through the BIOS, the Linux kernel is also able to apply these updates during boot. These updates provide bug fixes that can be critical to the stability of your system. Without these updates, you may experience spurious crashes or unexpected system halts that can be difficult to track down.

Pretty much. You SHOULD have your CPU's microcode installed.

--Installing your microcode--

Determine your CPU manufacturer. AMD or Intel should be pretty common.

Intel CPUs---
Arch users: `sudo pacman -S intel-ucode`
Ubuntu users: `sudo apt install intel-ucode`

AMD CPUs---
Arch users: `sudo pacman -S amd-ucode`
Ubuntu users: `sudo apt install amd-ucode`

Any other distro, the process should be very similar.

--Enabling early microcode updates--

To enable early microcode updates, you need to configure your boot loader's config.
This varies with different bootloaders.

---GRUB users---
GRUB's `grub-mkconfig` will automatically detect the microcode when generating a new config. To add the microcode in, simply generate a new GRUB config.

---Systemd-boot---
Simply open up your loader entry as root. For Arch users, it will probably be `/boot/loader/entries/arch.conf`

Once you've opened your bootloader entry, right above the RAM disk and right below the `linux linux-yourkernel...` kernel entry, you need to add:
Assuming your microcode was installed in the root of the /boot/ folder/partition.

Replace `intel` with `amd` if you use AMD.

Write the file and reboot.


Other bootloaders, please google your bootloader and installing microcode updates.

--------------------------------------------------------------------------

There are a few ways, but here's the most common way:

Run this command: dmesg | grep microcode

If nothing comes up, microcode wasn't installed properly.

If you have a lot of entries coming up, microcode was installed properly.

If you're like me and have only two entries, this is normal... ish.
It depends on your kernel. If you use a custom compiled kernel (linux-ck, linux-zen, etc), this is probably why as the process to fully enabling microcodes in custom kernels are a little tricky.
If only two entries come up and you have a standard Linux kernel (linux, linux-lts), this may mean it wasn't installed properly or the kernel you use is custom and not a traditional Linux kernel.

Another way of checking microcodes is your bootloader's logs or your system boot up logs.

--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
(Thanks Cpt_Kopfschmerz!)
Gamemode, is a daemon/lib combo tool developed by Feral Interactive which allows games to request a set of optimisations to be applied temporarily to the host OS. The tool is open source and aims to improve performance when playing games.

This is a little advanced and since I never have used it (might use it soon though), I'll leave it up to you.
There are instructions in the README.md which instructs you how to compile it.
https://github.com/FeralInteractive/gamemode

Arch Linux users, this is on the Arch User Repository. So if you use an AUR Helper, you can compile and install this quickly.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------

[WARNING] Use CPU monitoring tools (for temperatures, voltage, etc.) when changing the default governor. You should be safe for the majority.

[NOTE]If you overclocked your CPU and/or GPU, Linux will report your temperature incorrectly. Usually, it will claim to be 28 degrees C, but it is not. There are workarounds, but I don't know any at the moment.

[NOTE] See the end of this part about changing CPU scaling governor for a utility to change it. (Thanks Lord VoldeSnort! ^~^ ) **

[NOTE]This may reset on reboot. Create a service to automatically change it.

The CPU governor is pretty much power schemes. Just like the Power Management control panel in Windows. There are a few CPU power schemes. Take a look at the table:


Assuming you're here for performance, we're going to use the `performance` governor.

To see the current governor, enter this command:

This lists the CPU governors for all the CPU cores.

To change it to the governor of your choice, enter this command:

For me, I'm going to set all my CPU cores to performance:


[NOTE] Using `performance` CPU governor sets your system to run at the maximum speed. For example, if you have a 3.4GHz CPU, it will run constantly at 3.4GHz. If you're overclocked like me for example 5GHz. It will consistently run all cores at 5GHz.
Use this into consideration if you're worried about temperatures.

The changes take effect immediately.

To make it permanent, you need to add it as a system service or so. This differs from your distro. Arch users, you have to create a new system service on boot up.
IIRC, if any Linux user uses GNOME, they have a GUI for this.

**If you want or have a CPU frequency utility or something along the lines, you can also change it via that instead of the console. Some CPUs may even support a Turbo option.
There are other utilities and alternatives to these but these are what I've found.

To get a utility for this, simply install the packages:

Ubuntu users: sudo apt install cpufrequtils
sudo apt install indicator-cpufreq

Arch Linux users:
This is in the Arch User Repository, you will need an AUR helper. For me, I'm using Trizen.
trizen -S cpufreqd
(Never run an Arch User Helper as root. Sorry!)

Simply install those and open up your utility. You should be able to change your governor on the fly with the click of a button! It will sit in your taskbar.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
This is probably the biggest game changer of all time. This applies to any machine and any Operating System.
Source for all of this: https://access.redhat.com/solutions/18627

Quote from Redhat:

Originally posted by Redhat:

An overview on hardware clock and system timer circuits:

When it comes to talking about a system's clock, the hardware sits at the very bottom. Every typical system has several devices, usually implemented by clock chips, that provide timing features and can serve as clocks. So, which hardware is available depends on the particular architecture. The clock circuits are used both to keep track of the current time of the day and to make precise time measurements. The timer circuits are programmed by the kernel, so they issue interrupts at a fixed, and predefined, frequency. For instance, IA-32 and AMD64 systems have at least one programmable interrupt timer (PIT) as a classical timer circuit, which is usually implemented by an 8254 CMOS chip. Let's briefly describe the clock and timer circuits that are usually found with any nearly modern system of those architectures

In short, all machines have a hardware timer which pretty much sits next to a CPU and does similar functions to it, such as passing functions to the CPU, at a certain frequency and ratio.

There are many timers, but there are two specific ones: HPET and TSC.

High Precision Event Timer (HPET)
The HPET is a timer chip that in some future time is expected to completely replace the PIT. It provides a number of hardware timers that can be exploited by the kernel. Basically, the chip includes up to eight 32 bit or 64 bit independent counters. Each counter is driven by its own clock signal, whose frequency must be at least 10 MHz; therefore the counter is increased at least once in 100 nanoseconds. Any counter is associated with at most 32 timers, each of which composed by a comparator and a match register. The HPET registers allow the kernel to read and write the values of the counters and of the match registers, to program one-shot interrupts, and to enable or disable periodic interrupts on the timers that support them.

Time Stamp Counter (TSC)
All 80x86 microprocessors include a CLK input pin, which receives the clock signal of an external oscillator. Starting with the Pentium, 80x86 microprocessors sport a counter that is increased at each clock signal and is accessible through the TSC register which can be read by means of the rdtsc assembly instruction. When using this register the kernel has to take into consideration the frequency of the clock signal: if, for instance, the clock ticks at 1 GHz, the TSC is increased once every nanosecond. Linux may take advantage of this register to get much more accurate time measurements.

If you want the cut and dry statement of which to use: Use TSC if you're not in a server environment as HPET complies better with a Watchdog timer. Use HPET and a Watchdog timer if you're in a server environment.

Why? HPET is deprecated and used solely for older machines and hardware or servers. If you're running Windows (ew.), do not use HPET starting Windows 8 and up as Microsoft have implemented their better and faster timer: TSC, and using multiple hardware timers at once will create severe conflicts with each other which is then why your performance dips.
The same applies here on Linux, use HPET only if you're running it on a server and use a Watchdog timer and/or running legacy/old hardware as those perform better.

Now, how do we turn it off or on?
First off, you need to go to your motherboard's BIOS / Setup to turn off the hardware version of HPET, cutting all support from operating systems and applications that use it so it can fallback to TSC or another timer.
This differs from motherboards, but it should be in a hardware section and is labled "HPET" or "High Precision Event Timer".

Now, we need to turn it off in the system. If you're using Windows, why are you here?, and it should be disabled by default, but you may need to disable it in Device Manager and type in some console commands to completely turn it off.

If you're on Linux, this is actually pretty simple, but we need to change two things. First, check what timer you're currently using:
If it says `hpet`, you need to change it to `tsc`.
But first, we need to check what timers we can use:
For me, I have `tsc` and `acpi_pm`. We're going to use `tsc`. To change it to TSC, echo this command:

To make this permanent and use it on boot up, we need to add to our kernel parameters: `clocksource=`

If you use GRUB, go into your grub.cfg and find your kernel. Once you found it, find the `linux` line and at the very end of it, add this:
`clocksource=tsc`
Replace TSC if you use a different timer.
Do the same for others if you have some.

If you use systemd-boot, go into your /entries folder and find arch.conf or what ever it's named as. And at the end of `options`, add the same:
`clocksource=tsc`.

Reboot and check the current timer you use. You might also get a huge performance boost!

Security. A huge topic. Performance is useless if your security isn't good. So this guide will help you with that without losing any performance. c:

--------------------------------------------------------------------------

SSH. The most important thing any Linux user can know and have. But, the default installation isn't very secure. Let's harden it.

[NOTE] To check the sshd_config file for syntax errors, use `sudo sshd -t`. If you want an extended test mode, use `sudo sshd -T`.

A huge one. NEVER. EVER. Login as root. Even if you're the only user, just don't. You're so much better off just either typing sudo for most of your commands or using `su` to allow root access after logging into your account, assuming you're the system administrator with the permission to log in as root.

First off, open the OpenSSH config as root:
`/etc/ssh/sshd_config`

Find the commented line that says "#PermitRootLogin no"
Uncomment that and make sure it says `no`.

Then restart the OpenSSH service.

--------------------------------------------------------------------------
Pretty much a whitelist of users or a user group that can SSH into the server and can not.

Find the line that says "AllowUsers"
Uncomment it and add a list of users you want allowed. (Note, they still need a password + username to login.)
[NOTE]When adding users, make sure they're separated by a space and NOT a comma or anything.
Example:

You can also allow only user accounts in this group to login.
`AllowGroup sshusers` Replace sshusers with what ever you want.
--------------------------------------------------------------------------
In other words, do not allow users with no password to login at all.
Why would you even create a user with no password in the first place?!?!

Find "PermitEmptyPasswords".
Uncomment and set it to `no`.

--------------------------------------------------------------------------
Why use a different one? Well, many brute force programs for SSH use the most common port "22". This is the most common and default port for OpenSSH which is very insecure.

In sshd_config, uncomment "Port" and change the Port value to anything above 1026. Not required to, but the higher the better.

--------------------------------------------------------------------------
By default, OpenSSH listens to ALL available network interfaces and IP addresses on the system. This can be pretty bad.
We're going to add both your Public IPv4 address and your Private IPv4 address so you can connect via LAN+WAN.

Find the line "ListenAddress". Uncomment it and add your IPv4 address.
Add the same line right below it and add your Public IPv4 address.
Example:
--------------------------------------------------------------------------
Straightforward. Kicks out users who are idle for a certain amount of time.

Open sshd_config, find the option "ClientAliveInterval" and set it to a time in seconds.
Example:
`ClientAliveInteraval 600`
600 seconds = 10 minutes.

--------------------------------------------------------------------------
In short and simple, limits the max amount of users that can connect at once.

Find `ClientAliveCountMax` and set it to the number of maximum users.
Example:
`ClientAliveCountMax 12` Twelve, being the maximum amount of users that can connect.

--------------------------------------------------------------------------
Disabling this disallows reading the .rhosts and .shosts files located in ~/ or the user's home directory. Disabling this prevents the emulation of the obsolete rsh command and is insecure.

`IgnoreRhosts yes`
--------------------------------------------------------------------------
This isn't really a security tweak, but something you can customize to warn the user of what they can and can't do and if they do this, then this will happen and such, etc. Like a TOS or EULA.

`Banner /etc/issue` (Doesn't have to be `/etc/issue`, just specify the file.)
Then modify the /etc/issue file to your liking.
--------------------------------------------------------------------------
By default, a key strength of 768 bits is used. Current recommendations are for 1024 or 2048 bit strength. While I don’t expect this to be an issue, its a simple step. Once you change this, you will need to delete your current host keys and SSH will regenerate them when it restarts.

`ServerKeyBits 1024` Replace 1024 if you want to use a higher value such as 2048 or even 4096 if you want to go crazy.
--------------------------------------------------------------------------
And finally:
Why not? The answer is passwords. Someone can be dumb with their password and make it simple, or give it out, or use the same password over and over and a website gets login dumped, anything can happen. So we shouldn't use passwords, but keys instead.

From my experience, making SSH keys were difficult and tedious for some reason (maybe it was just Ubuntu Server being mean to me or whatever), but I can ensure you it's not a hard process and a lot better to use.

If you do end up using SSH keys and don't want to use passwords (thankfully), you can simply turn off password authentication:
`PasswordAuthentication no`
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Your computer. This is what I mean by physical security. You may have the best security on your server, but having poor security for you can cancel it all out. You should also use these tweaks on your server, not just the client!
Since I don't pay too much attention to some security features such as encrypting volumes and folders, LVM, etc, I will try my best with this part.

Pretty simple. Just use a password for GRUB and BIOS which I will explain how to do.

[NOTE] Please make sure you have a safe and secure place as well as a fallback/backup in case you lose your password!

--BIOS password
Using a BIOS password allows unauthorized users from configuring your BIOS and disable booting from any external media without the password.

This differs from motherboards, but they are all a very simple process to find and do.
For MSI motherboards using Click-BIOS, it's usually in the Security or the Boot section.

--GRUB password
This is pretty useful as well. This disallows users from accessing GRUB's boot menu unless you have the correct password.

First, make sure you have the package `grub-common` installed.

Once you have that package, type in `grub-md5-crypt` with root permissions and enter the password you want.

You will get an MD5 hash password, take note of it and keep it safe and secure. You will need this later.

Now, open up GRUB's config file (you have two options, /boot//grub/menu.lst, or /boot/grub/grub.conf. Both are the same and symbolic link to each other.)

Add in the following line anywhere:
Replace MD5 hash with your hash.
Example:
password --md5 $1$TNUb/1$TwroGJn4eCd4xsYeGiBYq

[WARNING]Have a backup of those two files in case something doesn't work and you're locked out of GRUB so you can use a live installation media to replace the config files.

Write the file and reboot your machine.
When you get into GRUB, it may or may not ask you for a password. If it does, enter it and see if it works. If not, press `p` and enter the password. If everything works, you can successfully boot up.
--------------------------------------------------------------------------
Quote from Arch Linux wiki:

An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access. There is little you can do from preventing this or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.

You can do a few things to minimize the risk of this happening, but you can't completely block this.

Some motherboards' BIOS firmware has an option to disable Firewire and Thunderbolt ports. Just recently, MSI released a BIOS update (at least for my mobo) with the option of disabling Thunderbolt and Firewire ports. This is very useful to minimize the risk of this vulnerability.
You could also block up the PCIe ports, although I'm not sure if there's a way to turn them off.
--------------------------------------------------------------------------
This is a pretty nifty and cool idea and I actually used it for a while myself. You can put your boot partition on a removable media, for example, a USB key and if the key is not plugged in, it will render the system bootable without it. Or, well, at least the operating systems that are on the USB key won't be able to boot without it.

This differs from bootloaders, but I can tell you that GRUB supports this. I don't know the steps for this, but for GRUB, it's pretty simple as formatting and making the media FAT(32) and installing GRUB on it which is almost the same process you do on a hard drive.
--------------------------------------------------------------------------
BadUSB, PoisonTap, LanTurtle, and live-boot distros such as Tails are a few common examples but there are many more.
You can protect yourself from devices like these with a software called USBGuard. USBGuard is a software framework which helps protect your computer against rogue USB devices by implementing basic whitelisting and blacklisting capabilities based on device attributes.

The installation process is pretty simple, but you need to take caution. If you misconfigured an option or anything, all USB devices may be blocked!

First, install the package. I suggest the github version as the regular version doesn't seem to work properly for me.

Once you installed it, open up the configuration file as root found in /etc/usbguard/usbguard-daemon.conf
Find `IPCAllowedUsers`, this allows you to control the daemon via IPC. Add your username in. In most cases, you would want this.
You can do the same in `IPCAllowedGroups` if you want and you can add `wheel`.

If you want to do any other configuration, look at the comments in the config file. They do a very good job at explaining what each option does in the comments.

Once you saved that file, you have to set up your Rules.conf so that way all your USB devices will be recognized and not blocked when starting the daemon. For this process, you NEED to be logged in as the root user. This is the only time you need to and it will be very quick. For me, using sudo didn't work and had to be the root user.

To configure usbguard to your needs, you can edit `/etc/usbguard/rules.conf` However manual editing of the rules is normally not necessary. You can generate a ruleset based on your currently attached USB devices by executing `usbguard generate-policy > /etc/usbguard/rules.conf` as root.

Once you're logged in as root, simply execute `usbguard generate-policy > /etc/usbguard/rules.conf` and it will write out a list of connected USB devices and allow them all and put them in rules.conf (assuming you're using the standard location of the config). Check if it worked by `cat /etc/usbguard/rules.conf`. You should see a bunch of USB devices that you have connected shown. If you can see your devices, then log out into your normal account via `exit`.
For example, this is an HP printer connected via USB:
A rule begins with a policy. `allow` whitelists a device and lets it go through. `block` stops the device from being processed and executing anything, pretty much rendering it like it's disconnected. And `reject` removes the device from the system. Then it follows a set of attributes with their options.

Now you're ready to actual use USBGuard!
USBGuard has a core daemon, a CLI, a QT GUI, a DBUS interface and an API via libusbguard.
If you want to use the QT GUI or another program communicating via DBUS, enable + start `usbguard-dbus.service`
If you want to communicate only via API (with a CLI tool or another software using libusbguard) enable + start `usbguard.service` (recommended)

[WARNING] Make sure to actually configure the daemon before starting/enabling it or all USB devices will immediately be blocked! (We have just done this so don't worry.)

Check if it's up by `sudo systemctl status usbguard.service`.
If it's running, you're ready and it's working as you read this!

To access the GUI of USBGuard, it should be in your applications. If not, it might be one of the following: `usbguard-applet-qt` or `usbguard-dbus`
To use the CLI, use `usbguard`.

If you're using the GUI and have it open in the background or is pulled up, if you connect any USB device, it will alert you of what you want to do with it. You can allow, block, or reject it. If the USB device is unfamiliar with you, reject and block it. You can make the selection permanent by having it write to the rules.conf.

--------------------------------------------------------------------------
A few Linux distros such as Fedora, CentOS or RHEL allows the console user to perform an interactive system startup by pressing I (not L, capital i ). Using interactive boot, the attacker can disable the firewall or other system services.

To change this, open up `/etc/sysconfig/init` and add or modify the setting and change it to `no`:
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
You can't rely on these. You also need to do some of your own work to protect against attacks and such.

~ Avoid using old connection methods like standard FTP, Telnet, etc
Or anything that isn't protected by SSL/TLS.
Without an encryption, people can capture commands, transferred files, requests, etc by anyone on the same network or intercept the data transfer and sneak in a fake website, malware to download, etc.

If using FTP - Use SFTP (SSH over FTP) or FTPS (FTP over SSL) or add SSL and/or TLS encryption to standard FTP.
SSH - Don't login via username + password. Use a password key file and make sure it's hidden from public/plain and obvious view.

*Not necessarily bad, but try to use alternatives as it's still useful.

~ Use keys to encrypt and sign data and communication. (GPG keys, SSH keys, etc)

~ If using a VPN, use OpenVPN as it is a light-weight SSL VPN.

~ If hosting a website, ALWAYS enforce HTTPS and use a verified SSL certificate and NOT a self-signed one. If you can't afford one, you can go to LetsEncrypt[letsencrypt.org] to get a free 90 day certificate to add to your website. Yes, you can renew it.
Cloudflare also provides free shared edge certificates and origin certificates if you set up your website properly.
If you're lucky and use Cloudflare's origin certificates, use HSTS (HTTP Strict Transport Security) which is a super strong method of HTTPS. It includes specific HTTP headers that have huge security tweaks and enforces a strong security policy.

~ Minimize the use of software. Try not to install a lot of software that you won't use to minimize the chance of one of the applications to be vulnerable to an exploit.

~ Install a package and kernel dedicated to security such as SELinux. This is a pretty broad topic so I will let you find this yourself.

~ Use a strong password. The generic, but most obvious and effective way to protect yourself. Use a strong good password. Have at least a number or two. A special character ( !@#$%^&*_ ) etc. And have no COMPLETE or common dictionary words.

~ Change your password every few months or weeks.

~ Don't use a previous password you have used in the past unless you're out of ideas. (Impossible!)

~ Lock user accounts after a certain amount of login failures. I will explain how to do this soon. But using `faillog`, you can configure it to auto lock an account that has had a certain amount of failed login attempts.

~ Verify you have no accounts that have empty passwords. Enter this command as root: `awk -F: '($2 == "") {print}' /etc/shadow` and if any user accounts come up, either give them a password or lock them up.

~ Verify no non-root accounts have the user ID (UID) of zero (0). Having a UID of 0 is root access w/full permissions and access. Only the root account should have this and no one else. Enter this command as root to check: `awk -F: '($3 == "0") {print}' /etc/passwd` You should only see the `root` account show up. If any other accounts show up, delete them or if possible, change their UID or just re-create their account.

This guide was written using a script to bypass the 8,000 character limit. With doing so, I am unable to edit the actual sections themselves without removing 500+ characters. So I made a section dedicated to anything I poorly explained. Sowwy! >.<
--

They're files and libraries used by the kernel to function better with other components, software and hardware on your system.
If anything in the user space needs the headers, it will use them alongside with your kernel. Think of them as drivers to your system so that way they can be used to interact with the system, (headers are not the same as drivers, just think of it that way!).
The headers are used by DKMS to compile modules for the kernel to be used with on boot up.

Distributions and Devices I have tested many of this:
Arch Linux
Debian*
Kali Linux*
Parrot OS*
Android**
Raspberry Pi 3*

*is apart or based off of Debian
**A very small amount of things were tested on my rooted Android device using the classic Bourne shell (sh) and not bash. Though, still worth mentioning.
Arch Linux is really the huge factor in this as I wrote this on that distro specifically. I am now using Windows 7 + Debian so I can test more stuff easily.

Thanks for the people in the comments and on the original Steam thread for their input on this. <3

For those wondering why this is not in the Steam for Linux section... I did not know there was a Steam for Linux guide section. So I kind of kept it here. Sorry. (Steam please help!)

If you would like to help me with this, request any help with the tweaks, inquire about sources, etc; you can contact me in many ways:

Twitter (I don't tweet, I might soon though): https://twitter.com/dotAshleyy
Email (preferred): meowiee@archlinux.email *
Steam: https://steamproxy.net/profiles/76561198823411448 **

**is subject to change in the near future
*not a developer or affiliated with Arch Linux in any way. this is NOT the official Arch Linux email name. the domain is allowed to be used as requested from Arch Linux staff.