'Oi! El Reg! Stop pretending Microsoft has a BSOD monopoly!' Last week, we asked readers for Linux BSODs, and ever-resourceful, you've gone beyond the call of duty and provided oddities that reach beyond our expectations. Mark yourselves down as “KPI exceeded”. Linux Airbus BSOD For the above image, Paulo kicked things off with a complaint that we're becoming a kind of anti-shill for …
Linux is now standard on Boeing, not sure about Airbus. Airbus originally was some sort of Windoze, I would not be surprised if they moved to Linux as well.
I flew FRA-SFO on United (11 hour flight) a couple of years back and the crew had some issues with the lighting in the hoy poloy cabin which shares something (not sure what) with the entertainment system. So they kept resetting it for the first 3 hours. As a result the entertainment consisted of watching the Linux boot sequence. Again. And again. And again.
Quite hilarious as I was working on some kernel stuff at the time. So the passenger in the seat next to me noticed that the stuff on my laptop screen looks waaaay too similar to the entertainment system and started asking questions "If I had anything to do with this".
"Best to aim at an open body of water though unless you want issues with the landing..."
Not necessarily - ever seen Emperor penguins propelling themselves out of the water to belly slide on the ice?
At the 2 minute mark in this video
https://www.youtube.com/watch?v=A9mbCNs47FI
http://www.bbc.co.uk/nature/life/Flying_ace, https://www.youtube.com/watch?v=9dfWzp7rYR4 was uploaded on Mar 31, 2008. You know what comes next.
This post has been deleted by its author
a photo of the fairly regular Acorn screens I used to see at railway stations
Yeah, but for that truly nostalgic feeling it needs to be on an amber-phosphor monitor with so much burn-in that you can read the most frequent destinations even when the monitor is switched off.
On a boring and slightly serious note, these things first started appearing in the early 1980s IIRC and were, I think, a thoroughly sensible solution to the problem mainly because they used teletext (MODE 7) which gave incredibly clear, easy-to-read text (by the standards of the day) and was extremely efficient in terms of data; an entire 40x32 teletext screen took about 1.2kB and so was perfectly suited to updates over slow (by modern standards) serial links.
Assuming that nobody would have been so stupid as to expect such a system to boot from floppy, I wonder if what has happened is simply that the AA cell keeping the CMOS memory alive has failed, so instead of booting from the ROM that it undoubtedly should have, it was looking for a non-existent disc?
M.
My thoughts are with Martin here, although I'm not sure that a machine running 1770 DFS had a battery (a model B+ or B+128 probably, but could be a B with a 1770 controller rather than the 8270 that was more common on model Bs. Probably not a Master or Master Compact because they came with ADFS).
The BEEB *ALWAYS* booted from ROM, but could be set to run an exec file called !BOOT from the floppy (or hard disk, but this is not ADFS) when it was started. To my mind, this looks like this is what it is trying to do. I would want to look at the access light on the drive to be sure.
Model Bs had space for a DIP switch on the keyboard rather than non-volatile memory to set the startup options, but it was possible to solder wire links rather than using a switch.
If it is that the diskette has worn out, I hope they have a supply of the soft-sectored, 5.25" double-sided, double-density diskettes, because I tried to locate some to buy a couple of years ago to re-write my collection, and totally failed to find any, even on the auction sites!
Standard 360KB or 1.2MB 5.25" IBM disks do not work.
I think I've seen some enterprising person build a SD card adapter that looks like a hard disk on the 1MHz bus for a BEEB, but that would need ADFS installed!
Maybe time to re-code for a Raspberry Pi.
Sorry to be a pedant, but it was an 8271 disc controller in the original Beeb. ;-)
I spent many a long evening playing with that... Usually deciphering the latest "funky format" used by a game developer to protect his latest release.
TBH I got more enjoyment out of that battle of wits than I usually did from the actual game.
The 8271 was probably not one of Acorn's best decisions for the BBC, since it was already pretty obsolete by the time it came out. However, I can understand their choice since it was the controller already used in the Atom disc drive module and in the System 3 before that, so they could just port hardware and software straight across.
The 8271 got to be as rare as hens' teeth, and you could get a daughterboard that plugged into the BBC B's 8271 socket that contained a 1770, which was much more available at the time.
deciphering the latest "funky format" used by a game developer
My "big win" on that front was Revs. Not so that I could make bootleg copies mind you, but so that I could change the names of all the drivers to those of schoolmates, and faff about with the gear settings to make the car go faster :-) Working from the "backup" also meant that the original was kept safely in its case.
I went on to write a disc sector editor as part of my A-level Computer Science coursework...
M.
Kinda.
Going back a bit so the details are a bit (a lot, actually) hazy. You could put a non-printable character in the disc name, which had the effect of stopping a directory listing at that point. With the appropriate text before that character you could display all sorts of nasty/scary/downright annoying messages, and lock people out unless they knew what file they needed to run.
It became a bit of a manual virus, it quickly spread around the discs for my school's BBCs.
Probably not a Master or Master Compact because they came with ADFS).
But they didn't say "Acorn MOS", they said "BBC Microcomputer 32k" or somesuch. It was the Master and the Master Compact wot said "Acorn MOS". The Master came with both ADFS and DFS and could be set to use either (or cassette or net) as the default file system.
The BEEB *ALWAYS* booted from ROM,
(also to the other poster), yes, I'm aware of that. I didn't mean the OS, I meant the application software.
The first message ("Acorn MOS") implies that the OS ROM has started correctly. The second message implies that the DFS has started correctly and is looking for a floppy disc. Not knowing anything at all about the system, however, I was suggesting that any sensible person wouldn't have designed the thing to load its application software from a floppy disc. This was before seeing Vinyl's post about updating the systems via floppy. A sensible design would (I would have thought) have involved software permanently installed in a ROM(*), and a serial link to some central server for timetable information - this would also have enabled the thing to take account of delays or cancellations. To make the thing semi-autonomous in the case of a failure of the serial link, "live" data could have been cached in EEPROM or battery-backed RAM; again, such add-ons were available for the BBC Micro, and IIRC the Master had 2x16k of EEPROM as standard.
The Master also had a real-time clock, which I would have thought would have been vital. Again, add-on boards were available for the Micro.
Even back then, floppies were known to be unreliable (and some brands of disc drive for the Micro would permanently corrupt a floppy if the power was removed at the wrong time) so why anyone would design a system to keep one constantly spinning 24/7 I don't know.
M.
(*)For non Acorn-fans, this was a common thing for Acorn's 6502 line. An unexpanded BBC Micro had physical space for (IIRC) four 16k "sideways ROMs" and OS support for up to 16. BASIC already occupied one of the slots, and if a disc drive was fitted the DFS occupied another, but expansion boards to allow the full range were commonly available. Software was often distributed in such a manner, making it instantly available on switch-on. The BBC Master actually came with some application software already installed "in ROM" - a word processor, spreadsheet, terminal program and text editor if I remember correctly (probably don't - I never had a Master, but I did have (still do have) a fairly heavily-expanded BBC Micro).
(*)For non Acorn-fans, this was a common thing for Acorn's 6502 line. An unexpanded BBC Micro had physical space for (IIRC) four 16k "sideways ROMs" and OS support for up to 16. BASIC already occupied one of the slots, and if a disc drive was fitted the DFS occupied another, but expansion boards to allow the full range were commonly available.
Another option would have been the cartridge one could put next to a Beeb's keyboard, but that would require the speech option upgrade. The Master, M128 and Leccy (with one of the extender options) had them too, although AFAIK those were physically different* from the Beeb's. Pro: they can be easily swapped; con: they can be easily removed or dislodged.
* I have a few Master cartridges, but I can only guess at the form factor for the Beeb, never having seen one, only judging from the holes in its keyboard PCB. And those look like not matching the Master's cartridge edge connector, plus they would be uncomfortably tall.
Another option would have been the cartridge one could put next to a Beeb's keyboard, but that would require the speech option upgrade
IIRC, that was solely designed to add "PHROMs" - Phrase ROMs for the speech chip. (Kenneth Kendal!) They were serial ROMs I think? The most common thing to see in that slot was a 28 pin DIL ZIF socket, connected by a ribbon cable to a 28 pin header plugged into one of the ROM sockets on the board. This allowed you to swap ROMs about without taking the lid off the machine, though of course you did have to remember to switch it off first.
M.
The Model B startup was as follows:
BBC Computer 32K
Acorn DFS (or 1770 DFS with appropriate controller and ROM)
BASIC
The B+64 and B+128 changed it to Acorn OS 64K (128K), with Acorn 1770 DFS
The Master series was Acorn Mos (for version 3.20) and MOS for 3.50) and DFS as above - and had a CMOS battery, in the shape of 3x AA batteries.
The Master Compact was:
Acorn Mos
Acorn ADFS
BASIC
Regarding the SD card, look up "Retroclinic".
Thanks for the link to RetroClinic, and the detailed startup information.
My BEEB has an issue 3 board, ordered on the first day that they accepted orders, and was delivered with OS 0.1, and still has Basic 1 (the OS was upgraded when the disk upgrade was fitted). I never really used B+ or B+128s, but I did have access to one of the first Masters that was available, with a 3xAA battery holder for normal batteries, not a single battery, but no longer. I also ran an Econet Level 3 fileserver with a 10MB hard disk for a network of machines with many of the available peripherals.
I think the DataCentre may make it onto my Christmas list! I hope it doesn't clash with the ATPL Sideways ROM board, but I suppose I could take that out.
This post has been deleted by its author
I think I've seen some enterprising person build a SD card adapter that looks like a hard disk on the 1MHz bus for a BEEB, but that would need ADFS installed!
Maybe time to re-code for a Raspberry Pi.
Wouldn't take much. Either run a RasPi with Raspbian and whatever works or RISC OS with one of the 6502 emulators. Either way, at the very least, you could have the floppy as an image, similar to the way that RPCEmu does it. Then it would just be a matter of how you communicated with it.
so instead of booting from the ROM that it undoubtedly should have,
Why? The entertainment terminals in an aircraft are dumb and useless without a network. So rather unsurprisingly, they do network boot to decrease the cost, ensure they all run the correct software revision and make any upgrade as easy as an on/off.
The BR departure display system was called PIDS (for Platform Information Display System) and originally ran on BBC Micros, later ported to first generation PCs. Each year when the national timetable was compiled (usually no more than a couple of weeks before it went live; the final version used to produce Working TimeTables and other internal data was usually not available until after the public version was already in the bookshops; however it was considerably more accurate), or when it was updated for any reason, extracts had to be run for each station on a line and exported to a floppy disc, then some poor sod (me for some time) had to take the discs and manually load the data onto the machine (which, as has been pointed out elsewhere, was usually stuffed in the back of an inaccessible cupboard with questionable levels of ventilation, moisture, diesel fumes and other environmental factors of which PCs are not particularly fond) at each station. You then had to input the date on which the new timetable would start and, all being well, the information would be correct for the start of the new timetable. I say "all being well" because on one occasion I was caught out by the fact that somebody at one station had helpfully switched the PC date format to US, so when I put the start date to 06/05/89 it didn't kick in on the 6th May as expected. A return site visit eventually resolved the problem.
To give an example of what was involved in updating the system I had to visit:
Stratford
Maryland
Forest Gate
Ilford
Seven Kings
Goodmayes
Romford
Gidea Park
Harold Wood
Brentwood
Shenfield
Billericay
Wickford
Rayleigh
Hockley
Rochford
Prittlewell
Southend Victoria
Ingatestone
Chelmsford
Hatfield Peveral
Witham
Kelvedon
Marks Tey
Colchester
St Botolphs (now Colchester Town)
Hythe
Wivenhoe
Alresford
Great Bentley
Weeley
Thorpe-le-Soken
Kirby Cross
Frinton-on-Sea
Clacton-on-Sea
Walton-on-the-Naze
If you remember what floppy disc transfer rates were like you can imagine that took an absolute minimum of 20 minutes at each station, plus waiting times for the train to the next station. Realistically it was a three day job doing nothing but updating PIDS and waiting for the next train!
Given the age of the system I am utterly amazed to find an example still running in 2012, particularly the BBC system, and find myself wondering how the hell they managed to keep it updated given that the updates needed to be exported to 5.25" floppy discs. Assuming it was replaced by a more modern system following the illustrated failure it must still have given over 30 years continuous service!
Those working with the modern, centralised, online, real-time systems don't know they're born! :)
What an informative post!
Reading it, it crossed my mind that, with access to a pc and loaded with the current BR timetable, a program could be written which worked out the optimal sequence of station stops to complete the job in the shortest possible time. Assuming that the trains were running on-time, of course :-(
Unfortunately PCs were not, at that time, powerful enough. The first PC rail planner I am aware of was released by BR Business Systems, covered the Network South East area, and was branded as Journey Planner. It was released in approximately 1992 if memory serves, and required a 386 with maths co-processor or a 486.
If you remember what floppy disc transfer rates were like you can imagine that took an absolute minimum of 20 minutes at each station, plus waiting times for the train to the next station.
Ah, you answered my question. I was just thinking that "wouldn't it be great if there was an easy to use transport system that linked all those places together ?". But then I realise when this was, and perhaps the answer is (was) "the road system" :-)
I admit, it's Windows wall to wall here and BSODs are pretty much unknown.
However, are any of these Linux screenshots really OS crashes? First one looks like something failed to load at boot time, rest look like application failures.
Like I said, I don't know much about Linux, just have doubts that these are OS problems.
In the same way, you really going to blame the OS for a bad/kernel panic when the RAM or PSU starts to give up the ghost? It's still funny as when the resulting dump lands on a giant public display (proceed with this silliness at full steam) though, no matter what the OS.
The last time I saw a kernel oops was for a 2.2 effort that I'd accidentally nudged the (unfastened) motherboard and caused something to break circuit. They are possible, you can see them in the code but they don't really turn up too often.
To be fair I haven't seen many BSODs recently either but that may be because I don't see much in the way of MS these days.
The glory days of the BSOD were the Windows 9X era when the mere failure to think MS approved happy thoughts would prompt a VXD* to pull a blue screen. That really was Windows fault.
*What do you expect from something deliberately (and awkwardly) named not to sound like a disease.
I'm fairly certain that back in the late 80s/early 90s (when they rebuilt East Croydon Station) I saw several of the platform monitors displaying the C64 startup screen. If they eventually went for BBC micros, they may have been testing the system.
Actually, it makes sense to use consumer micros. They would have been cheaper than any custom made system, and the likes of Acorn and Commodore would be more than capable of manufacturing enough devices for BR's needs. They would probably be cheaper to maintain as well, as there would have been a lot of technicians with experience maintaining Commodore 64s and BBCs.
1770 DFS was also an option on the Master, for compatibility's sake.
The original BBC Micro's official disc interface used an 8271 chip; while I believe some third party options were available with the 1770 or 1772 chip for the Micro, the Master used a 1770 chip as standard. Apparently the 8271 was already EOL when they specified it for the Micro, but the 1770 had the advantage of allowing "double density" recording, and also being compatible with the format used by the 8271.
The BBC Master therefore had both "1770 DFS"; single-density, compatible with discs created by and for the BBC Micro and "1770 ADFS", which was double-density. Disc capacities ranged from 100k (40track, single-sided, single density) to 640k (80 track, double-sided, "double" density). The main limiting factor for the single-density discs was a 31-entry single catalogue; i.e. there were no (real) directories, and a maximum of 31 files per side of disc, even if there was spare storage on the thing. Third parties had various ways of solving this (e.g. my Watford Electronics DFS allocated two additional disc sectors to allow 62 files per disc, but was otherwise 100% Acorn DFS compatible).
ADFS brought subdirectories and additional catalogue space.
The Archimedes used (I think) the same 1770 (or 1772?) chip, but fiddled with the format to allow 800k per disc. By default the Archimedes couldn't read DFS discs, but third party tools were available. Archimedes users used to crow that this was a good deal better than the PC at the time, for which the standard format was 720k. We conveniently ignored Amiga users who used some clever speed tricks (I believe) to squeeze 880k onto the same discs.
My Archimedes and BBC Micros are still in the attic and the last time I got them out (couple of years back) they did work, though both had some keyboard problems (dead keys).
M.
And it appears that it's actually the floppy drive that's gone to meet its maker; ISTR the Beeb just waiting at this point if you had DFS installed but no drive connected. That, or it's the floppy itself that's now devoid of most of its magnetic coating, but, ISTR again, that would result in some error message.
And no, despite being a non-UK reader, I did not have to consult Wackypedia for this. I can even recreate the screenshots; it's all there in boxes in the attic.
<insert "cobwebs.ico">
That Cisco BSOD isn't a real BSOD.
All that message says is: "You asked me to parse some XML and you gave me garbage." All you have to do to exit it, is to press the "Exit" softkey. It's not rebooting the phone, just exiting the attempt to parse the XML and return to normal phone operations.
Then the CISCO Phone makes perfect sense.
As for the netowrk link.... did the developers not stop to think that telling the world that the network link had gone away was not a good idea? And decent system (end-to-end) should be anlt to handle that sort of thing gracefully. surely there is a better solution here oh, I don't know.... Telling the people watching that the device is temporarily out of service sorta like ATM's do (or should do).
No.
That is the Blue Screen of Life
Or Blue Screen of Basic*. Or in the case of C64 basic, Blue Son Of a Bitch iirc. Poke this, peek that. What kind of low level nonsense is this?
Actually C64 basic encouraged playing around deeper in the hardware.
C64 music is the best. Mine is the one with a copy of Master of Magic on a C30 tape.
"Actually C64 basic encouraged playing around deeper in the hardware."
Pretty much all of the 8-bit BASIC based computers did even prior to the 64. It was the only way to do "clever" stuff and to get some real speed out of them. Writing a game on a PET? peek 515 (or was it 151) to get an "instant" read which key is pressed. Ditto on TRS-80, lots of peeks and pokes to do clever stuff like using VARPTR to locate where in memory a string has been stored so you POKE Z80 code into it, then pass the result of VARPTR to USR to execute the code, even if garbage collation or other variable assignments have moved it. TRS-80 BASIC also had IN and OUT commands to write/read up to 256 8 bit ports for external hardware which made for easier interfacing projects since you only had to identify the port read/write pin and decode an 8 bit address instead the 16 bit memory address on some other systems.
Lots of the old circuit designs (component availability permitting) are probably transferable to a modern RasPi with it GPIO ports. How anout a computer "WiFi" controlled Big Trak from the era of Apple ][, CBM PET & TRS-80? See page 79 of Ciarcia's Circuit Cellar, Volume 3
BSOD equivalent on a C64 was usually a screen full of garbled characters. Or the tendency to respond with ?SYNTAX ERROR to everything even when preceded by line numbers, as when typing in a BASIC program. But since the C64 had no DOS and therefore instant-on booting, it wasn't really an issue in the first place. I wore out numerous pushbutton switches I'd hooked up to my C64's user port as reset buttons as my standard response to this.
A closer analogy to a BSOD would be the infamous Guru Meditation on the Amiga platform, aka the Black Screen of Death. At least you knew when it was coming, when you saw the power LED flashing (or brightening/dimming on later Amigas) you'd usually reset before the Guru put in an appearance.
Recently flew from Japan to Helsinki via Moscow and back on aeroflot. Apparently Aeroflot (and I presume most Boeing) aircraft use a custom version of XMBC running on DSL linux. The seatback screens were all stuck in some kind of reboot loop for around 45 minutes after take off on the return leg from Moscow, eventually booted and ran fine though.
I recently did a couple of flights to/from Singapore. The outward leg on a slightly older 777 was definitely Linux - got to watch the boot process on a layover. The return flight was on what looked to be an almost-new (or at least recently refurbished) 777. Didn't see a boot screen, but some of the iconography on the touch UI looked very Android-ish.
So I guess it's not just 787s. Also I guess Google now know what movies I watched, what my in-flight meal was etc.
A "BSOD" is a fatal system error caused by a coding error (or errors) in the kernel, leading to a system crash which requires a power-off restart. None of the above qualify. Rather, all are clearly PBKAC errors in user-space (not the kernel!), caused by whoever set the system up. All can be cleared up from a login with a dumb terminal, no reboot required.
...you are seeing the output devices BSOD. Most of the time they are bottom of the range windows PC's, Raspberry PI's,the monitors built in OS or any other random bit of hardware, connecting back to a fairly heft server.
And just like any other bit of kit, they need patching, updating etc, the only difference is they are in very public places.
7 working scan-it-yourself POS terminals out of about 20 (and 3 of those 7 tried to short change me last week). Most had a big 'No Entry' sign, which I presume means the software is sufficiently alive and kicking to understand it should say the terminal is broken. There were some Windows dialog boxes saying 'I should have sent an email to the appropriate techy explaining the problem so he can ssh in and fix it, but instead I am going to spew my guts onto the screen and invite any passers-by to poke things with interesting consequences because the committee of clueless twits who specced my OS are too thick to understand that not all computers can rely on friendly humans being near by'.
The last two were the ones with black screens of death: UEFI saying "I bet you wish you had used a Pi now"
The real stupidity prize goes to the customers who thought it would be sensible to form a queue at the entrance to the scan-it-yourself section instead of walking past the obviously broken ones to the point where they would be able to see 4 working terminals ready and waiting.
Sorry for the repost but it appears that the Register Android client is a complete pile of bull-dooky. I've now uninstalled it so it won't happen again.
Don't know if I'd go that far, but it really could use a bit of work.
Starting with the programmers.. Gentlemen, could you line up by that wall over there? Yes, the one with all the small holes in it....
(Great for getting the stories, not so great for getting the comments (why does it sync them then complain about network errors when you try to view them, regardless of whether you're on or offline (and it can display them happily when you are offline so must do the syncing it claims), and it's quite shite for writing in comments. Lacks copy'n'paste fro a start. Oh, and IIRC no voting on comments either! But at times is my most used app)
That's pretty much the only reason I've seen any BSODs in the last... oooh, 6-7 years now? Despite the naysayers in the Lunatic Cult of The Swearing Penguin, it's a rare beasty indeed these days. I'd imagine most of any software related ones now come from legacy software that still has the magic touch...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
