Tag: Linux

What have you done for me lately? (Dec 2017)

Jeroen

Don’t worry! This is not yet another “I haven’t blogged because…” post. It’s similar though: it’s to aggregate all the cool material I’ve been producing lately instead of writing on my personal blog!

Without further ado, here’s the goodies from the past:

Oh yeah, there’s also some stuff going on in the present:

Finally, here’s some cool stuff I might possibly do in the near future:

  • I’ve worked several months in a Java/Maven/Spring project, which lures me to write about the differences between Java and C#. No promises though!
  • 2018-01-xx: excited to start on a project that uses ClojureScript, hurray for opportunities to learn stuff! Might even write about it, here or on Infi’s blog.
  • 2018-xx-xx: blog post about Top 100 Games is in progress, though no promises here!
  • 2018-xx-xx: a side project that gets sidelined a lot, I still intend to finish EmpGrid some time.

Several things on these lists I want to blog about, but I’m not ready to commit to anything yet. Stay tuned!

LPIC-1 Exam 101 Study Plan

Jeroen

I’ve worked almost exclusively with Windows machines for the past years. However, this is changing rapidly (by circumstance, mostly) at the moment. So the time was never better to start a deep dive into Linux.

As you can see from my past Study Plans, I’m a big fan of “breadth-first” learning. I’ll go into a focused, meticulous, relentless grind starting at the very beginning. I plan to do the same for my Linux studies.

Certification Downsides

I will mention two major problems with certifications though:

  1. The certificates are near to worthless.
    Cheating your way through is commonplace, especially at companies that care only about being able to charge more for an employee because they’re certified. The only “worth” of a certificate lies in the fact that it reminds you that you’ve passed it fair and square.
  2. They tend to test a lot of silly or unimportant knowledge.
    Experts will tell you that many things you need to know to pass an exam are things they will in reality actually have to look up. Knowing whether method so and so returns an INT or BIGINT is useless, in real scenarios you’ll have an IDE or documentation to tell you this.

But for me striving to pass an exam is worth it nonetheless. Following exam objectives closely gives me confidence that I’ve got a solid basis, and frees me of having to spend any mental-cpu-time on monitoring that. I want to cover as close to 100% of the important topics as possible, and I guess covering 130% worth of material is one way of doing that.

Here’s a visualization of what I mean:

Venn diagram of Study Plan Coverage
Venn diagram of Study Plan Coverage

The blue area covers the green area for the most part, and it takes zero time to use it as a study guide. The red area is a plan I would probably create myself composing it from various resources. But creating it would cost me many hours, and is more likely to leave serious gaps.

So I’ve decided that going with exam objectives as a guide is a sane choice for me.

The Actual Plan

So how about the actual plan? Isn’t that basically the objectives from the website then? Well: yes and no. I also like to publicly share my plan, for two reasons:

  1. The main reason: it gives me confidence I’ve got a solid plan.
  2. Secondary reason: others might find it useful.

In addition, as a side effect, I guess it motivates me: feeling that “others” are watching my progress makes me want to complete everything. Regardless of whether there are such “others”.

This time around I tried something different from the previous Study Guides. I’ve used Trello to catch the study plan. You can check out the public board yourself. Here’s a screenshot:

LPIC-1 101 Study Guide Trello Board
LPIC-1 101 Study Guide Trello Board

Personalizing The Plan

Finally, you can easily copy this board and use it as a starting point for your own studies. This is quite easy to do:

Copy Trello Board
Copy Trello Board

It’s exactly what I have done, and you can follow my progress on Trello.

And now that I’ve told you about this, dear reader, I will have to complete my studies…

Learning to Linux: the Road to Becoming a Power User

Jeroen

Let’s first set the scene: I’m participating in an Infi study group and would have to present to colleagues about “WTF is Linux?”. Interestingly, I am a total Linux beginner, and they were ranging from intermediate to advanced skill levels. Joy!

So, what’s on the to-do list? Three things:

  1. Understand history and context of Linux;
  2. Get to know what you don’t know yet;
  3. Learn what the tools to learn more are;

Basically, I’m looking for all the things I need to get started and to keep going. Note that all this is aimed at folks that are at least to some degree a power user.

