Hacker News Reader

One of my "favorite" examples is Docker's CMD Dockerfile instruction. I often build static Go binaries and deploy them on a "scratch" base image, which just means there's nothing there but the kernel and your app. But when I set `CMD "/bin/app"` or whatever, it will throw an error complaining that `/bin/sh` doesn't exist. Apparently `CMD "/bin/app"` compiles to `/bin/sh -c /bin/app` or whatever and instead to get it to work properly, you have to make it an array: `CMD [ "/bin/app" ]`. I only run into this once every ~9 months so I tend to forget the details, apologies if this description isn't quite correct.

Ah, yes, Docker uses the shell depending on what form of CMD you use. I do find that to be poor design. I would much prefer that they have separate instructions for those, perhaps something like SHELLCMD vs RAWCMD. Then it's immediately clear which is which.

Microsoft is the worst for this. If you have a cryptic Linux error message it's usually because something "interesting" has happened, whereas on Mac they tend to be fairly descriptive (particularly in dmesg). Microsoft's offerings inevitably are a world of "Sorry, something went wrong! ID $RANDOM_HEX" and "An unexpected error occurred". I cannot stand it.

I have to disagree there. Yes they're only writing the id of the error, but if you just Google that you usually get a super indepth description with steps how to resolve it.

Just printing error ids is fine if there is a good knowledge base which addresses them.

> Yes they're only writing the id of the error, but if you just Google that you usually get a super indepth description with steps how to resolve it.

This is a lot of fun to do when you're trying to figure out why your network driver is crashing. Had that happen before and had to result to using my mobile phone, trying to identically write the code from my computer. Again, lots of fun. Extra fun ensures when the solution involves having to download a new driver, which you then have to download on the phone, figure out how to transfer (good luck if you have an iPhone) without using WiFi since your network card doesn't work, and then finally apply the update.

Maybe, just maybe, they can add a "Details" button that would actually print out the error itself.

Sure, most would of course like that but then they would also need to get all N highly technical and detailed error messages professionally translated into all Y languages they support, right?

That is like a separate project, just as collecting/authoring the messages initially would be.

Or maybe this part of Windows is English-only? Not sure. Still, it would be quite the project to manage only for English.

> Sure, most would of course like that but then they would also need to get all N highly technical and detailed error messages professionally translated into all Y languages they support, right?

Not sure. If the error messages are translated on the website, they could as well put those translations directly into the OS. If they are not translated on the website, no need to translate them in the OS.

AFAIK, languages have to be separately installed/shipped with the installation, so if you have EN-US installed, you'll just have the error messages for EN-US.

Translating error messages just makes them less searchable. Don't. (if we're talking about drivers/kernel at least :))

yeah, MS already has a huge knowledgebase and why cant they ship the errors they already know of with a detailed fix ? w11 already requires 64GB or more storage for install. what is bad in another gb of text if it came to that?

Furthermore, there's no way it would be a gig of text.

War and Peace is about three megabytes uncompressed.

So, even if you shipped all the translations, I doubt you'd have a full gigabyte's worth. Especially not if you compressed them while at rest.

As a user, all the cloud services errors seem to do is generate a huge internal debugging string that I can't find by googling. My university's MS administrators have outright told me that they are useless. Why can't I authenticate to this service? Why do I get "Sorry, something went wrong" – they don't know. The error comes and goes periodically. It's infuriating.

As the other poster said, error codes made a lot of sense when bytes were expensive (you could fit 255 kinds of fail in a single one!). Bytes are no longer expensive. Brain time is more expensive now. Optimise for that – and be descriptive.

I think the worst for this is probably just about any C++ compiler when you make a mistake trying to use a template. You can easily get an error message that is several kilobytes and dozens of lines long.

One that always annoyed me was running a 32 bit binary on a 64 bit Linux system - it says file not found, and when I first encountered that it threw me for a little while.

Yep, that's the downside of syscalls only giving you a finite set of errors they can return, instead of being able to say "couldn't find DT_INTERP '/lib/ld.so.1'"

On the bright side, syscalls have manpages that accurately describe their errors. In this case, "man 2 execve" says:

> ENOENT The file pathname or a script or ELF interpreter does not exist.

Would you think to run "man 2 execve" when getting "file not found" with a random binary though?

No, but I'd think to do the ls and the strace as the author did. Then I'd check the manpage instead of stackoverflow. Obviously her way worked, too, but I prefer manpages. /shruggie

(Well, I just knew the answer in this case because I've hit this particular error a bunch of times, but that's not really the point.)

I actually agree with jmgao's point that this inscrutability is the downside of syscalls' limited error return; just pointing out the good as well as the bad.

Yes, you'd rather strace and as that also obscurely fails you'd then ldd the binary...

Salesforce is like this too! Cryptic error messages that say "contact admin" when I am the admin.

