Linux needs to come in after the fact and run on whatever garbage happened to ship.
(FWIW: in this case the root cause was a host bridge in the tables which had been granted a truly outrageous memory space despite having no devices in it. It was likely a typo, or some test stuff that got left in.)
I was not writing code at the time and had nothing to contribute.
So apparently they fixed it later.... then came the security issues, unexpected behavior, shit going sideways.
Sometimes a straight crash is not such a bad thing.
One of the things I like about Kubernetes is that the ecosystem (generally) tries to adhere to the "Not healthy? Then crash and keep crashing" mantra when something doesn't work. If I see something is in a CrashLoopBackoff I at least know its b0rked. Stuff that reports its up and running when it's actually hosed is really annoying.
The worst sort of thing to track down is working ... but not. God knows when it started or what it has impacted.
Worse if it impacts real data or data goes where it shouldn't.
You're assuming this was an issue. Manufacturers religiously create artificial tiers in software to upsell users. This is true of hardware just as much as it is software.
(It also took some Perkele by Linus to make it work correctly)
Perkele means evil spirit in Finnish and is a popular Finnish profanity.
https://www.itprotoday.com/compute-engines/windows-nt-and-vm...
https://www.amazon.com/Showstopper-Breakneck-Windows-Generat...
EDIT: fix typo
:)
Toward the end of the Bell system, AT&T used Unix to run the control plane of phone switches and also to do administrative tasks for the phone network. I remember a paper in the Bell Systems Technical Journal where they did auditing of billing records for the whole U.S. with a set of tools kinda like grep, awk, etc. but with binary-format data records.
There are situations where operating systems get behind the 8 ball and there isn't a perfect thing to do. Giving up to prevent data corruption is one choice, but trying to soldier on and do the best you can is another.
Lists of recently switched processes, or the general category of errors it falls in.
It should certainly be possible for someone who can diagnose an error to see the details, but making it the default can be problematic when the message has a chance of being shown to real end users.
I think normal users have a pretty good idea what to do with it -- show it to the nearest tech person or paste it into Google.
Just giving it to them up front makes things easier, not harder. They need help so they take a screenshot. If it contains the relevant information, someone can help them. If it just says "an error occurred" then nobody can help with that because it contains no information. Now they have to go back and have the tech walk them through trying to extract the information from some log file, which is seventeen clicks through an interface they've never used and now there are 5000 entries and they don't remember exactly what time it happened etc.
It also deprives the user of any opportunity to learn. The user has a problem, they get a message, they ask the tech what to do and the tech tells them. Now the next time they get the same message they know what to do. But if the message is always the same regardless of the cause then they lose the ability to match known problems with known solutions and give up.
Not all users care to learn that sort of thing, but you take it when you can get it, not purposely inhibit the user from doing it.
I suspect the modern trend of making problems opaque comes from companies that do it on purpose. If the user can solve their own problems, what do they need with your expensive support contract? Why have the user fix problems with their existing device when you can sell them a whole new one the first time anything happens?
And then other developers who don't even use those business models still cargo cult the same UX.
I rather have a detailed error report in one language and then have to find someone who speaks it to translate it (if Google doesn't do a good enough job), than fifteen poorly written versions. Not to mention, those error screens should be as minimal as possible in terms of features so less goes wrong.
I don't want animations, fancy colors, dealing with the horror show that is localization, or anything of the sort. Because the system when it hits a bsod is in an undefined state, so it's best to exercise as little as possible of the system, just enough to get the error message out.
Already this excludes most people who will see the error. Meanwhile, experts already have more sophisticated tools available to them like the event viewer. Obviously that wouldn't be useful in a situation like this where boot-up is blocked, but like I mentioned previously, there's only so much diagnostics you can reliably provide on a system that is in the middle of crashing.
So both sides have to be able to see the details.
Nobody is decoding QR codes by hand, so it isn't that big a deal to go from "https :// www.windows.com / stopcode ? code=ACPI_BIOS_ERROR" to "https :// www.windows.com / stopcode ? code=ACPI_BIOS_ERROR & p1=0000000000000002 & p2=FFFF9A0..."
If it is for the user then being able to google the exact error is going to return more results than 47 translations.
Most users will in fact do nothing but report said error to their vendor whom will refer to their English language documentation.
In other news most programming languages aren't localized for example.
And they already provide just enough information to be able to google the error. I am just opposed to adding more detailed information, the kind of information that's only relevant for experts and is not guaranteed to be available in the middle of a crash.
> In other news most programming languages aren't localized for example.
Programming languages aren't consumer products like operating systems are