All my bests to all of you and friends and mates 
response_t foo, bar, humbug; 
Dito - hope your MP3 player isnât affected by the Z2k bug 
http://forums.zune.net/403986/ShowPost.aspx
Best Regards, Thorsten.
Rant:
Iâve been saying for years now: Thanks to capitalism and itâs offshoots, we pay the lowest rate possible for our engineers, and give them as much work to do as they can possibly endure, in the shortest possible timeframe. Thatâs the sort of thing that results. Common examples are smartphones which crash daily, the fact that gnome desktop and firefox have crash recovery now, etc etc. Iâm sure you can think of some of your own.
Iâve also been using the example that one day it will happen somewhere serious, and possibly cause loss of life or injury or %badthings.
Seems I was right: http://www.abc.net.au/news/video/2008/10/15/2391330.htm
I actually guessed that one was a firmware malfunction before it was confirmed by the ATSB. The airline tried to cover it up by blaming it on interference from an electronic device on board, which got heaps of airtime, including a full 10-minute timeslot on a popular current affairs TV news show. And of course the incident was not the hot news topic by the time that the investigation was complete, so not many people realise that was total speculation/BS/paid advertising.
The fault was somewhere (they donât say where, but you can figure it out) between the triple-redundant inertial sensors (like accelerometers/gyros, they tell the computer which way the plane is flying) and the completely non-redundant flight computer they all connect to. So, obviously, this was a firmware fault on that computer (unless all three inertial sensors had the exact same fault simultaneously, very unlikely).
I should also add for you air travellers, that this was nicely covered up, and somehow airbus were not forced to ground all models of aircraft running this firmware until it was repaired, as is the standard response when a serious fault is found. I should remind you that airbus were receiving terrible publicity at the time. Cover-up anyone? Oh - also the same systems are used on boeing aircraft. Essentially, to really fix this, means a firmware upgrade for nearly every large airliner in the sky. How much do you think it would cost to ground them all until thatâs done? Ahhh, the mighty dollar.
You get what you pay for ⌠or ⌠what you donât
I might also add that without capitalism/patents/competition/etc we could have a common database of working implementations of software/firmware/etc, which would be used by all manufacturers, and screwing up leap year dates would not happen. Itâs only because the Zune devs have had to make their own implementation, that they made this small oversightâŚ
The really sad part is, you can bet your ass that some hardworking zune dev will get his ass kicked for this, and the company directors that shell out the workloads and pay rates will get off scot-free. Grr.
Iâve been saying for years now: Thanks to capitalism and itâs offshoots, we pay the lowest rate possible for our engineers, and give them as much work to do as they can possibly endure, in the shortest possible timeframe.
Hmm, I have certainly experinced that kind of development âguidanceâ before. Some quotes; âno one cares if you just string this thing together with spaghetti codeâ, âit doesnât have to work first time, just get it on the market, quick! We can always fix it later.â
However, Iâm not so anti capitalism. Every system has its faults, and I think capitalism is the best option we have seen in practice so far. I do think open source is a very fine thing, though I think it is a long way from replacing capitalism as an all pervasive system.
Oh yeah, forgot to mention, happy new year for 2009! ~498ppm more awesome than 2008!
really? âblah blah blah anarchy blah blahâ in a happy new year thread?
Itâs not âhappyâ at all for the vast majority of the human race mate 
Most people fail to realise the extent to which capitalism/democracy is flawed. Sure it looks OK from where weâre standing⌠Thatâs because WE are the bad guys. (as exemplified by BFâs reaction: âHey youâre killing my buzz man, donât talk about the worldâs problems, Iâm busy trying to drown those out with entertaining toysâ)
Take it to a 3rd world country, where you make as much in one day as a whole family makes in a year, and try saying that again⌠Hell, just take it to the ghetto in your local town. Tell it to the homeless people where you live⌠Tell it to the girls selling their bodies to eatâŚ
I do think capitalism is the best system weâve seen so far, at least in the modern world⌠But do we stop making computers because the one we have now is the fastest one yet?
zzzzzzzzzzzz
Fair call, I think weâve both had enough of that!
On the electronic side of the of analysis tip, I canât help but wonder what exactly it was⌠I dunno if you read about it, but apparently they magically started working again the next day⌠so obviously it wasnât really locked up, *something* (the RTC apparently) was still ticking away happily. Interesting that it didnât go crazy on Feb 29, but on new yearâs instead⌠I guess thereâs some counter or something in there that only goes up to 365 days
Makes me think about error handling though. I mean letâs put this in a midi context⌠Say you have some function for setting a midi channel, which accepts a char as a parameter:
signed char SetChannel(unsigned char newchannel) {
}
Seems fine, but, thereâs no such thing as channel 255 So I mean you can do stuff like forcing the input to a legal value like
signed char SetChannel(unsigned char newchannel) {
if (newchannel > 15) newchannel = DEFAULT_CHANNEL;
foo(bar, newchannel);
return 0;
}
or Limit it
signed char SetChannel(unsigned char newchannel) {
if (newchannel > 15) newchannel = 15;
foo(bar, newchannel);
return 0;
}
wrap it around
signed char SetChannel(unsigned char newchannel) {
if (newchannel > 15) newchannel -= 16;
foo(bar, newchannel);
return 0;
}
wrap it again
signed char SetChannel(unsigned char newchannel) {
newchannel %= 16;
foo(bar, newchannel);
return 0;
}
Etc etc⌠But, say you want it to fail, and return an error?
signed char SetChannel(unsigned char newchannel) {
if (newchannel < 16) {
foo(bar, newchannel);
return 0;
} else {
return -1; //return an error code if the requested channel is invalid
}
}
OK you can have it pop up a message on the LCD, or send an error code via sysex or whatever⌠But then what? I mean, what if some other function depends on the success of this one (as in the case of the Zune 30G heh)⌠Then you have to test for this functionâs success⌠And what if that fails? That line of âwhat if that function fails?â could lead all the way back to the main loop of the app, and prevent it from running, or prevent it from returning to the main loop.
Is there a âright wayâ to deal with this, some kind of a standard or convention (official or otherwise) or is it just a matter of adjusting for the specific needs of your app, or a bit of both, or what?
Happy new year my ass, i am sick of having to be happy when i am told