Hacker News Reader

utborinon Node.example.com Is an IP Address

Because it’s 16 bytes, and in Python 2 strings were just bytes, so any 16-byte string could be interpreted as an IPv6 address.

Doh.

utborinon Re: Integrating "safe" languages into OpenBSD? (2017)

In a thread about OpenBSD,

> Developers in particular don't generally care about security

Thanks, now I have to clean a mouthful of coffee off my screen!

utborinon Fibery – yet another collaboration tool

“We have miserably spent 3 years of our lives and are still ashamed of the result.”

This should come with a trigger warning.

utborinon PEP 594 – Removing dead batteries from Python's standard library

I was once a fervent devotee of semver. It's so predictable! It's structured! There's a system! Everyone loves a system, especially engineers.

I've since become disillusioned.

The problem with semver, in my experience, is that it's impossible to predict whether a change will actually break someone else's code. Of course there are certain classes of change that are more likely to cause problems for other people. Changing a function signature, or deleting a function outright, is obviously a breaking change.

But the line between breaking and non-breaking isn't a bright one. Move away from the obvious examples and things start to get murky. Even the humble bugfix can be problematic. What if a client application unwittingly relies on the buggy behavior? Now that fix is breaking for them. Is that a contrived concern? Maybe—though anyone who has written an emulator can attest that this a real problem.

What about a non-breaking feature addition? Let's say the new feature requires some extra branches in a function, but doesn't change the function's interface or behavior for people who don't use the feature. Fine, non-breaking. Now say these branches alter the function's performance, and a client application's batch job that used to run in under an hour now takes four hours. It does run, so it's not "broken," but four hours is an unacceptable runtime to the users. Is that still a non-breaking change?

What these examples demonstrate to me is that semver's breaking/non-breaking change concept is incoherent. It conceives of changes as universally breaking or non-breaking, out of context, but a change can only be breaking or non-breaking in the context of a specific client application. Even the seemingly obvious example of deleting a function is non-breaking for applications that don't use the function!

I think the way we release software reflects that we know this deep down, even if we don't admit it. Imagine how you might handle upgrading a library in an application you've written. The new library is a bugfix release. Do you upgrade the library, push it to production at 100%, and gallop off to lunch without so much as a glance over your shoulder? My guess is no. Personally I'd be running my test suite, reading the library's change log, making a gradual release, and keeping a close watch on instrumentation during and after.

The interactions between software systems are simply too complex, too nuanced, too specific to the particular applications. We put all these safeguards in place and do things cautiously because we've been burnt too many times. And we've learned that in actual fact, the line between breaking and non-breaking doesn't exist.

utborinon Death by PowerPoint: The slide that killed seven people

A very similar phenomenon happens in aviation—we call it complacency. Thousands of successful takeoffs in a row make it hard sometimes to remember that each one is a completely independent event.

The way I fight it is by explicitly reminding myself that just because something worked yesterday, that doesn't mean I can skip a step today or let my guard down at any point.

It really does take deliberate thought though. Funny how the brain works.

(The upside is that every successful takeoff becomes a delightful surprise!)

utborinon The Colgan Air disaster was a milestone in aviation safety

One of the biggest changes that came out of the Colgan crash is the so-called "1500 hour rule." Before Colgan, only the captain needed to have an airline transport pilot (ATP) certificate, the highest level of pilot certification. First officers (copilots) could fly with a commercial pilot certificate, a lower grade of license. Now, both pilots are required to hold ATP certificates.

ATP applicants need to have 1500 hours of flight experience—hence "1500 hour rule"—though there are exceptions if you've attended specific approved aeronautical schools or have military experience. Commercial applicants need only 250 hours. (Here too there are exceptions for certain training programs.) The standards on the flight tests are tighter for ATPs and the written exams are worlds apart.

As an instructor I can tell you the difference between a 250-hour pilot and a 1500-hour pilot can be enormous. Not always—some pilots have 1500 hours, and others have the same hour, 1500 times in a row—but there can be a huge difference.

This rule has been controversial though, not least of all because both pilots in the Colgan crash already had more than 1500 hours. And the FAA made so many changes after Colgan that it's been hard to tell which of those changes actually made the difference, and which, if any, were simply no-ops. Critics of the rule have especially focused on how many flight tests the Colgan captain failed, and how the response by the pilots to an aerodynamic stall was completely backwards. Aerodynamic stalls are something you learn in your first ten hours of training as a private pilot and drill constantly throughout your career, so to get that wrong at the air carrier level speaks to an incredible failure in training and evaluation.

utborinon 38% of bugs at Airbnb could have been prevented by using types

To me the biggest benefit of static types, type hints, annotations, etc. is their documentation value. I don't have a particularly strong opinion on the issue of static typing generally, but if you don't use types, you damn well better document what your functions expect to receive and what they produce.

It is so frustrating to jump into a codebase and have to read every single line to figure out what the inputs and outputs are. Think about how much time is wasted. It's like an anti-multiplier. One engineer decides they don't want to take a few minutes to annotate types or write a comment, and now every other engineer on the team has to waste time figuring out what's happening. It makes me want to scream.

utborinon B612 is a highly legible open source font to be used on aircraft cockpit screens

Touch screens installed in the instrument panel are very hard to use in even light-to-moderate turbulence. Have someone shake your phone around while you try to dial a number and you’ll have some idea of the difficulty. Knobs, and to a lesser extent physical buttons, give you something to hold onto. It may not sound like much of a difference but in my experience it’s much, much less error-prone to have hardware inputs when the aircraft is getting bounced around.

utborinon Ask HN: What's the most useful skill you ever learned?

Active listening. I'm amazed at how much better discussions go when this simple tool is used. Conflicts big and small melt away. Understanding, trust, and confidence are built. And even if not everyone agrees at the end, they at least feel heard, which is such an overlooked and underrated need.

utborinon Theranos, CEO Holmes, and Former President Balwani Charged with Fraud

> if you want to lie about some drone-based burrito delivery service

I wouldn't suggest lying about anything in the aviation sector either.

utborinon Living cells are very fast and crowded places (2012)

I am suddenly very uncomfortable, imagining myself as a roiling blob of goo.

utborinon Go 1.8 Release Candidate 1 is released

"For those who object that dot files serve a purpose, I don't dispute that but counter that it's the files that serve the purpose, not the convention for their names."

Oh, that's rich. This from the guy who designed a language where the case of a symbol's name determines the symbol's visibility.

utborinon The sad truth about depressive realism (2006) [pdf]

Can't understand why you're getting downvoted. My experience with depression is like yours. It's easy to romanticize mild depression. It's impossible to romanticize serious depression: an utter inability to feel, which paradoxically results in a sucking black hole of numb despair; not being able to get out of bed, never mind go to work, talk to friends, or engage with the world in any meaningful way; and ultimately suicide. Depression is not "sadness." It's not stoicism. It's a complete disconnection from reality with zero upside.