Some errors fill the screen. And some come from the .NET Framework Microsoft goes large today in our 12 Borks of Christmas as the .NET Framework muscles in on a reader's attempt to pay for his parking. The machine, snapped by Reg reader Dylan, is squatting in a Watford shopping centre. "The Harlequin/Intu/Atria/Whatevertheheckitscalled," he said, belying the confused identity of the venue, …
"the .NOT Framework" (FTFY) ... this is probably just a result of a bug somewhere, in the code or as a result of a .NET upgrade or some other upgrade. I never saw these issues back in the days before Windows when a device like this would have been running code written for an 8048 by one programmer who tested and verified everything with the hardware designer ... just two people working together.
These days you write the code and use things like .NET which are written and supported by crowds of programmers and managers. You are coding to work with hardware that was bought from another manufacturer ... it's a bit like BASE jumping with a parachute you bought on the web ... oh wait, they delivered a Barbie parachute only 6 inches wide.
> "when a device like this would have been running code written for an 8048 by one programmer who tested and verified everything with the hardware designer"
...and it would've had a single line LCD interface, no wifi, not ethernet, would've only taken coins and spat half of them back out with no way to give change. The resulting ticket would then have failed at the barrier because the printer was crap and nothing had anpr...
The world has actually improved since then, although there are better options than windows now as well.
"The world has actually improved since then..." - yes we are seeing much better bugs. You are correct about the lack of "features" back then but a simpler environment meant that both features and bugs were less frequent ... nowadays so many bugs are "fixed" by adding more code with more features and this story simply documents what happens in this environment these days.
Having programmed the bits and bytes of the raw hardware of a TRS-80 and coming close to the same with PDP-11 hardware, I have NO desire whatsoever to return to "simpler times." Give me the raw power of modern computing to get the job done instead of wasting my time on details that should have been solved umpteen years ago.
"...bugs were less frequent..."
Not a programmer who worked in the industry back then, eh? Bugs were far more plentiful than nowadays because there was nothing tested to start out with. You had to write the whole stack for primitive hardware, from keypress debouncing on up.
I agree with you msobkow, but I was working in the field - most of the time my job was fixing programmers and hardware designers problems by testing devices - my attitude was always to try and show that the devices failed or screwed up so I was always very happy when I failed because that indicated that the devices were probably quite reliable. I've spent my whole life documenting and then fixing both hardware and programming problems everywhere.
The majority of problems are are simply a result of someone in the field not understanding every possible working and failing options in both the software and the hardware - as a result everything is sold as "working" ... the same situation we see with our phones and BORKed devices all the time these days.
Lol, probably hardware failure. Trying to deal with error codes from hardware is never fun because hardware developers never have understood software and they can't be arsed to give us enough information. This looks to me like a hardware error failing to be surfaced in a useful manner.
I've been there and thankfully rarely get involved these days.
I was developing data recovery software and was using SPTI to talk to the storage device. The first thing that gives pause is that it's accessed through IOCTL which I think all programmers would agree is never going to be a pleasant experience. But of course on the other end of that there is SCSI which is no great friend of programmers either.
So you can imagine my irritation when attempting to issue some SCSI command or other only to be greeted with error code 0x80070057 'The parameter is incorrect'. Thanks guys. Very helpful. One of the two dozen parameters I've sent to the device has been rejected. Maybe by the OS. Maybe by the device driver. Maybe by the device itself.
Thanks a *censored* million.
I could have made a 486 CPU running an old x86 version of Linux work with >20 year old Linux software do a better job. I actually tested FreeBSD 4.7 through 4.11 on an old 486 (kernel+world took >24 hours to compile but GUI performance was actually acceptable). [Worth mentioning, even on that ancient hardware, I was quickly convinced that FreeBSD would make a better daily driver and server OS than anything post-XP excreted from Micros~1, beginning with ".NOT", and soon after, FreeBSD 5 became the OS for my main workstation]. And with "modern" display hardware, it would ACTUALLY WORK (and quite possibly MORE reliably). A typical touch screen with a basic USB 1.0 compatible HID interface could do the same job with that old hardware+software as it does with newer stuff, minus the ".Not" b0rkage. Seriously, COULD be done. (but finding a working SATA adapter or replacement iDE drive for it would be difficult, so it'd probably work better to use an RPi with Raspberry Pi OS on it)
i have recently done a lot of touch screen UI stuff using an RPi, and with Linux on it, the CPU load is small, unless you use Chrome for a web-based UI, in which case Chrome is a pig and hungry for a faster CPU and more RAM. But something more native generally performs nicely, even on an RPi 1.
".Not" tried to fix DLL Hell by inventing NEW ways of B0RKING THINGS UP.
Well, at the very least, that b0rked display in the article was 3D SKEUOMORPHIC looking.
"The UK is camera mad."
Abso-bloody-lutely it is!!! There's not only an obsession with monitoring roads (cheaper than Police), but also inside shops/shopping centres (cheaper than security guards), but also anywhere you may need to interact, so if there's any kind of dispute, they have a photo and/or video as "proof".
I mean, this is a fucking parking meter with transaction in the main under £10, probably the vast majority under £5, but someone feels the need to take a picture of anyone putting money into the machine.
The real reason, of course, is the parking "fines" if you overstay your (paid for) welcome by more than a whole second. The cameras already got your car number plate, but when they issue the invoice to the vehicles registered keeper, said keeper can deny they were driving and refuse to say who was driving. Now they have a photo of the person paying for parking, which they can then match up with a DVLA driving licence request and sting you £120 for being a minute late back to your car because they can "prove" it was you (assuming you did, of course)
There's never a problem with them capturing me on film. My naked, glowing, twerking arse causes most film cameras to dissasemble in self loathing & the digital ones to barf up their bits in an inability to scream. Should any operators be watching the camera at the time I twerk past, the sobs for a quick & merciful death get drown out while I abscond with all the MindBleach.
*Hands you a set of Jujunta Peril-Sensative Sunglasses*
Put those on before it's too late. I'm going streaking later down a major public mall. =-D
(Mine's the clear plastic coat that hides nothing. Muh Hahahahahahahaha!)
So, somewhere on some disk there is a picture of whoever had the damned cheek to photograph the borkage. Soon they will be arrested and -- why not? -- extradited to the USA under the Federal Espionage Act, for revealing some sort of a defect in critical US-made software to their suspected Chinese acquaintances.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
