>> Faulty software is unecessary. It's quite possible to write software 
>> that works well, and it needn't even be particularly expensive. 
>> (Depending on what it's supposed to do, obviously.) But people can't 
>> be bothered, it seems...
> 
> Bad software is everywhere, though.

Sadly yes.

> Unfortunately, bad software being 
> burned to a ROM means that device will likely have bad software forever. 

Almost everything these days seems to hold software in some sort of 
flash RAM rather than actual ROM now. (What does that say about firmware 
reliability?)

> Honda is likely using firmware from an outside company. I'd hate to 
> find that the same quality software resides in, say, the ECU or the 
> cruise control system, or worse: the airbag controller....

Er, yeah. o_O

> But, alas, this is a mere consumer device. They want it done quick, and 
> they want it done cheap.

This seems to be the way these days. Cheapness is the number one 
priority. I'm probably just old and grey, but I swear there used to be a 
time when *quality* was the number one priority... These days it seems 
to be who can make the device for a few pence less than anyone else. 
Because cheap == good, right? *sigh*

>> And yet, 
>> a bunch of bored hackers on the Internet who don't even have access to 
>> the design spec for the player managed to do a better job than paid 
>> programmers. I ask you...
> 
> They didn't have tight deadlines to hurry up and finish the project? 
> They're more talented/driven than the manufacturer could pay for?

Given that there are hundreds of players on the market, many of them 
cheaper and more featureful than mine, you'd think they would want to 
not release it until it was working really well. I guess not...

Still, it boggles my mind that anybody could take a random piece of 
hardware and figure out how the hell to write low-level device drivers 
for it with no technical data at all. I mean, how the hell do they even 
know which CPU it has?!

>> Indeed. There's no reason for it, other than they didn't plan what 
>> they were doing properly. If they'd done the job right, it would work.
> 
> Likely. Though clipka's theory sounds plausible. Unicode is a tricky 
> thing to do correctly anyway. It's not just finding the appropriate 
> glyph for a given codepoint, but also how that codepoint is supposed to 
> affect the output stream, string normalization forms, RTL and other 
> really fun gotcha's.

It's perfectly possible to handle Unicode properly. As clipka says, it 
was probably just a feature they threw in at the end without testing 
properly, that's all.

Post a reply to this message