Playing around with a mainframe OS from the 70s (I'm weird like that), I realized that IBM has that wonderful thing where nearly every message has a code that you can use for lookup. In manuals or online, for example.

If you ever used OS/2 you might have seen that, too.

The problem is, the original handbooks are hard to come by[1], and while another wonderful thing (in some aspects) is that a modern, current mainframe is still compatible with that old code from the 70s, and so you can use their resources, you sometimes encounter error codes where the description is basically just "contact IBM". Most likely because IBM really does not expect you to encounter that error on a mainframe delivered since, say, the Berlin Wall fell.

Even if I wanted to, I doubt IBM wants to sell me a support contract for their 4 decades old last public domain version of their mainframe OS on an emulator.

[1] ... and especially on that old OS the message itself can be cryptically short, likely because even a few bytes still cost serious money in the beginning. You still see that in bootloaders.

writing good error messages is hard* and a potential security issue if it leads to information leakage. for this reason in my team (not jira) we opt for "sorry, something is wrong" per default in the UI (with maybe the real error message in the logs) and only provide the real message if deemed necessary.

* and good developers aren't necessarily good writers

Yes, it is hard to write a good error message. Sometimes it's not necessary to write a good error message if you can provide something that the user can Google or at least something that's useful to someone who can investigate further.

For example, the old "Error occurred, check the logs" is useful because it tells me that there is info in the logs.

It's even better if it says "Error 4824 occurred, check the logs" because it gives me an error code to try to look up.

Better yet is "Error 4824 occurred, check the foobar-error.log file for transaction_id nv3kd32dx9" which also gives you which error log to check AND gives you a unique ID to grep for. Sadly, I've NEVER seen that type of error message in any software.

It's much harder to figure out what's going wrong with closed source software. And even if I do figure it out, I'm powerless to change the situation.

Actually, the source can lie since the compiler could be buggy. The disassembly won't, and if you see the equivalent of 1+1=3 then you know you probably have stumbled upon a hardware bug. A hex editor is your friend; you can spend hours or even days on trying to figure out how to compile the thing correctly with all its dependencies and not change something else, or a few seconds to minutes finding what bytes to change.

Even as a system level programmer, who actually sees bugs in compilers, CPUs, and anything else, I would postulate that the vast majority of programmers in the vast majority of cases would be totally sufficiently equipped with the source code, with no need to know assembly and how to reverse engineer a binary.

In fact, the chance of running into a compiler bug is so low at higher levels, that you're better off assuming that it is not a compiler or hardware bug. If it is, you're either doing something so special that you a) might want to be doing it differently if inadvertently, or b) know exactly what you're dealing with already. Or you encountered something worth bragging about, and finding such a corner case unicorn in assembly when you don't even know the original source to know what is supposed to happen, gosh...

Otherwise, it's a bit akin to expect from a car mechanic that they can run a debugger on the ECU, or doing chemical analysis on exhaust buildup...

with no need to know assembly and how to reverse engineer a binary.

That's precisely the problem. People not knowing the fundamentals --- because the industry doesn't like for it to be widely known that a lot of DRM and other user-hostility can be disabled with changing a single bit, for example --- thinking open-source is somehow a panacea, then either wondering why it's so difficult to fix what should really be a simple thing that is "open source", or spending a ton of time trying to do it anyway. Then there's the stuff that's "open source" but effectively "look but don't touch" because they are so massive or otherwise locked out in some other way. If you've tried to change something in Android or one of its apps, you might have experienced that. (Fortunately, Java decompiles very easily.)

In other words, RMS was only partially right about open-source. Don't let that be a distraction from the real issue of software freedom which is closer to "right to repair"/modify.

Otherwise, it's a bit akin to expect from a car mechanic that they can run a debugger on the ECU, or doing chemical analysis on exhaust buildup...

No, it's more like expecting that one will look for spark, fuel, and air on a no-start before blindly swapping parts, or indeed know how to tell whether the mixture is rich or lean from the deposits on the spark plugs...

Expecting everyone to know how to read a hexdump is a very unusual take on CS education; I would not rank platform-specific assembly knowledge above control flow statements, command-line semantics, or other Intro to Programming-type material.

There's also whole categories of user-hostile software that can't be fixed with a simple binary patch -- ASM can still be obfuscated, or DRM might be enforced by a secondary processor. Dealing with those at a technical level is what I would definitely consider above the basics.

Similarly, right to repair advocacy has focused on cultural and legislative changes rather than greater technical competence. It's a good and useful skill but addressing the ills of the software industry won't come from assembly knowledge.

I guess I struck a nerve or some vested interests... but that's how it is: industry-brainwashed half-competent and unquestioningly docile developers unfortunately make up the bulk of them. Open-source is merely a distraction while they slowly destroy freedom. Dig deeper and you'll see the uncomfortable truth.

> Actually, the source can lie since the compiler could be buggy. The disassembly won't ...

...unless the disassembler is buggy.