Hacker News Reader

Comment by BitwiseFool | Hacker News Reader

Seems like a dumb question, but I find that even BLATANTLY_OBVIOUS_WARNINGS are so much more effective if there is a 'why' that explains the danger.

View on HN

One of my favorites is the warning you get if you enter the shell of an Oracle ZFS storage appliance:

  +-----------------------------------------------------------------------------+
  |  You are entering the operating system shell.  By confirming this action in |
  |  the appliance shell you have agreed that THIS ACTION MAY VOID ANY SUPPORT  |
  |  AGREEMENT.  If you do not agree to this -- or do not otherwise understand  |
  |  what you are doing -- you should type "exit" at the shell prompt.  EVERY   |
  |  COMMAND THAT YOU EXECUTE HERE IS AUDITED, and support personnel may use    |
  |  this audit trail to substantiate invalidating your support contract.  The  |
  |  operating system shell is NOT a supported mechanism for managing this      |
  |  appliance, and COMMANDS EXECUTED HERE MAY DO IRREPARABLE HARM.             |
  |                                                                             |
  |  NOTHING SHOULD BE ATTEMPTED HERE BY UNTRAINED SUPPORT PERSONNEL UNDER ANY  |
  |  CIRCUMSTANCES.  This appliance is a non-traditional operating system       |
  |  environment, and expertise in a traditional operating system environment   |
  |  in NO WAY constitutes training for supporting this appliance.  THOSE WITH  |
  |  EXPERTISE IN OTHER SYSTEMS -- HOWEVER SUPERFICIALLY SIMILAR -- ARE MORE    |
  |  LIKELY TO MISTAKENLY EXECUTE OPERATIONS HERE THAT WILL DO IRREPARABLE      |
  |  HARM.  Unless you have been explicitly trained on supporting this          |
  |  appliance via the operating system shell, you should immediately return    |
  |  to the appliance shell.                                                    |
  |                                                                             |
  |  Type "exit" now to return to the appliance shell.                          |
  +-----------------------------------------------------------------------------+

I like how it explicitly says "no, seriously, Mister Unix Wizard, we mean YOU."

This place is a message... and part of a system of messages... pay attention to it!

Sending this message was important to us. We considered ourselves to be a powerful culture.

This place is not a place of honor... no highly esteemed deed is commemorated here... nothing valued is here.

What is here was dangerous and repulsive to us. This message is a warning about danger.

The danger is in a particular location... it increases towards a center... the center of danger is here... of a particular size and shape, and below us.

The danger is still present, in your time, as it was in ours.

The danger is to the body, and it can kill.

The form of the danger is an emanation of energy.

The danger is unleashed only if you substantially disturb this place physically. This place is best shunned and left uninhabited.

I think there's a lot to learn from this message, even in your daily communication with people from other fields of exertise. It's very clear and communicates without any technical terms – if only all error/warning messages were a bit (!) like that.

For reference, the message parent quoted is a Long-time nuclear waste warning message:

https://en.wikipedia.org/wiki/Long-time_nuclear_waste_warnin...

I've seen commentary before that this messaging could actually backfire, if you imagine intrepid explorers seeing this message and thinking there must be some great ethereal power located inside, ready to be unleashed with the right set of rituals.

Only way this works is if the one reading it knows your culture was technologically advanced, for-real and not just in your own estimation, and has some appreciation of what that might mean.

Otherwise, "curse of the mummy? LOL, yeah, I'm sure that's a real thing. Must be something great buried here. Watch out for actual traps, but we're about to get rich, boys!"

> Only way this works is if the one reading it knows your culture was technologically advanced, for-real and not just in your own estimation, and has some appreciation of what that might mean.

This is pretty well guaranteed if they can read your message at all.

I alluded to European expeditions to Egypt for a reason :-)

Though maybe there's only a brief window of development in which a culture is both not superstitious enough to be scared by this, and also lacks the technology & knowledge to figure out what you actually mean and verify it themselves.

Europeans could read Egyptian inscriptions for two reasons:

- A descendant language had been preserved in the Coptic Bible.

- The Rosetta Stone provided a parallel text between Egyptian and Greek, and Greek was well understood.

But the ability to read Greek gave us more than just an understanding of what the Rosetta Stone said. The Greeks wrote a lot about Egypt, too.

That's part of the design consideration, and the reason for the emphasis on "no value." I mean, humans gonna human, but you can still try to communicate a difference between "this is dangerous because we booby-trapped our buried treasure" vs "we don't want this."

