Technology

Things Every Hacker Once Knew

Eric Raymond goes over a few things every hacker once knew.

One fine day in January 2017 I was reminded of something I had half-noticed a few times over the previous decade. That is, younger hackers don’t know the bit structure of ASCII and the meaning of the odder control characters in it.

This is knowledge every fledgling hacker used to absorb through their pores. It’s nobody’s fault this changed; the obsolescence of hardware terminals and the near-obsolescence of the RS-232 protocol is what did it. Tools generate culture; sometimes, when a tool becomes obsolete, a bit of cultural commonality quietly evaporates. It can be difficult to notice that this has happened.

This document is a collection of facts about ASCII and related technologies, notably hardware terminals and RS-232 and modems. This is lore that was at one time near-universal and is no longer. It’s not likely to be directly useful today – until you trip over some piece of still-functioning technology where it’s relevant (like a GPS puck), or it makes sense of some old-fart war story. Even so, it’s good to know anyway, for cultural-literacy reasons.

The article goes over:

Hardware context
The strange afterlife of the outboard modem
36-bit machines and the persistence of octal
RS232 and its discontents
UUCP, the forgotten pre-Internet
Terminal confusion
ASCII
Key dates

Found via a couple of other interesting bits –
What we still use ASCII CR for today (on Unix) and
How Unix erases things when you type a backspace while entering text.

Defensive BASH Programming

If you write any Bash code that lasts more than a day, you should definitely read “Defensive BASH Programming” and follow the advice, if you haven’t already. It covers the following:

Immutable global variables
Everything is local
main()
Everything is a function
Debugging functions
Code clarity
Each line does just one thing
Printing usage
Command line arguments
Unit Testing

All that with code examples and explanation of importance.

Preparing for the PHPUnit 6 and PHP 7

If you woke up today and found that most of your PHP projects’ and libraries’ tests break and fail, I have news for you: you are doing something wrong. How do I know? Because I was doing something wrong too…

First of all, let me save you all the extra Googling. Your tests are failing, because a new major version of PHPUnit has been released – version 6.0.0. This version drops support for PHP 5 and, using the opportunity of the major version bump, gets rid of a bunch of stuff that was marked obsolete earlier.

But why does it fail, you ask. Well, because PHPUnit is included in pretty much every composer.json file out there. And the way it’s included is almost always is this:

"require-dev": {
"phpunit/phpunit": "*",
}

PHPUnit being a part of pretty much every composer.json file, is probably the reason why people want to be much more relaxed with the used version, than with any other component of the system. That’s usually good. Until it breaks, much like today with the release of the PHPUnit 6.

How can you fix the problem? Well, the quickest and the easiest solution is to update the composer.json with “^5.0” instead of “*”. This will prevent PHPUnit from upgrading until you are ready.

While you are doing it, check the other dependencies and make sure that none of them are using the asterisk either. Because, chances are, the exact same problem will happen later with those too.

The only difficult bit about this whole situation is the correlated drop for the PHP 5 support. Yes, sure, it has reached its end of life, but there are still a lot of projects and environments that require it, and will require it for a lonweg time.

As you are the master of your code and dependencies, other people are of their own. So you can’t really control when each of your dependencies will update the requirement for the PHPUnit 6, or any other tool that requires PHP 7.

On the bright side, major releases of PHP don’t happen that often, so this shouldn’t be the frequent problem.

PagerDuty Incident Response Documentation

PagerDuty shares their Incident Response Documentation:

This documentation covers parts of the PagerDuty Incident Response process. It is a cut-down version of our internal documentation, used at PagerDuty for any major incidents, and to prepare new employees for on-call responsibilities. It provides information not only on preparing for an incident, but also what to do during and after. It is intended to be used by on-call practitioners and those involved in an operational incident response process (or those wishing to enact a formal incident response process).

I think this is a goldmine for anybody involved with incident response teams, operations, monitoring, technical support, network centers, and other similar setups. Not only it covers the specific steps and expectations during different situations, but it also defines the culture, which the company is trying to built.

I wish I had this 15 years ago when I was involved in setting up the Network Operations Center (NOC). I will definitely use it in the near future, when we’ll be setting up the support department at work.

Dissecting an SSL certificate

Julia Evans does it again. If you ever wanted to understand SSL certificates, her post “Dissecting an SSL certificate” is for you. This part made me smile:

Picking the right settings for your SSL certificates and SSL configuration on your webserver is confusing. As far as I understand it there are about 3 billion settings. Here is an example of an SSL Labs result for mail.google.com. There is all this stuff like OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 on that page (for real, that is a real thing.). I’m happy there are tools like SSL Labs that help mortals make sense of all of it.