History and Context

First there was Unix, which was great, but it was closed source and not very portable. So Richard Stallman set to create a clone: GNU. However, the kernel “GNU Hurd” didn’t work out so well at the time. So Linus Torvalds wrote the Linux kernel in the 1990s, and together they now form the Operating System “GNU/Linux”, often referred to as just “Linux”. History has by now shown that GNU/Linux was far more popular than GNU/Hurd.

Before we dive into Linux itself, let’s consider its place amongst other Unix-like OSes. There are both open source ones such as Minix and FreeBSD, and closed source ones like Solaris. All of them are fully or partially compatible with “POSIX“: a standard for OSes. You can get the full picture at Wikipedia, but here’s a simpler version:

Unix-like OSes overview

Zoom in on the green “GNU/Linux” box, there turn out to be very many Distros. A distro being the Linux kernel, GNU tools, a package management system, and possibly a window system and desktop manager. Again, there’s a full picture at Wikipedia, but I made a more condensed overview:

Linux Distros Overview

The top ten distros for 2016 according to DistroWatch are as follows:

Rank Distro Package Manager Default Desktop(s) Comments
1. Mint dpkg Cinnamon, MATE, Xfce, KDE community-driven spinoff from Ubuntu with a lot of out-of-the-box multimedia stuff
2. Debian dpkg Gnome reliable Linux distro that can be used plain, but is also the ancestor for many other distributions
3. Ubuntu dpkg Unity (moving to Gnome 3) beginner-friendly spinoff from Debian, both for desktop and server environments
4. openSUSE rpm None, Gnome, KDE community program sponsored by SUSE, to promote use of Linux everywhere
5. Manjaro pacman XFCE, KDE, Gnome power and flexibility of Arch, but with a friendly installer and some more GUI stuff added
6. Fedora rpm Gnome latest and greatest features that will also go into Red Hat Enterprise Linux
7. Zorin dpkg Gnome 3 spinoff from Ubuntu for newcomers accustomed to the Windows GUI
8. elementary dpkg Pantheon spinoff from Ubuntu with the look and feel from Mac OSX with a few custom apps
9. CentOS rpm None, Gnome, KDE basically Red Hat Enterprise Linux without the enterprise license and support fees
10. Arch pacman CLI very minimalistic Linux distro, requiring the user to take control of the OS

There is also a pretty good Youtube video that gives some context about this same list.

Oh, and obviously I also have to do an honorable mention for the weirder, more “clickbaity” Linux distros: Satanic Ubuntu, Christian Ubuntu, Damn Vulnerable Linux, LinuxBBQ, Slackintosh, and Stresslinux. For the most part I have no clue what they do (if anything at all), I’ll leave that as an exercise to the reader.

What to Know

First thing to do when getting started with a new technology is finding out how much you don’t know yet. Thinking about the Dunning-Kruger effect…

Dunning-Kruger effect

… I would like to start at the Valley of Despair right away. And I’d like a clear path of that slope ahead of me. Please.

Now obviously you can’t start from zero; even reaching the Valley requires some knowledge. So investing some generic startup time seems good. Here’s a few suggestions:

But where to go from there? What is there to know? Well, there’s a few obvious resources that serve as very natural check lists:

In addition, it seemed helpful to try to do one or two nontrivial in-depth tasks in a VM, and see what you encounter. For example setting up a LAMP stack to host WordPress in a VM, or cloning a cool project and getting all dependencies (like Java, ugh!) up and running.

At the end of my research, and with help of my study-buddies, I conclude these are the few essential skills that I’m missing to be productive with Linux as a developer or sysadmin:

  1. Command Line. Without solid knowledge here you’ll feel lost for any nontrivial task in Linux. Some “introduction to Linux” articles tell you it’s not really needed (depending on the distro you choose), but I disagree, and think you’d get frustrated unless you learn to use it.
  2. SSH. Related to the Command Line, knowing how secure shell works is essential to managing a remote Linux instance (e.g. a VM in the cloud). This includes knowledge on managing SSH keys.
  3. Nano or Vim or similar. Also related to the Command Line. Often you’ll have to edit a config file from the command line, and being able to do that confidently is quite helpful.
  4. File System Hierarchy and Permissions. Knowing where to find stuff (and who has access to it) is essential to be productive. On a specific note, it seems important to know where things will be logged (e.g. where does a package install or server software keep its logs).
  5. Package Management and Installing Software (and troubleshooting that when it goes awry). Most interesting tasks on Linux require installation of libraries and software, and quite often this can go awry. You need to learn how to debug this.