Right, but that could probably be explained away as “Hah, they couldn’t figure out how to strike a deal with the ethereal being, but we have the best mystic in the tribe with us!”

I’m not saying the experts did a bad job at all. This is probably about the best you could do to communicate with a culture of unknown technological complexity, far off into the future. I’m just saying, as good as it might be, this communication is likely still pretty imperfect :)

> Right, but that could probably be explained away as “Hah, they couldn’t figure out how to strike a deal with the ethereal being, but we have the best mystic in the tribe with us!”

In a way that is true. You could in principle use the radiation from nuclear waste to do useful work (like generate electricity), but our sages haven't figured out a way to do so in a way that makes economic sense to us. The waste could be useful to a different civilization with better technology or worse natural resources.

I wonder if fudging the truth and being less specific is actually better.

"A terrible sickness is contained underground. It kills all who come close. We have done our best to contain it so it does not kill you, our children. We have hidden it. It is very deep. You are safe if you do not dig."

The purpose is not to control people's behavior over the next several thousand years. The purpose is to behave ethically with respect to people over the next several thousand years.

like the Pah Wraith were Plutonium and the Fire Caves were Yuca Mountain.

I dunno, I TL;DR'd in the middle. Seems like it's dangerous maybe? Whatever, can't be that bad.

“You’ll soon be glowing with health!”

It's odd how surprisingly difficult it is to convince people to stay away or their skin might fall off.

Wow, that brings back memories! I wrote this message, and it was a direct result of some very bad experiences from some people who thought they knew what they were doing -- but in fact had no idea. I don't know how well this message worked, but it warms my heart to see it again; thank you!

Holy shit! THIS is why I come to HN.

I really really want an Oxide. Sadly it doesn't solve any problem we have, but ... man, so cool. Great work.

That feels like an additional sentence was added every time someone screwed up their machine and called support.

I forget where this was posted, but there was a multiline comment along the lines of

  "DO NOT ATTEMPT TO OPTIMIZE OR REFACTOR THIS CODE. 
  When you ignore this warning and fail, increment this tally mark: IIII"

http://bash.org/?947444

    //
    // Dear maintainer:
    //
    // Once you are done trying to 'optimize' this routine,
    // and have realized what a terrible mistake that was,
    // please increment the following counter as a warning
    // to the next guy:
    //
    // total_hours_wasted_here = 25
    //

Do we know what the current tally is?

Is the code still in use?

Likely from this SO answer: https://stackoverflow.com/a/482129

You know what they say. Regulations are written in blood.

Well, in aviation. Not so sure for software engineering.

https://en.m.wikipedia.org/wiki/Therac-25

A small fraction of software developers work on safety-critical software. Safety-critical software is (or at least should be) developed with quite different methodologies, as the cost/benefit assessment is very different regarding development speed against number and nature of defects.

If there are lessons written in blood for the development of safety-critical software, they haven't propagated to the wider field of software development.

