a) The manual was out of date the day it was published

b) The manual was written by a tech writer and sales reps

'nuff said.

Never ever trust a manual you have not written yourself, got lost, found again, buried in soft peat for three months and digested by the Beast of Traal.

Would that the smaller cousin of the Bugblatter beast or its larger cousin?

I can't check the guide its currently updating......

It is the Ravenous one.

You missed the "recycled as firelighters" stage.

"Who? Me?" is one of my favourite columns on El Reg, but the stories seem to have got a lot less dramatic recently. Time to take a break?

I have to agree. +1. Perhaps all the good stories have been told? They are relying on reader contributions for the stories*. However, this is really just part of the vanillaization (the opposite of vandalization?) of El Reg, now known as Reg.com.

*I know I don't see some user handles in the comments any longer. Have they gone AC? Doubtful, they probably aren't visiting Reg.com and this brain drain is affecting the quality of columns like Who? Me? and On Call.

I think the problem is that they are trying to fill two columns... "On Call" and "Who? Me?"... and it's getting a bit like terrestrial TV competing with Netflix, Prime, NowTV, Disney+, Discovery+... it's diluting the magic

Well, yes, but no... On Call is saving the day, Who? Me? is the other side of the coin.

If you want entertainment then this is the wrong place. The Register is about enlightenment . Who Me and On Call are lighthearted and not meant to feature wide-screen, technicolor horror for the benefit of hedonistic comentards.

No, El Reg was always about both. Or haven't you ever read BOFH, SFTW or Stob?

"the stories seem to have got a lot less dramatic recently."

Wait until you hear about the time I left a USB cable on my desk...

> the company got an important lesson in checking its documentation.

One that, if they are like every other company I have experienced, they continued to ignore.

After all, if you check (or test) something, that might turn up errors. Errors cause delays and they aren't in the release timetable.

As someone who ends up writing a lot of documentation you never put passwords in the documents, refer to a (hopefully) controlled system. There are two reasons for this, the first is when someone updates the passwords the documentation doesn’t need to be rewritten, the second is if you shouldn’t use it then you shouldn’t have access to the password.

The other problem is someone changing the process from what the document says and not updating the document, so the process is as good as useless.

As someone who has spent a large amount of time on call for various jobs I know that good documentation is invaluable especially when having to fix something at 3am when you have just been woken up….

...at 3am when you have just been woken up.

At that time you need simple words and large letters. Like written for a 6-year old during the day.

Topping it off with the text "DON'T PANIC" in soothing letters.

At 3am you ask the person who called you to put tje problem in writing which gives enough time for the laptop to boot up and the vpn to connect.

And your brain to start before having to do anything else

At 3am my brain's so low on caffeine that it entered a vegetative state. So, for it to start it needs strong tea in sizable quantity, which takes time to prepare - that's before I'd even be able to locate the laptop let alone its VPN connection. And that's why I better don't do on call.

When recently I was asked to submit some management and backup/restore documentation for a software we developed, when I submitted passwords in a separate KeePass file I was told that wasn't nice....

I remember an old colleague telling me a story (so it may be apocryphal) of a company who had a written procedure for a delicate task. It was the kind of task that only got done when things were going VERY pear shaped, and it had been about 3 years since the last time t had been needed.

My old colleague, then just a junior PFY, dutifully went and obtained the procedure from the guide, and started to follow the steps precisely, as he had been instructed to do. About 2/3 of the way through he went to visit his boss and asked who Dave ********* was? His boss looked at him funnily, and told him to stop being a troublemaker and get back to work. My colleague returned to his desk collected the guide, returned to his boss, and told him he was stuck on Step 24.

The Boss grumbled, scanned down the page, and upon reaching Step 24, proceeded to turn white as a sheet, and mouth something along the lines of "Oh Sh%t!". The Instruction read something along the lines of "For the Password to System X, please contact Dave *********."

Apparently, this Dave had left the company about 18 months before, and it had not been a happy breakup. So the chances of getting the password were Zero.

I dont remember, what my old colleague said happened, apart from a lot of wailing and gnashing of teeth, but he and the company learnt a valuable lesson. Never entrust sensitive information to a single person. And better yet, dont entrust it to a person at all, but use a safe (or for the modern case), a password locker.

Documentation that does not match reality is worse than lying, it's outright FRAUD.

Select "bulk import", select "Choose file"....

THERE

IS

NO

'CHOOSE FILE'

OPTION!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

One of these days I'm going to visit London, find the people responsible for our software and educate them with a two-by-four. There. Will. Be. Blood.

All went well, for a while. He got to page three of the procedure,

Hopefully the documentation wasn't in The Sun...

Well, it did almost go titsup at that point...

> Well, it did almost go titsup at that point...

Well played Sir -->

Hopefully the documentation wasn't in The Sun...

Well things did go TITSUP (Total Inability To Support User Passwords)

"Hopefully the documentation wasn't in The Sun..."

He might have made a right tit out of himself instead.

Better than being left behind

My first rule would be, don't give superuser access to anybody that doesn't understand the commands they are typing.

Yes, I know in theory, you can have a documented procedure and give the job to a simpleton who simply follows that procedure to the letter. I've worked in places where they do that.

I know people whose first response in any situation is to pull out the notes from a 2 day training course and follow the instructions they were given 5 years ago by a tutor who has probably never actually done it themselves. It's great for people who work in the kind of organisations where everybody needs to keep their head down and their arse covered at all times.

But things can go bad very quickly when something unexpected happens that doesn't match the documentation. IMHO It's better to employ somebody that actually understands the system inside and out and doesn't need to read a manual to know what to do.