Haven't heard that one before.

I use Ruby when I can. Lots of Bash. I've done some in Python recently, Java some time ago. D.

Removed by mod

The first thing you're missing is backing everything you want to keep up in a separate location.

For 4, yes, Linux supports NTFS (what Windows uses) and just about every other filesystem you'd see.

For drivers, almost everything is in the kernel; that is, you don't have to do anything, you just get them with almost any distro.

The common exceptions to that are NVIDIA graphics drivers, for which the free ones are usually insufficient, and Intel wifi chips, which have proprietary drivers.

When you're installing, the installer should give you give you the option, when partitioning, to create a LUKS encrypted drive. You should do this; it's easier to encrypt your disk now than it is after you've installed this. This requires a separate /boot: the bootloader doesn't know how to encrypt the disk, so you need to put Linux on a separate unencrypted partition so you can boot it and decrypt your /.

I assume you're using array.index(char), which returns the first index. index also accepts a start argument, so ['a', 'b', 'b', 'a'].index('a', 1) will return 3.

A bit more natural way to write this is to loop over the search list, and just check for equality, like this:

def indices(array, search):
    indices = []
    for index, value in enumerate(array):
        if search == value:
            indices.append(index)

    return indices

This can be its own function or inline. Above, I use enumerate, which allows you to iterate over both the index and the value.

This, to me, would usually indicate a graphics driver problem. It's hard for me to diagnose without a bunch more information.

Sorry, but that doesn't count as Linux help.

BTW do you actually work on Hurd?

Removed by mod

lwn.net is the best resource if you can't read lkml, which is usually very technical.

A more stable (i.e. older) kernel may or may not help with any crashes. If there is a clear kernel panic (it switches to a black screen with white text and tells you it's a kernel panic), it might. A more frequent cause of crashing is graphics drivers: nouveau, the free NVIDIA driver, is notoriously buggy. These will manifest by a sudden and complete "freeze", where the last frame is displayed on screen but the system is otherwise unresponsive.

If you have an NVIDIA card, switching to NVIDIA's proprietary driver will probably be much more stable, at the cost of software freedom.

For your crash, check your journal, it should offer clues as to why the crash is happening.

Yep! I'm also entirely self-taught, no degree.

The first thing to note is that almost all certificates are useless. There are a few that are respected, like the Red Hat certificates (e.g. RHCSA) and Cisco (for networking), but most ops and all programming certificates (as far as I know) aren't a huge deal.

The rest of this advice will be *nix specific, I don't use Windows or know anything about administrating it.

If you're really new, the first thing to do is to try and figure out how the system you're running right now works. If you're looking to be a *nix admin, that means running it and using it regularly. If you don't want to use it as your desktop, that's fine, just dedicate an old computer as a server. Install a distro on it. Install three. Get used to using SSH, to your shell (you can use any shell you'd like, but try to be fluent in Bourne, it's by far the most common so it behooves you to be able to read it). Start digging into how to do common things with command line utilities. What processes are running (ps)? How do I stop one? What's the filesystem layout? If I install a package, how does that work? What is the package format, how might I build one? What's my init (probably systemd) and how does that function? What's the boot process like? What does the kernel do?

You don't have to understand this all at once, just pick something you're curious about and pursue it until you understand it from a high level. A good test is if you're able to point to a component and describe what is responsible for it, what piece of software, or process running on the system.

Once you understand how things work from a high level, pick a service or technology you think sounds cool and install it. Configure it. Network with it. You can play with containers using LXC or Docker, or install an SQL database and write a toy program to interface with it. Try out LVM, LUKS. Try different filesystems. Get used to configuring services, almost all of them will use a plain text configuration file.

Spin up VMs, or containers. Play with configuration management, be able to press a button and have four VMs come up from scratch and be configured with different roles: a web server, a database, a backend, and a NAS (you do not have to write the backend service, fill out the website, or populate the database, just have them configured to talk to one another).

If, at this point, you don't know what to pursue, look up some job listings and pick technologies off of the requirements list and install and configure them. This will get to be pretty routine. You can't do this with everything (if they require you to have maintained a fleet of hundreds of servers in AWS, you obviously cannot just do that), but you can for a lot.

Acquire a drive for automating things. If you do something more than three times, write a script. You'll find that, with the right tool, almost everything in *nix is interfaceable with via shell script.

For the modern world, grumpy sysadmins who manage everything via a bunch of bespoke scripts only they know how to use are singular points of failure, and that's looked down upon. You can still be grumpy, but you'll want to really learn and understand git, and how to write code that others can read and extend. Companies are moving away from individualised servers that each have to be specially configured to a pool of resources (computers, VMs, containers) that are utilised automatically, or somewhat automatically by a C/M service backed by a backed up, version controlled repository. Configuration becomes code.

If this is a lot, just remember to pursue one thing at a time. Going from "Oh, I wonder how networking works" to "I ran some commands to try and created a bridge and now the internet doesn't work but LAN does?" to "I spent four hours trying to fix this problem I created" is a great way to learn to do this stuff.