(Disclaimer: I don't work on safety-critical software.)

NASA's guidelines are not written in blood, but certainly in lost spacecraft. The most famous is the Mars Climate Orbiter that was lost due to ground system and orbiter using different units of measurement, but that's not the only example [1]

1: https://www.csoonline.com/article/3404528/8-famous-software-...

> NASA's guidelines are not written in blood

I can think of at least three NASA missions that resulted in deaths: Apollo 1[1], and the Challenger[2] and Columbia[3] space shuttles.

[1] https://en.wikipedia.org/wiki/Apollo_1

[2] https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disas...

[3] https://en.wikipedia.org/wiki/Space_Shuttle_Columbia_disaste...

Only one of those particularly affected guidelines. After, anything that might end up in a pure oxygen atmosphere had to be non-inflammable, and very uncomfortable.

The 737 Max attempted pioneering work in this area.

What do you mean attempted? Boeing successfully slaughtered 346 people with their negligence.

And they didn't even get any new regulations written that I've seen. The hand wheels for the horizontal stabilizer trim became too hard for average pilots to physically operate if the aircraft is going too fast and out of trim far enough (even without being outside the safe operating envelope). There was no regulation limiting how much force the trim wheels can need while within the operating envelope. AFAIK, there's still no such regulation. So the "fixed" 737 Max models didn't change the hand wheels, meaning the physical backup in case of a trim runaway might not actually be usable. Yet they certified it without changes, because there's no regulation saying that the safety backup wheels have to be physically usable by average pilots in the event the primary powered system fails!

Are we living in the same world? Encryption, weed, appliances don't do their jobs in the name of efficiency?

Seems like half the time it's the blood of the lobbyist or spook who didn't realize how heavy that suitcase full of benjamins was and the other half of the time it's the blood of whoever got trampeled when the moral panic turned into a moral stampede.

Cheap quips like "regulations are written in blood" are just high brow ways of saying "because I said so".

As the top level commenter points out, these sorts of messages coming from untrustworthy entities who's best interest only aligns with yours in passing are not held in high regard unless they come with some sort of justification since the entities in question (be they oracle or the EPA) do not have the reputation for honesty that they can rely on. If there's really a hazard, communicate the hazard and don't lie about it. The vast majority of the regulation of which you speak is far closer to the "no user serviceable parts inside" end of the spectrum than the "warning, landmines" end and that is why it's not taken seriously.

>"no, seriously, Mister Unix Wizard, we mean YOU."

That makes sense as they're the folks who will get in trouble.

Rando person probably turns back at this point "nope this isn't what I wanted".

Guy who thinks he knows better is the one who keeps going and freaks out when it hits the fan.

I had to read that multiple times to prove to myself that the text didn't literall call out "Unix Wizards".

After 10+ years of doing qa on the ZFS appliance I completely ignored the warning and you could have slipped anything past me in the text.

Why include the shell then? Just curious.

It really should be applauded, you own this thing and can fully control it, but that means you can do things with it we can’t save you from and will refuse to even try.

No need for a “security” team to lock away access from you, a very stern warning will do.

Got it, thanks!

It's really for Oracle techs to use, I guess?

Dell Compellent has a similar thing. Theirs is hidden behind the super seekrit password "SuPpOrt"...

That's a very...secure password!

Debugging maybe?

When I worked support for networking equipment every device had potentially multiple shells or APIs hidden that allowed you to do stuff that really only the engineers who made the thing should do / direct someone to do it.

I often walked trustworthy customers through using them as they knew if they did it then it was on them.

Reasonable, someone gets to use it.

Most likely for support engineers working on "something went really wrong" cases to be able to provide you with debug commands that you should run, or for support engineers to be able to run such commands.

For Sun (later, Oracle) support staff to access remotely (with the customer's approval).

Apparently, you didn't read the message.

No I did, just not sophiscated to understand all of that. My basic understanding is that they put something in the piece of software that users should absolutely not touch, that's why I asked why it absolutely has be there.

That is, is there any chance that they can remove it from the hand of users without damaging the usability of that piece of software. The other commenters mentioned that support engineers may use it, so that answered my question.

  +-----------------------------------------------------------------------------+
  | You are entering the operating system shell. By confirming this action in   |
  | the appliance shell you have agreed that THIS ACTION MAY VOID ANY SUPPORT   |
  | AGREEMENT. If you do not agree to this -- or do not otherwise understand    |
  | what you are doing -- you should type "exit" at the shell prompt. EVERY     |
  | COMMAND THAT YOU EXECUTE HERE IS AUDITED, and support personnel may use     |
  | this audit trail to substantiate invalidating your support contract. The    |
  | operating system shell is NOT a supported mechanism for managing this       |
  | appliance, and COMMANDS EXECUTED HERE MAY DO IRREPARABLE HARM.              |
  |                                                                             |
  | NOTHING SHOULD BE ATTEMPTED HERE BY UNTRAINED SUPPORT PERSONNEL UNDER ANY   |
  | CIRCUMSTANCES. This appliance is a non-traditional operating system         |
  | environment, and expertise in a traditional operating system environment    |
  | in NO WAY constitutes training for supporting this appliance. THOSE WITH    |
  | EXPERTISE IN OTHER SYSTEMS -- HOWEVER SUPERFICIALLY SIMILAR -- ARE MORE     |
  | LIKELY TO MISTAKENLY EXECUTE OPERATIONS HERE THAT WILL DO IRREPARABLE       |
  | HARM. Unless you have been explicitly trained on supporting this            |
  | appliance via the operating system shell, you should immediately return     |
  | to the appliance shell.                                                     |
  |                                                                             |
  | Type "exit" now to return to the appliance shell.                           |
  +-----------------------------------------------------------------------------+

Cleaned up formatting

Thanks! I've ported that edit to the GP - it just requires adding two spaces to the start of each line (see https://news.ycombinator.com/formatdoc).

That is so arrogant (from oracle) it should be illegal.

Tell me you've never worked in support without telling me you've never worked in support.

In this case, the message in question was written at Sun -- by someone who would turn out to be one of Oracle's biggest critics.

I wonder who that might be! :)

EDIT: Ah, I see you claimed authorship in a comment below.

AH, now we see who cavorted inside the shell.

You would have added some expletives too if you had worked as a support engineer.

It depends. If you give a reason why, it opens up the door for people to argue about whether the "why" is a valid justification. It also can make people feel like the "why" does not apply to them.

"why" can be pretty nebulous too.

For a larger, widely used project, the question isn't "why" make something internal, but "why not". The safe default is to not semi-permanently commit every half baked bit of code to the public stable semvered API boundary to support for who knows how many years, but to only do so after careful consideration and justification.

To add this disclaimer to every single bit of internal code is to drown your codebase in a sea of redundant comments - none of which are specific to the code, or even the codebase, but are instead rehashing "why encapsulation?" 101. This will only train readers of your code to ignore the low-value low-signal comments, and they will then end up asking the same question anyways, and "read the comment that's right there!!!111oneoneone" will be a fustrating experience for everyone, although they might not be able to articulate why.

The real question I'm curious about here isn't "why are internal things internal" - but why this internal thing must technically be public. Does this predate ES6 symbols? Is there a plan to switch to those at some point in the future? Is there a tracking issue? Or does this need to be accessed from elsewhere in a manner that makes Symbols awkward to use? Where?

Here it seems "INTERNALS" is the "why". If it's not a public API then of course it could change or disappear without warning between releases (including minor releases).

Go handles this by not allowing 3rd party to import a package path with internal/ in it. Only the current module can

Ancient vanilla JS can accomplish similar by using wrapper functions.

    var React = (function(){
        var React = {};
        var __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED = {};
        ...code extending/using React etc...
        return React;
    })();
    // accessible:   React.whatever
    // inaccessible: __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED

However, there's always caveats where language level access controls don't let you quite express the access restriction you want. Perhaps you want to expose something to other official modules from the same constillation of libraries, for example (meaning you wouldn't be able to use Go's "internal"), without comitting to supporting the semver contract for any other arbitrary user of your API (meaning you might resort to similarly scary names.)

Private properties in JS classes are syntactic sugar that compile to variable definitions like this in the object's scope

iirc, react-dom (a separate package) needs to access that property as well, which is why it's exposed in the first place

Which is awful, because I've seen a number of FLOSS projects that have perfectly good reusable code in their internal/ subdirectories. And I mean code by no means unique or specific to those projects.

And whoever says something about instability or APIs being subject to change without notice - they're wrong because those are Go git repos and one can always pin to an old tag or even a commit SHA.

If something is unusable (too specific, too fragile, too flaky), no one would use that anyway. A warning is fine and even welcomed, but a block is a slap in the face.

Most sane languages have visibility modifiers. This link refers to Javascript so...

Go did that with casing, so you can tell visibility without lookup or needing to think. The internal/ is a package level restriction, so somewhat orthogonal in that they are for different levels

It's certainly not dumb. If you look at every large library, there are some forbidden internal symbols that are used in a lot of 3rd part projects. Many times those are more stable than the API, and often enough they get published as part of the API once a lot of people decide to depend on them.

It's maybe not dumb to use the forbidden internal symbols, but it's certainly dumb to go ask the folks who through naming and documentation have communicated almost comically loudly and explicitly that they don't want you using the symbols if it's cool if you use the symbols.

You would be surprised about how many times I've seen the internalVariableDoNotUse symbol to be exposed on the formal API of a library because everybody uses it already, it would be too much work to change it.

The "why" is that you will be fired, clearly :P

I suspect they'll soon have an issue where someone wanted to get fired but it didn't work...

Interesting point. In naming it this way, the maintainers have committed to firing anyone who uses it, as an implicit guarantee of the public-facing API.

Fortunately they're free to rename it in their next release.

Perhaps something snappy like __secret_internals_do_not_use_or_version_specific_retribution_will_follow_possibly_including_firing

I wouldn't be surprised if there is a FB-internal comment (or commit message) that was stripped in the open source repos

Reply on news.ycombinator.com