Actually the planes are overhauled on a regular basis. Virtually the entire plane is replaced over a 7-year timespan. Also, there's a big difference between a plane with a very large and dedicated maintenance infrastructure versus a lone probe zipping around in the depths of space.
What I find amusing is that everybody gets pissed off at Microsoft, instead of SGI, who sold these precious patents in the first place. Who committed the greater crime? (Not that I'm personally worked up over this issue, but you know what I mean.)
Well, it's a new definition for "dark ages", that's for sure.
I was under the impression that the defining characteristics of the dark ages was ignorance, suppression, warfare, famine, strife -- you know, BAD STUFF.
And by that I mean, worse than simply forgetting something you wrote down somewhere.
Sometimes I really wonder about the things you guys elevate to "front-page article" status...
(Yes, user johnjones already posted about Showstopper, but I have more to say than "this book was funnnneee..."). So, as johnjones pointed out, there is a book related to this subject: "Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" by G. Pascal Zachary.
What's interesting is comparing what Showstopper says to the claims in these slides.
The slides suggest early NT development was done by a small team of super l33t c0d3rz who took care of business and frowned upon slacking. However, the picture painted by the book is dramatically different -- people were forced to work around the clock, the team was dominated by a small gang of guys who were basically complete assholes, everybody walked on eggshells for fear of pissing off Dave Cutler, The New Savior, and NOBODY in the group ever knew what was really going on. The whole project was shrouded in mystery, even to people on the team, because basically everything existed in Cutler's head.
The only thing I see where Showstopper and the slideshow firmly agrees is the slide labeled "Goal Setting".
I personally have a lot of other opinions about why some of the statistics may pan out the way they do (for example, how much hardware did you REALLY have to test with in NT 3.1 days, versus Win2K?) but I want to stay focused on the Showstopper/slideshow discrepancies, so I'll leave it at that.
The thing to realize about Showstopper is that it was based almost entirely on interviews with the people who were involved with the initial NT coding effort.
By comparison this slideshow was written by one guy, Mark Lucovsky, who gets lightly flamed in Showstopper (at best). Oddly, I grabbed Showstopper off my bookshelf and opened it straight to the page describing Lucovsky. Weird. Anyway, here are excerpts from a single paragraph: "...smart but immature... nevertheless angered teammates with his skepticism and self-serving judgements... relentlessly critical of others, constantly probing for weaknesses... 'Until you prove otherwise, you're wrong and he's right.'" Whew, hate to be THAT guy. It gets worse. One page later, a paragraph opens by simply saying, "Many people felt that Lucovsky was a jerk."
Given that, it wouldn't surprise me if Lucovsky was still just trying to justify the fact that the early NT dev team was comprised of a bunch of flakes who had to burn the candle at both ends to actually deliver anything.
Please understand I'm not necessarily defending any current MS practices, or even Win2K (which is still vastly superior to NT3.51). I've personally worked VERY closely with groups inside MS at different times (a couple times on-campus in Redmond), and I'll be the first to tell you the company is bureaucratic and packed to the gills with people who don't know what the hell they're doing -- just like every other company that employs tens of thousands of people.
What I *am* saying is that this slideshow is looking at the past with "rose-colored hindsight" and I believe the motives are suspect at best. Draw your conclusions with a grain of salt. (Enough metaphor-abuse for today.)
Do like johnjones suggested -- go buy or check-out Showstopper and read it. It's interesting, informative, and it IS kind of funny. It's amazing they were able to produce anything at all. How's THAT conclusion for contrast with the slideshow?;)
Oh yeah, Vivid, I loved that one, too. Vivid's hazy-sphere thing was lots of fun. Useless but cool looking.:)
My favorite POV True Life Story (TM) was this image that took my brand new 40MHz 386 about 19 hours to render... then I bought a 387 coproc and render time dropped to 19 minutes. Luckily the rendering was for work purposes, so on the spot I justified the cost of the 387.
And then there was my big show of "working late" at a different (non-graphics-related) company... In reality I was just hanging around so I could set up everybody's PC to render fragments of my images overnight... I guess these days they'd fine you $400K and send you to jail for 30 days.
I did on a stock market charting application I worked on many years ago, but it was just something I was playing with. Back then POV ran so slowly it really wasn't worth it for my needs.
You'd probably have to have some very complex visualization requirements before the processing overhead would be worth it.
Maybe it's heightfield support would be cool to use, I suppose.
I've been using POV since the days it was the new upstart on the block and all the CompuServer folks were using DKBTrace.:)
POV rules.
It's EASY to bring current machines to a grinding halt with POV-Ray. I was doing some weird experimentation last year... one image featured about forty intersecting glass planes and a bunch of fog and lighting effects. A very low quality rendering at only 640x480 on five networked machines ranging from 500MHz to 1.2GHz (with workloads split according to CPU power) took six days to render. A back-of-the-envelope calculation put a high-quality anti-aliased 1024x768 render at close to a month of round-the-clock processing.
I figure I'll go back and try this again when my slowest machine is 1.7GHz, I've got a couple of old 2.2GHz boxes laying around, and my main machine is 5GHz or so. Seriously.
Here's a cool POV wallpaper I submitted to skinz.org which I completed just before I gave up on that big project above...
Actually Microsoft did hire a German company to port COM services to UNIX. Unfortunately I've forgotten the name of the company which did the port. However, it was available for a number of years. In addition to the basic anti-MS sentiment in the UNIX community, I believe it didn't generate much interest because it became available roughly around the time the Internet was kicking into high gear (for which COM/DCOM is rather poorly suited) and the time Java was everybody's media darling.
But they did deliver COM on UNIX.
And yes, I get it.:)
Yes, you have missed something important, and unfortunately Microsoft marketing is to blame (again). Indeed a great number of MS programmers have missed it too, so you're not alone. Remember when.NET was called Next Generation Windows Services (NGWS)? Probably not, but it was for at least two years' time. NGWS is what's important about.NET.
This web services crap was basically smoke-and-mirrors. As someone else pointed out earlier in this topic, if MS or somebody else writes a CLR, suddenly, "Windows" programs will run on other operating systems without so much as a recompile. Given the DOJ problem which was looming large around the same time as the.NET unveiling, I think the "look at our web services" smoke-and-mirrors tactic intentionally diverted attention away from this potential portability option. Indeed, the portability concept was so important in their design phase, MS went as far as to segregate a great deal of highly-Windows-specific functionality in classes with names like Microsoft.xxxx (although this comprises only a tiny fraction of the full.NET model).
Don't get me wrong -- I like SOAP and have pushed for it (and used it, and early derivatives) inside my company for years -- but comparing.NET to "web services" is like comparing your desktop computer to one of those e-mail appliances for the computer illiterate. Sure it CAN do those things, but it's only a small fraction of the real story.
The.NET system object model is a top-down redesign of practically every part of the Windows API. Win32 is gone, GDI is gone, even COM/DCOM is gone (although still accessible). Instead you have this fantastically consistent MASSIVE system object model. Programming against this thing is pretty great. There are a few holes and a few decisions which strike me as stupid, but when you're talking about thousands of classes, everybody is bound to have a few pet peeves.
Unfortunately, it's hard to put an exciting marketing spin on a great new system-wide API strategy, and as I mentioned I don't think they wanted to play up the portability aspect at all, so we end up with the vague.NET marketing-speak hype machine.
There are other important and useful things in.NET, too, but to me the new comprehensive (and consistent) system object model is by far the most important (did I mention it was consistent?). People who compare it to Java either haven't compared them in-depth, are extremely Java-biased, or simply don't know what they're talking about. But that subject has been discussed to death in great detail all over the 'net, just search for it. (BTW, I was a professional Java programmer for over two years -- I'd say Java is merely "OK", not great -- I mention this as evidence that I'm not simply a MS-centric anti-Java nutcase, I did use it to make a living, for awhile.)
I think if.NET fails to gain momentum, it will be a great loss. Beyond the crappy marketing spin that seems to bury anything MS manages to do well, I think Microsoft itself may accidentally kill interest in.NET by only shipping it to the Great Unwashed as part of some new DRM-nazi consumer-unfriendly Windows -- call it WinDisney.
But from a purely technical perspective,.NET is pretty great.
No one needs to know how the internal code that runs the engine works, but knowing what all the errors it can tell you mean is pretty damn important. Knowing that changing your brake fluid the "old" way isn't doing the job completely is important to know too. This isn't stuff that "backyard" mechanics don't understand, this is stuff they are being deliberately not told. There's a big difference.
No one? In fact, there is huge interest in how the code works. A very large number of the aftermarket chips and often things like A/F ratio controllers are directly dependent on how this code works. As an example, I race Vipers, and it was very important to know exactly what both ECUs were up to for optimizing the fuel map (I say both because the Viper V10 is really a V6+V4, right down to having a pair of ECUs). Just watching how the cells change (even using a dealership's $3000 monitoring tool) won't help much unless you can see the code. It's like watching Windows Media Player GPF. You sort of know what it did, but you have no idea why...
Also, I've never saved the URLs but I've seen quite a few discussion forums on the 'net dedicated to reverse-engineering the code in stock engine computers. The discussions commonly include chunks of assembly code. They're very serious, and they're very interested in the code itself.
On here, though, there's a bigger problem with people who know a lot less than they think they know.
Indeed...:P:)
Finally, this whole issue might be barking up the wrong tree. It may not even be the automobile manufacturers who keep this stuff "secret". I saw VW mentioned a bunch of times. A guy I know (who races Vipers) is an engineer who designs the chips for stock VW ECUs, and his company also writes the code -- and he doesn't work for VW. In other words, VW and other auto manufacturers do not necessarily own the code that runs their cars, it's often contracted out.
It would take some work, but you could use the old Fractint program's "disk video" mode to generate a series of 32767x32767 image files in a tiled layout, then write a simple app to chain them together and print them out.
Many moons ago in the college daze, my friends all jointly (pun intended) rented a big farm house which featured a giant white garage wall at the end of the long driveway. We'd planned to do use Fractint to create a series of sort of "paint-by-numbers" templates to cover this huge wall.
Never happened. Too much reggae, beer, sun, etc.
But still -- check out Fractint. They never got beyond version 20.x under DOS, but it's still one of the more flexible programs available for scripted automation... search for it in Google, there are a couple of dedicated sites out there.
Anyhow, I was thinking three of these things - if they were all turned on (all three, space at 120 degrees apart on a circular platform), the platform wouldn't go anywhere, but by varying the speed, you could get diferent motion vectors
Pager motors are one of the perferred devices for imparting motion in BEAM robotics. Look here or here, for starters -- there are tons of BEAM sites out there...
How many of you would be able to fix your own cars or repair a stove?
Probably a lot of "us", actually. Fixing a car, repairing a stove, or (as most people here probably know), digging around in the guts of a machine actually isn't that hard.
The point is that most people are too lazy to fix a car, fix a stove, or learn to use a PC beyond "The little blue 'W' starts Word when I poke it with the arrow."
The question shouldn't be, how easy is too easy, but rather, how lazy is too lazy? And I think we passed the "too lazy" point a long, long, long time ago.
Have I missed something on the SGI site, or does this licensing change open up OpenInventor to run on any platform?
I couldn't find anything that specifically said Linux, but that's how the/. article is written, and that seems to be the gist of the conversation so far. (Although I'm guessing that's probably the "other" slashdot effect, Linuxcentricity)...
The Coke bottle is a great example of trade dress. It is still so familiar even to this day that they decided to put a huge Coke bottle replica on the Las Vegas strip as part of the Coca-Cola store. Everyone recognizes the shape instantly as belonging to Coca-Cola - that is what trade dress is all about.
The bottle design is nothing compared to the way Coke defends the little red-and-white swish. A few years back we did some multimedia apps for Coke, and a significant portion of the legal swamp we had to navigate centered on that read-and-white swish, which they amusingly refer to as their "dynamic ribbon device". And god, never, never say the word "Pepsi" inside their building or you're almost literally escorted to the street.
On the other hand (this is my on-topic-tie-in), the bottle design and the dread "dynamic ribbon device" are recognizably associated with Coke, whereas tabs are just an on-screen doodad that are relatively obvious. Hell, if Adobe really starts being a dick about this, just go back to button-strips where the current item's button is depressed. Same thing, mildly different look. Even the same code behind the scenes.
Sure, they look similar. They also look exactly like the control panels Windows 95 uses. Hmm, I wonder why Adobe isn't suing Microsoft?
If you'd read the article, you'd know that Microsoft (and a number of other companies) cite Adobe's work as prior art. IANAL, but if I'm not mistaken, this implies they have an agreement or possibly even a license. (Amazing... I was able to read ten or fifteen useful comments before the Microsoft whining started.)
They claim it didn't arrive in time for them to test. Granted, that's a pretty bogus claim, but it's their excuse.
Think: magazine lead-time.
IIRC, PC Magazine has often quoted lead-times in the past of something amazing like four months. I'm sure it probably varies depending on the column in question, and it wouldn't surprise me to find that the lab tests in particular have a long lead-time. It's quite a bit of work to globally distribute a 200-page technical (well, pseudo-technical) print-publication...
Slashdot Mirror
Actually the planes are overhauled on a regular basis. Virtually the entire plane is replaced over a 7-year timespan. Also, there's a big difference between a plane with a very large and dedicated maintenance infrastructure versus a lone probe zipping around in the depths of space.
GET OFF MY LAWN!
What I find amusing is that everybody gets pissed off at Microsoft, instead of SGI, who sold these precious patents in the first place. Who committed the greater crime? (Not that I'm personally worked up over this issue, but you know what I mean.)
I was under the impression that the defining characteristics of the dark ages was ignorance, suppression, warfare, famine, strife -- you know, BAD STUFF.
And by that I mean, worse than simply forgetting something you wrote down somewhere.
Sometimes I really wonder about the things you guys elevate to "front-page article" status...
What's interesting is comparing what Showstopper says to the claims in these slides.
The slides suggest early NT development was done by a small team of super l33t c0d3rz who took care of business and frowned upon slacking. However, the picture painted by the book is dramatically different -- people were forced to work around the clock, the team was dominated by a small gang of guys who were basically complete assholes, everybody walked on eggshells for fear of pissing off Dave Cutler, The New Savior, and NOBODY in the group ever knew what was really going on. The whole project was shrouded in mystery, even to people on the team, because basically everything existed in Cutler's head.
The only thing I see where Showstopper and the slideshow firmly agrees is the slide labeled "Goal Setting".
I personally have a lot of other opinions about why some of the statistics may pan out the way they do (for example, how much hardware did you REALLY have to test with in NT 3.1 days, versus Win2K?) but I want to stay focused on the Showstopper/slideshow discrepancies, so I'll leave it at that.
The thing to realize about Showstopper is that it was based almost entirely on interviews with the people who were involved with the initial NT coding effort.
By comparison this slideshow was written by one guy, Mark Lucovsky, who gets lightly flamed in Showstopper (at best). Oddly, I grabbed Showstopper off my bookshelf and opened it straight to the page describing Lucovsky. Weird. Anyway, here are excerpts from a single paragraph: "...smart but immature... nevertheless angered teammates with his skepticism and self-serving judgements... relentlessly critical of others, constantly probing for weaknesses... 'Until you prove otherwise, you're wrong and he's right.'" Whew, hate to be THAT guy. It gets worse. One page later, a paragraph opens by simply saying, "Many people felt that Lucovsky was a jerk."
Given that, it wouldn't surprise me if Lucovsky was still just trying to justify the fact that the early NT dev team was comprised of a bunch of flakes who had to burn the candle at both ends to actually deliver anything.
Please understand I'm not necessarily defending any current MS practices, or even Win2K (which is still vastly superior to NT3.51). I've personally worked VERY closely with groups inside MS at different times (a couple times on-campus in Redmond), and I'll be the first to tell you the company is bureaucratic and packed to the gills with people who don't know what the hell they're doing -- just like every other company that employs tens of thousands of people.
What I *am* saying is that this slideshow is looking at the past with "rose-colored hindsight" and I believe the motives are suspect at best. Draw your conclusions with a grain of salt. (Enough metaphor-abuse for today.)
Do like johnjones suggested -- go buy or check-out Showstopper and read it. It's interesting, informative, and it IS kind of funny. It's amazing they were able to produce anything at all. How's THAT conclusion for contrast with the slideshow? ;)
My favorite POV True Life Story (TM) was this image that took my brand new 40MHz 386 about 19 hours to render... then I bought a 387 coproc and render time dropped to 19 minutes. Luckily the rendering was for work purposes, so on the spot I justified the cost of the 387.
And then there was my big show of "working late" at a different (non-graphics-related) company... In reality I was just hanging around so I could set up everybody's PC to render fragments of my images overnight... I guess these days they'd fine you $400K and send you to jail for 30 days.
I did on a stock market charting application I worked on many years ago, but it was just something I was playing with. Back then POV ran so slowly it really wasn't worth it for my needs. You'd probably have to have some very complex visualization requirements before the processing overhead would be worth it. Maybe it's heightfield support would be cool to use, I suppose.
POV rules.
It's EASY to bring current machines to a grinding halt with POV-Ray. I was doing some weird experimentation last year... one image featured about forty intersecting glass planes and a bunch of fog and lighting effects. A very low quality rendering at only 640x480 on five networked machines ranging from 500MHz to 1.2GHz (with workloads split according to CPU power) took six days to render. A back-of-the-envelope calculation put a high-quality anti-aliased 1024x768 render at close to a month of round-the-clock processing.
I figure I'll go back and try this again when my slowest machine is 1.7GHz, I've got a couple of old 2.2GHz boxes laying around, and my main machine is 5GHz or so. Seriously.
Here's a cool POV wallpaper I submitted to skinz.org which I completed just before I gave up on that big project above...
http://www.skinz.org/skin.phtml?skinid=1131
And you deserve to be moderated "Offtopic".
Actually Microsoft did hire a German company to port COM services to UNIX. Unfortunately I've forgotten the name of the company which did the port. However, it was available for a number of years. In addition to the basic anti-MS sentiment in the UNIX community, I believe it didn't generate much interest because it became available roughly around the time the Internet was kicking into high gear (for which COM/DCOM is rather poorly suited) and the time Java was everybody's media darling. But they did deliver COM on UNIX. And yes, I get it. :)
This web services crap was basically smoke-and-mirrors. As someone else pointed out earlier in this topic, if MS or somebody else writes a CLR, suddenly, "Windows" programs will run on other operating systems without so much as a recompile. Given the DOJ problem which was looming large around the same time as the .NET unveiling, I think the "look at our web services" smoke-and-mirrors tactic intentionally diverted attention away from this potential portability option. Indeed, the portability concept was so important in their design phase, MS went as far as to segregate a great deal of highly-Windows-specific functionality in classes with names like Microsoft.xxxx (although this comprises only a tiny fraction of the full .NET model).
Don't get me wrong -- I like SOAP and have pushed for it (and used it, and early derivatives) inside my company for years -- but comparing .NET to "web services" is like comparing your desktop computer to one of those e-mail appliances for the computer illiterate. Sure it CAN do those things, but it's only a small fraction of the real story.
The .NET system object model is a top-down redesign of practically every part of the Windows API. Win32 is gone, GDI is gone, even COM/DCOM is gone (although still accessible). Instead you have this fantastically consistent MASSIVE system object model. Programming against this thing is pretty great. There are a few holes and a few decisions which strike me as stupid, but when you're talking about thousands of classes, everybody is bound to have a few pet peeves.
Unfortunately, it's hard to put an exciting marketing spin on a great new system-wide API strategy, and as I mentioned I don't think they wanted to play up the portability aspect at all, so we end up with the vague .NET marketing-speak hype machine.
There are other important and useful things in .NET, too, but to me the new comprehensive (and consistent) system object model is by far the most important (did I mention it was consistent?). People who compare it to Java either haven't compared them in-depth, are extremely Java-biased, or simply don't know what they're talking about. But that subject has been discussed to death in great detail all over the 'net, just search for it. (BTW, I was a professional Java programmer for over two years -- I'd say Java is merely "OK", not great -- I mention this as evidence that I'm not simply a MS-centric anti-Java nutcase, I did use it to make a living, for awhile.)
I think if .NET fails to gain momentum, it will be a great loss. Beyond the crappy marketing spin that seems to bury anything MS manages to do well, I think Microsoft itself may accidentally kill interest in .NET by only shipping it to the Great Unwashed as part of some new DRM-nazi consumer-unfriendly Windows -- call it WinDisney.
But from a purely technical perspective, .NET is pretty great.
God I wish I had mod points today. Yours was the only funny response in this total waste-of-space article...
No one? In fact, there is huge interest in how the code works. A very large number of the aftermarket chips and often things like A/F ratio controllers are directly dependent on how this code works. As an example, I race Vipers, and it was very important to know exactly what both ECUs were up to for optimizing the fuel map (I say both because the Viper V10 is really a V6+V4, right down to having a pair of ECUs). Just watching how the cells change (even using a dealership's $3000 monitoring tool) won't help much unless you can see the code. It's like watching Windows Media Player GPF. You sort of know what it did, but you have no idea why...
Also, I've never saved the URLs but I've seen quite a few discussion forums on the 'net dedicated to reverse-engineering the code in stock engine computers. The discussions commonly include chunks of assembly code. They're very serious, and they're very interested in the code itself.
On here, though, there's a bigger problem with people who know a lot less than they think they know.
Indeed... :P :)
Finally, this whole issue might be barking up the wrong tree. It may not even be the automobile manufacturers who keep this stuff "secret". I saw VW mentioned a bunch of times. A guy I know (who races Vipers) is an engineer who designs the chips for stock VW ECUs, and his company also writes the code -- and he doesn't work for VW. In other words, VW and other auto manufacturers do not necessarily own the code that runs their cars, it's often contracted out.
http://tpga.virtualave.net/game-links.htm
If you're a Microsoft type, MS is running a .NET "artificial life" sort of thing here:
http://www.gotdotnet.com/terrarium/
It would take some work, but you could use the old Fractint program's "disk video" mode to generate a series of 32767x32767 image files in a tiled layout, then write a simple app to chain them together and print them out.
Many moons ago in the college daze, my friends all jointly (pun intended) rented a big farm house which featured a giant white garage wall at the end of the long driveway. We'd planned to do use Fractint to create a series of sort of "paint-by-numbers" templates to cover this huge wall.
Never happened. Too much reggae, beer, sun, etc.
But still -- check out Fractint. They never got beyond version 20.x under DOS, but it's still one of the more flexible programs available for scripted automation... search for it in Google, there are a couple of dedicated sites out there.
Pager motors are one of the perferred devices for imparting motion in BEAM robotics. Look here or here, for starters -- there are tons of BEAM sites out there...
Probably a lot of "us", actually. Fixing a car, repairing a stove, or (as most people here probably know), digging around in the guts of a machine actually isn't that hard.
The point is that most people are too lazy to fix a car, fix a stove, or learn to use a PC beyond "The little blue 'W' starts Word when I poke it with the arrow."
The question shouldn't be, how easy is too easy, but rather, how lazy is too lazy? And I think we passed the "too lazy" point a long, long, long time ago.
I couldn't find anything that specifically said Linux, but that's how the /. article is written, and that seems to be the gist of the conversation so far. (Although I'm guessing that's probably the "other" slashdot effect, Linuxcentricity)...
The bottle design is nothing compared to the way Coke defends the little red-and-white swish. A few years back we did some multimedia apps for Coke, and a significant portion of the legal swamp we had to navigate centered on that read-and-white swish, which they amusingly refer to as their "dynamic ribbon device". And god, never, never say the word "Pepsi" inside their building or you're almost literally escorted to the street.
On the other hand (this is my on-topic-tie-in), the bottle design and the dread "dynamic ribbon device" are recognizably associated with Coke, whereas tabs are just an on-screen doodad that are relatively obvious. Hell, if Adobe really starts being a dick about this, just go back to button-strips where the current item's button is depressed. Same thing, mildly different look. Even the same code behind the scenes.
If you'd read the article, you'd know that Microsoft (and a number of other companies) cite Adobe's work as prior art. IANAL, but if I'm not mistaken, this implies they have an agreement or possibly even a license. (Amazing... I was able to read ten or fifteen useful comments before the Microsoft whining started.)
Think: magazine lead-time.
IIRC, PC Magazine has often quoted lead-times in the past of something amazing like four months. I'm sure it probably varies depending on the column in question, and it wouldn't surprise me to find that the lab tests in particular have a long lead-time. It's quite a bit of work to globally distribute a 200-page technical (well, pseudo-technical) print-publication...
C: REQ . 1 14 94 0 />
C:
C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'
C: </start>
C: END
Longer, more complicated examples are shown later, but this pretty clearly illustrates there probably won't be significant overhead.
You probably have that much unused blank space in the last packet of any file you send. Non-issue.
Might I ask what leads you to draw this conclusion?
A variable must be definitely assigned before its value can be obtained. The example
class Test
...
{
static void Main() {
int a;
int b = 1;
int c = a + b;
}
}
is invalid because it attempts to use the variable a before it is assigned a value.