Things to learn about Linux

Julia Evans has this amazing list of things to learn about Linux.  I think, it doesn’t matter how new or experienced you are with the operating system, you’ll find a few points in this list that you either know nothing about or know very little.

Personally, I’ve been using and administrating Linux systems for almost two decades now, and my own knowledge of the things on that list is either very limited or not existing.  Sure, I know about pipes and signals, but even with basic things like permissions there are some tricky questions that I’m not sure I can get right on the first go.

Some of the topics mentioned are simple and straight-forward and will only need a few minutes or a couple of hours to get up to speed with.  Others – are huge areas which might take years, if not decades (like networking, for example).

I look forward to Julia’s drawings covering some of these.

 

Migrating to PHP 7

PHP 7.0.0 has been released for a year now.  I wasn’t in a rush to migrate to it, but with all the cool features and performance optimization, it’s definitely something I wanted to look into rather sooner than later.

It turns out that I’ve done my first PHP 7 migration a week ago, when I upgraded my laptop to Fedora 25.  Yup, that’s right.  It’s a bit embarrassing, but I have been developing on PHP 7 for a week without even noticing it.

$ php --version
PHP 7.0.13 (cli) (built: Nov 9 2016 07:29:28) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Xdebug v2.4.1, Copyright (c) 2002-2016, by Derick Rethans

I think that was due to a few things:

  • It’s been quite a busy week, so my attention was all over the place.
  • PHP 7 backward compatibility is pretty awesome.  There are only a few things that need fixing in the older code bases, but if you haven’t been living under a rock for the last few years, you probably have nothing to change or worry about.
  • Most of the code I’m working on runs through TravisCI builds, which are executed on both PHP 5.6 and PHP 7.  Since we had this for a while now, most, if not all, of our code is PHP 7 compatible.

The absolute lack of any issues for the last week, related to this upgrade, is encouraging.  Now I will probably try to upgrade our servers sooner than later.

With that, I’ll go back to the wonderful and exciting world of PHP, leaving you to decide whether I’m very serious or very sarcastic…

 

Amazon Lightsail – virtual private servers made easy

Amazon announced a new service – Amazon Lightsail – virtual private servers made easy, starting at $5 per month.

pricing

This is basically a much simplified setup of a few of their services, such as Amazon EC2, Amazon EIP, Amazon AIM, Amazon EBS, Amazon Route 53, and a few others.  For those, who don’t want to figure out all the intricacies of the infrastructure setup, just pick a VPC, click a few buttons and be ready to go, whether you want a plain operating system, or an application (like WordPress) already installed.

It’s an interesting move into the lower level web and VPS hosting.  I don’t think all the hosting companies will survive this, but for those that will do, the changes are coming, I think.

Julia’s Drawings on Programming

Julia Evans, who blogs about her programming endeavors, now also draws simple, note-like sketches on a variety of the computer and programming related subjects.  Those are great as kick memory refreshers or reminders for “I wanted to learn more about that” kind of things.  Here’s her take on pipes, for example:

pipes

Worth an RSS subscription!

EPEL : the effort behind the scenes

Catching up with recent news, I came across this blog post by Stephen John Smoogen in Fedora People, where he explains the reason for the recent disappearance of the Puppet package from the Extra Packages for Enterprise Linux (EPEL 6) repository:

This week various people using EPEL on RHEL and CentOS 6 have found that the puppet package is no longer provided by EPEL. The reason for this is due to the way EPEL packages are built and kept inside the repository. A package needs a sponsor so that we can hopefully get bug fixes and security updates to it. In the case of puppet this package is sponsored by the user kanarip. However, most packages aren’t whole pieces, they rely on other software.. in this case the package puppet relies on a lot of different ruby gems of which one of them was called ruby-shadow. This package was orphaned 30 weeks ago and while it did have other people watching it, none of them took over the package.

[…]

Last week a large cleanup was done to clean out orphaned packages from EPEL which removed ruby-shadow. Once that was removed, then all of the other packages depending on ruby-shadow were also removed. Today various people reinstalling systems found puppet wasn’t around and came onto #epel to ask.. which seems to have gotten the packages responsored and hopefully they will be back in the EPEL release in a day or so.

This problem has been happening a lot lately. I think it shows quite a few problems with how EPEL is set up and managed. For this, I take responsibility as I said I would try to clean it up after FOSDEM 2016 and it is still happening.

Unpleasant annoyance that shouldn’t have happened, right?  Well, yes, maybe.

Software is a complex matter, whether you are designing, developing, testing, or distributing it.  So things do go wrong sometimes.  And that was something I wanted to focus on for a second.

Forget the actual designing, developing, testing and documenting the software.  Forget all the infrastructure behind such a vital part of the Linux ecosystem as EPEL.  Just think of this single issue for a moment.  Once again:

A package needs a sponsor so that we can hopefully get bug fixes and security updates to it.

So what, I hear you say.  Well, let’s take a closer look.  EPEL provides packages for multiple versions of the distribution, hardware platforms and so on.  Let’s just look at the EPEL 6 for x86_64 (to keep things simple).  That looks like a lot of packages, doesn’t it?.  How many? At the time of this writing, from a random mirror that I got:

wget -q -O - http://download.fedoraproject.org/pub/epel/6/x86_64/ | grep -c 'unknown.gif'
12129

Yup. That’s 12,129 packages!  And each one of those has at least one developer behind it, to sponsor.  Some of those amazing people obviously maintain more than one package. Some packages are maintained by multiple people.  All of them are working hard behind the scenes for you and me to have an easy and stable access to a whole lot of software.  Here is a quote from the FAQ which is smoked and marinated in all that effort:

Software packages in EPEL are maintained on a voluntary basis. If you to want ensure that the packages you want remain available, get involved directly in the EPEL effort. More experienced maintainers help review your packages and you learn about packaging. If you can, get your packaging role included as part of your job description; EPEL has written a generic description that you can use as the basis for adding to a job description.

We do our best to make this a healthy project with many contributors who take care of the packages in the repository, and the repository as a whole, for all releases until RHEL closes support for the distribution version the packages were built for. That is ten years after release (currently) — a long time frame, and we know a lot can happen in ten years. Your participation is vital for the success of this project.

I don’t know about you, but for me, this is absolutely mind-blowing.  So I just wanted to take this opportunity to say thank you to all the brilliant people behind the scenes, who are often invisible, yet indispensable for the continuous success of Open Source software in general, and Linux in particular.

You guys rock!