My advice, at least to myself, is to sit down and carefully master these first. At least to some degree. Only then will other tasks on Linux (e.g. managing an NGINX server) not be a frustrating job anymore.

Learn to Learn

So how do you most efficiently climb this learning curve? Discoverability of essential info on Linux can be a bit of a problem. But here’s a shortlist we came up with:

  • man can be used with any other command as an argument, and it will explain all about it
  • info is GNU’s answer to man, intended to be more fully-featured (hyperlinks and such) and comprehensive
  • The “bropages” is like man but more succinct and example-based
  • locate, find, and which are commands for finding stuff on the file system
  • aptitude in Debian distros, or a similar tool for your set of distros, to help understand the package system
  • unix.stackexchange.com can be a great generic resource for Linux (and other *nix OSes)
  • https://askubuntu.com/ is quite a vibrant community should you choose to use that distro
  • LPIC (or similar) exam objectives can be a great study guide
  • read shell scripts before executing to learn
  • and as a final trick, you could do git init in a certain folder (e.g. /var/log) and use diffs to check how things change following your actions

However, perhaps unsurprisingly, the most common piece of advice when asking experts “How to learn?” is…. practice. Practice, a lot!

PS. This was cross-posted to Infi’s blog.

Beginnersplaining Linux to Experts

Jeroen

Working at Infi I’m involved in several study groups, one of which is about Linux. When we started the group it turned out we had six people and six different levels of experience. And I was the absolute newbie of the group.

We decided to set up a program divided in weeks, with one subject for each week, and a “Lead” for each subject. The Lead would research a lot about his or her main topic, and ask the rest of the group to merely do some light recommended reading. This is to get everyone at a base intro level for each topic. Every week we’ll have a session where the Lead would talk about his or her research, along with some open discussion.

Obviously, the first topic would be a “Linux Basics” session. It also seemed logical that the newbie (me!) would pick up this topic, because I’d have most to gain from researching the hell out of it.

Seems legit, right!? Except I now realize this means I’ll be presenting on Linux Basics to five colleagues that know a lot more about this topic than I do. Oh, and because it’s the first week’s topic I have only a week to prepare. Whelp!

I’ll just have to focus on learning a lot from all this. No progress without failure, and no progress without taking risk, I guess.

Foot Note: The Programme

We composed the Study Plan based on whatever the group members individually found interesting enough to research. This means it’s a bit of a weird assembly, but interesting nonetheless:

  • Week 1: WTF is Linux?
  • Week 2: Command Line
  • Week 3: File Systems
  • Week 4: Screen
  • Week 5: Web Servers (Apache & NGINX)
  • Week 6: Ansible
  • Week 7: .NET Core
  • Week 8: Logging & Smart Monitoring
  • Week 9: KVM, Virtualization, Containers

A New Hope

Jeroen

Did I mention before that I write here to collect my thoughts and as writing practice? Well, in any case, after my previous monster post, and given that it’s the start of a new year, I figured I’d do a “New Beginnings” post. Then the sci-fi addict in me awoke and typed “A New Hope“, even though I’m a Trekkie at heart. But I digress.

I wanted to summarize which technologies and experiments I’m most interested in pursuing next. Let me try to list them in order of current preference.

1. Elasticsearch …. and Nest?

Elastic as a (primary?) data store intrigues me. It feels like a second chance for Lucene towards me (experimenting with Solr didn’t “click” for me). There recently was a major version released so it seems like a great time to start investigating. I’m hesitant about Nest though, which you’d kind-of have to use if you want to access Elastic with .NET: during my first few experiments I felt like I was “wrestling” the API.

2. Gulp, or: More Gulp!

