'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 Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