I’ve done quite some work with Gulp recently, and it was a very (and surprisingly) fun experience! In the past, most devops tasks felt like chores to me, but not so much with this Gulp. So this point would actually be “More Gulp” (as I’ve done quite a bit of it recently already), but I still have quite a list of things I want to try out, like for instance setting up JSCS.

3. Node

Yes, yes, I know: I’d be a hipster-after-the-fact if I’d start on Node now. Even so, I enjoy writing Javascript, and Node would be a way to do even more of it in my pet projects. Not sure how I would be utilizing Node yet: with ExpressJS, for custom (Gulp) packages, general scripting, or perhaps something like project Euler.

4. Linux

This one’s been on my mind for a while now: perhaps I’ve been stuck too much in my Windows-comfort-zone. It would be good to shape up my base knowledge of Linux as a development environment.

5. Grunt

Why yes, in addition to Gulp there’s also Grunt on this list. Gotta know what’s on the other side of the fence to be able to compare, right?

I’m placing a short but distinct separation here, because these are currently mostly “in reserve” kind of ideas.

6. Couchbase

Working a little with this at work as well. There’s a few things I’d be excited about to try at home, mostly features from version 3 and 4. Would need a “subject” though to make it interesting…

7. Study three-way-diff-tools

For some reason I never got my mind wrapped around these tools. And that’s frustrating. I should just spend a few hours trying to understand the details of these tools… I guess.

8. Raspberry / something IoTish

This one’s on the list because it nags me that I don’t see what all the rage with IoT is (or is it “was”?) about, and for that reason I feel like I have to “make Slackbot call a webhook that calls my webserver that calls my Raspberry which turns on a LED strip and autopilots a drone around in my room”. Or something.

9. Android app

I’m curious how the Android-dev-experience compares to my short experiments from around 2011. This would also allow me to revisit Java. But on a whole I feel I’d have to invest a lot of time or not do this one at all.

10. Closure Compiler

It’s on the list because I find the idea of it intrinsically interesting. It’s low on the list because I’m not sure if I work on things personally or professionally at the moment where this would be worth the investment.

Wow, that worked like a charm! Apologies for the stream-of-consciousness post, but now I do know what to do next! And I’m not even going back to adjust the (order of the) list accordingly, I’m just gonna leave you all hanging out there, guessing at what’s next…

Shredder

Jeroen
Shredder, nemesis of the TMNT!
Shredder, nemesis of the TMNT!

Trading my three year old PC for a bottle of whisky (or is it whiskey?) to a friend seems like a great deal. With several work-related files left on my computer, it felt like a great opportunity to try out a shredding tool. So I figured I’d just Google for the popular choice and try it out.

Then I got submerged in a whirlpool of information. Some folks linked to “non geek perspectives”, for example this article on 4 file shredder tools. Others gave walls of text on the technical details. I was in fact hoping to find some article on the Dutch hardware.info site on this topic. In the end the Stack Exchange site for “power users” gave me the most info through a dedicated file-shredding-tag.

And there, finally: a great list of shredding options! Options all around: bootable CDs, hidden Windows 7 tools, as well as a  great post on Scott Hanselman’s blog. For some reason one of the answers with almost the least amount of answers caught my attention.

So I downloaded a bootable ISO of Ubuntu and fired it up. First I tried the “basic” suggestion:

The terminal screen just sat there, with a blinking caret. Apparently I’d entered a staring contest. After some time I decided to hit the enter key a few times in the console: the caret moved. After a minute of pondering I tried CTRL+C: and the operation got cancelled. I’d lost the staring competition, that’s for sure.

Now, this staring contest had taken about one hour. So I decided to try the second suggestion:

No dice. Utterly confising console error messages. Since I’m mot quite a Linux guru like these guys, I did some more searching around. Finally I found some more detailed instructions on hdparm. First I had to unfreeze my drive, and I had to set a password (though I don’t quite grasp why). Then the moment of truth…

Ever since I’ve been in yet another staring contest with Ubuntu. Only this time I’m gonna win, or die trying!

Update: after over two hours the staring contest is over… and won! The console returns to normal. At first, it seems Ubuntu can still browse the drives. But, after a reboot, there is not a single file, folder or partition to be found anymore!