The latter two questions aren't relevant. The first one is, slightly.
First note that in functional langauges (Lisp), you normally just have "lists", and stay away from arrays. Those "lists" are called "linked lists" in imperative languages (C++), which serves as a reminder of how they're probably implemented (in a functional language, the programmer is encouraged to think at a higher level, not caring how the implementation is done).
As ThinkGeek mentioned, an array is generally a contiguous block of memory, while a list chains separate small blocks of memory with pointers between them.
Those implementation differences lead to major performance differences for kinds of operations you can do:
Read first element: array fast, list fast
Read last element: array fast, list slow (or fast, if doubly-linked)
Read Nth element: array fast, list slow
Insert at middle: array slow, list fast
Insert at end: array slow (or fast, if realloc), list fast
Search for member: array fast (if sorted), list slow (even if sorted)
When I say "slow" above, I mean it takes more time depending on how much stuff the container holds (O(N)), rather than taking a fixed amount of time (O(1)). The big advantage of an array is speed to access items in the center- you can go to the Nth spot directly, while in a list you'd have to walk there sequentially from the beginning. When inserting items or otherwise editing the container, however, a list is faster.
As an aside, both Java and the C++ STL library use the word "vector" to mean an array represented as a class. This is incorrect- by definition, vectors are numbers, and support operations like addition and multiplication. If something cannot be multiplied times two, then it's not a vector.
The low barriers to software updates also make software a less rigorous practice than hardware design.
Which is why hardware manufacturers have tried to adopt some of the update advantages of software. Intel learned from their fdiv bug and gave their new chips an ability to be patched in software. The CPU can be loaded with a list of instructions+operands known to be dangerous, along with an alternative series of instructions that can be executed in its place. (actually, this change was in the works before fdiv arose).
Your use of "gaming world" is somewhat inaccurate. You're talking about console and arcade hardware, which is the majority of games, but far from all.
Games running on desktop PCs still crash often, and players don't mind much.
The most important thing though is robust software design.
No, the most important thing is limited system variation. The real reason your GameCube stuff doesn't crash badly is because you have exactly one piece of software that will run on exactly one kind of hardware.
In our games, we all code exception handlers for the software, so that a single errant NULL pointer doesn't bring the whole thing down with a
Don't think that PC software authors don't use exception handlers. It's because multitasking PCs are more flexible and allow users to attempt tasks that aren't necessarily within the capabilties of the system. Console games have only one target platform, so there's no need to allow tasks whose success is uncertain.
I think the people who buy those shirts are junior admins. The senior types don't often want to appear in T shirts.
Also, the lower-level staff is on the front lines of responding to end-user needs. They're more likely to field questions about "Which new NVidia card should I buy?". After all, they're more numerous, more accessible, have more unscheduled time, and have more direct experience with the bowels of consumer-grade hardware (as opposed to designing backoffice architexture, a more important task for the senior guys)
but things in LOTR that have the heaviest computer manipulation are things that are magic or take place in the ring's netherworld
That's just completely untrue. What about the thousands of warriors at the Battle of Helm's Deep? The majestic fortresses, the grotesque oliphaunts?
LOTR was filled with CG from head to toe, for subjects neither explicitly magical nor netherworldly. (I won't go into Golum- one could say he's magic too, instead of simply malnourished)
The CG needs for an Evangelion movie (an ill-starred project if there ever was one) will be similar to LOTR. They'll have to create realistic depictions of huge, improbable structures for the actors to be projected in front of. Then they'll have to build large creatures which look natural when stationary (like the Ents) and command them to move in ways that are smooth and life-like, but far from human-like.
You ought to work tech support some time. There are real costs associated with software bugs.
Real but small. Having worked both support and development, I also know that there are real costs to fixing bugs- especially in a product that's already released.
One entire day of downtime from Melissa was a very "real cost". It sure didn't hurt the market share of Microsoft's emailers in the corporate world though, which is why they were able to get another entire day of downtime one year later from Code Red.
This code freeze lasted for SIX MONTHS. That's a HUGE risk for a software company
That would've been a "HUGE risk", if it had happened. 1 It also undermines any arguments based on "customers are lemmings that will buy anything we dangle in front of them".
That's a strawman. The actual argument is that "customers will accept many crashes in their software", and it has been empirically demonstrated by the large number of crashes still occuring in recent software. (Microsoft and Apple's desktops still crash frequently enough that it's no surprise. Redhat's does as well).
It seems well accepted that Win2k was more stable than WinXP. That sure looks like a case of more features (to drive a big round of upgrades) outweighing stability.
when I work with a senior admin within the organization, I find they are the "NO" people.
Senior admins are a small minority of software customers.
Well, the B5 effort was hijacked by all sorts of external effects- unpredictable actor availability (3 main characters left unexpectedly) and an uncertain number of seasons.
Yes, Straczynski planned for 5 seasons originally- but towards the end of season 4, it really looked like #5 wouldn't get made (the current network was dropping it, and no one was found to take it up until the last minute)
So, he squeezed many of the concluding events into the 4th season, in case it turned out to be the final one. That's why the main villians were all vanquished in the 4th season, and the 5th opened up with discovery of new (servitor) monsters that had been hidden under rocks up till then.
So, it's really understandable that the 5th season seemed lacking- it's best parts were squeezed into earlier episodes.
It's going to take a breakthrough on the order of Newton to make Software Engineering as reliable a discipline as Civil Engineering.
The reliablity of today's Civil Engineering comes not from deep theoretical understanding ala Newton- it's really just the same "build, crash, repeat" method those Freemasons have been using for 1000 years.
Now that we've had centuries of experience at building similar kinds of structures, most of the kinks have been worked out. Those rare CivEng projects that break new ground still have a high risk of unexpected failures. (A 4000% cost overrun is a failure)
Civil Engineering still uses empirical testing to decide if a new technique is reliable, as does "Software Engineering". You just notice it more in SE because that field has more opportunities for innovation and much, much fewer penalties when an experiment fails.
JUnit is a step in the right direction, but there's still a long way to go.
JUnit is a step down a curving road to a dead-end. It won't take us to an ultimate solution (but it will provide benefit in the near-term future). That's because it's not a system to help formally prove code is correct (which some unpopular languages support to small degrees)- instead, Unit Testing is just a way to automate "build, crash, repeat" empirical testing.
Most people I work with in the IT industry would give their arm, leg, spleen, right lung, part of their left lung, lower intestine, and maybe even their occipital lobes for a reliable system that WORKS.
No, that's the myth!
Show me one off these voluntarily maimed admins, who carved out all his organs hoping for improved software. They don't exist.
(More realistically, show me one who sacrificed 30% of his annual salary for better software. He also doesn't exist)
True, from day to day, everyone wishes that that jobs were easier.
"I wish customers would read the web page, instead of calling me for phone support"
"I wish we had a train to Chicago instead of me driving this truck for 7 hour streches"
"I wish the servers I maintained didn't crash"
However, if those people were fully rational, they'd understand that as soon as their wish comes true, they're out of a job. (An enlightened person will welcome the change as better for the world at large; a luddite would whine, scream, and throw boots in the gears)
And anyway, IT admins are not the consumers of software. They're not the ones who drive the buyer-seller economy. The actual consumers are other people in the company- and from their perspective, the IT staff are an expense attached to buying the software.
GNU is a viral license. If you incorporate GNU code into your projects the price you pay is the loss of control the projects.
That's not what "viral" means. A virus is a creature which infects cells with it's own DNA. It's not something that the victim decides to willingly accept, in exchange for some benefit. It's purely an attacker- a parasite.
If you talk about it as "paying the price", then the correct biological analogy is a "symbiote". You pay something, and get something back for it. This is how ALL software licenses work. The GPL isn't special in this regard- it just requires compensation in code, instead of money.
If those things were done on the server, it would increase network usage for every player, degrading the performance of the entire game.
Somewhat more reasonable would be including code in the client to create fake enemy images behind solid surfaces...
However, if the game client software was smart enough to do that (meaning it could calculate for itself which walls totally blocked off your view of the area), then it might as well just not send 100% concealed enemy pictures to the video card.
The kinds of driver-hacks I'm talking about are possible because the game relies on the video card to decide if an enemy is visible to the player, rather than computing that itself.
(Even better would be for the server to restrict transmitting enemy data for things you cannot see. The original Quake did this- I don't know why they took it out. This would have a side effect of making 40 player games smoother...)
Yes- but the special features can often be toggled with a keystroke. Push a button to enable "x-ray vision", then go back to normal mode after you've located the enemies.
There certainly are cheats for RTCW, and the sequel.
In fact, one of the best cheats for an FPS is "wallhacking". You install a modified graphics driver that negates the Z value of drawn objects.
That way, distant things appear in front of nearby ones, instead of the reverse. So you can prepare to fire at an enemy before he's even in view. (Especially powerful with indirect weapons, like a rocket launcher with large explosions)
I've seen screenshots of Z-inversion wallhacking in RTCW:ET, but don't remember where they went. Here's one screenshot of a related hack: the alpha-blended trick, where the video driver is modified to make everything translucent.
Cheating based on videodrivers can effect many different games- anything where seeing more clearly could be an advantage.
3. Must be in the dark. 4. Can't walk in front without casting shadow/being blinded. 5. Uses more floor space. 6. Project bulb needs more frequent replacement than LCD screens (not recommended to run them 24/7)
All in all, a projector just feels less space-age than 3 meters of LCD pixels.
It's not religosity, but legality. To obey copyright laws, they should comply with the license, which means that any binaries must come with the source used to build them. Not patches which can be applied against some other source, and not code for some unspecified later version of the software. All users must get the exact source used to build the binaries they have. (Or "a written offer valid for 3 years", blah blah blah...)
And, it's not just a matter of legal compliance either. Real users are hurt by this- even though the mail archives aren't searchable, it's easy to find cases of the "source code" failing to build because it references external sites that no longer exist. (Which is possibly discouraging more developers from assisting in the project, if the code doesn't seem like a stable place to work)
Open Source is supposed to be about empowering users to contribute their own programming skills to projects they need. How could someone submit a bug fix for OpenZaurus, if she can't even know that the source code she downloaded is the same stuff that's running on the PDA?
kergoth is trying to track the handhelds.org kernels,
The best solution for that, of course, would be to work with them, as part of their tree. But prehaps they're not amenable. (Although they manage to give OpenZaurus a prominent link on their webpages)
However, needing a kernel from a specific source doesn't explain why the buildroot pulls in code for all kinds of things from a dozen places on the internet, or why he can't just make a tarball of the patched-together files whenever a binary release is prepared.
The most "reliable" problem is that TCP sockets freeze up after getting a burst of more than 100k in a short period. The connection stays open, but no data will ever flow through it again.
This makes syncing and many other useful functions impossible.
(However, UDP and ping never fail, and the controls for getting the card initialized at all are easier in OZ)
The worst danger is that you'll lose power in the first quarter-second of the flashing process, turning the unit into a small brick until you mail it in for repair. (And depending on the kind of ROM you're flashing, even this problem might be impossible. It's only a concern using a 3rd party ROM)
Of course, a simultaneous failure of your AC power and battery is impossible on its own. Which is why the flashing software refuses to run unless AC is attached.
But the thing is, the Zaurus (US version, SL-5500) includes Linux as it's original OS. Neither the official Sharp ROM, nor OpenZaurus, is competitive with Palm or PocketPC for end user convenience and stability.
So, switching in an amateur Linux for the professional one is a fairly minor change. It makes some definite improvements, but also has obvious shortcomings.
Overall, a desktop GNU/Linux like Redhat, SUSE, or Debian is more stable and userfriendly than the Linuxes I've seen on PDAs. (And ironically, the average person is much more forgiving when a desktop crashes than when their PDA flips out)
Slashdot Mirror
First note that in functional langauges (Lisp), you normally just have "lists", and stay away from arrays. Those "lists" are called "linked lists" in imperative languages (C++), which serves as a reminder of how they're probably implemented (in a functional language, the programmer is encouraged to think at a higher level, not caring how the implementation is done).
As ThinkGeek mentioned, an array is generally a contiguous block of memory, while a list chains separate small blocks of memory with pointers between them.
Those implementation differences lead to major performance differences for kinds of operations you can do:
When I say "slow" above, I mean it takes more time depending on how much stuff the container holds (O(N)), rather than taking a fixed amount of time (O(1)). The big advantage of an array is speed to access items in the center- you can go to the Nth spot directly, while in a list you'd have to walk there sequentially from the beginning. When inserting items or otherwise editing the container, however, a list is faster.
As an aside, both Java and the C++ STL library use the word "vector" to mean an array represented as a class. This is incorrect- by definition, vectors are numbers, and support operations like addition and multiplication. If something cannot be multiplied times two, then it's not a vector.
He means it can be eliminated by inverting the conditional to be "if not A then C" instead of "if A then NOTHING else C", as it is now.
The low barriers to software updates also make software a less rigorous practice than hardware design.
Which is why hardware manufacturers have tried to adopt some of the update advantages of software. Intel learned from their fdiv bug and gave their new chips an ability to be patched in software. The CPU can be loaded with a list of instructions+operands known to be dangerous, along with an alternative series of instructions that can be executed in its place. (actually, this change was in the works before fdiv arose).
Your use of "gaming world" is somewhat inaccurate. You're talking about console and arcade hardware, which is the majority of games, but far from all.
Games running on desktop PCs still crash often, and players don't mind much.
The most important thing though is robust software design.
No, the most important thing is limited system variation. The real reason your GameCube stuff doesn't crash badly is because you have exactly one piece of software that will run on exactly one kind of hardware.
In our games, we all code exception handlers for the software, so that a single errant NULL pointer doesn't bring the whole thing down with a
Don't think that PC software authors don't use exception handlers. It's because multitasking PCs are more flexible and allow users to attempt tasks that aren't necessarily within the capabilties of the system. Console games have only one target platform, so there's no need to allow tasks whose success is uncertain.
Ok
I think the people who buy those shirts are junior admins. The senior types don't often want to appear in T shirts.
Also, the lower-level staff is on the front lines of responding to end-user needs. They're more likely to field questions about "Which new NVidia card should I buy?". After all, they're more numerous, more accessible, have more unscheduled time, and have more direct experience with the bowels of consumer-grade hardware (as opposed to designing backoffice architexture, a more important task for the senior guys)
but things in LOTR that have the heaviest computer manipulation are things that are magic or take place in the ring's netherworld
That's just completely untrue. What about the thousands of warriors at the Battle of Helm's Deep? The majestic fortresses, the grotesque oliphaunts?
LOTR was filled with CG from head to toe, for subjects neither explicitly magical nor netherworldly. (I won't go into Golum- one could say he's magic too, instead of simply malnourished)
The CG needs for an Evangelion movie (an ill-starred project if there ever was one) will be similar to LOTR. They'll have to create realistic depictions of huge, improbable structures for the actors to be projected in front of. Then they'll have to build large creatures which look natural when stationary (like the Ents) and command them to move in ways that are smooth and life-like, but far from human-like.
You ought to work tech support some time. There are real costs associated with software bugs.
Real but small. Having worked both support and development, I also know that there are real costs to fixing bugs- especially in a product that's already released.
One entire day of downtime from Melissa was a very "real cost". It sure didn't hurt the market share of Microsoft's emailers in the corporate world though, which is why they were able to get another entire day of downtime one year later from Code Red.
This code freeze lasted for SIX MONTHS. That's a HUGE risk for a software company
That would've been a "HUGE risk", if it had happened. 1 It also undermines any arguments based on "customers are lemmings that will buy anything we dangle in front of them".
That's a strawman. The actual argument is that "customers will accept many crashes in their software", and it has been empirically demonstrated by the large number of crashes still occuring in recent software. (Microsoft and Apple's desktops still crash frequently enough that it's no surprise. Redhat's does as well).
It seems well accepted that Win2k was more stable than WinXP. That sure looks like a case of more features (to drive a big round of upgrades) outweighing stability.
when I work with a senior admin within the organization, I find they are the "NO" people.
Senior admins are a small minority of software customers.
Well, the B5 effort was hijacked by all sorts of external effects- unpredictable actor availability (3 main characters left unexpectedly) and an uncertain number of seasons.
Yes, Straczynski planned for 5 seasons originally- but towards the end of season 4, it really looked like #5 wouldn't get made (the current network was dropping it, and no one was found to take it up until the last minute)
So, he squeezed many of the concluding events into the 4th season, in case it turned out to be the final one. That's why the main villians were all vanquished in the 4th season, and the 5th opened up with discovery of new (servitor) monsters that had been hidden under rocks up till then.
So, it's really understandable that the 5th season seemed lacking- it's best parts were squeezed into earlier episodes.
In George Orwell's 1984, TELEVISION watches YOU!
(And no, it can't be turned off. Some people can face it against the wall, though)
It's going to take a breakthrough on the order of Newton to make Software Engineering as reliable a discipline as Civil Engineering.
The reliablity of today's Civil Engineering comes not from deep theoretical understanding ala Newton- it's really just the same "build, crash, repeat" method those Freemasons have been using for 1000 years.
Now that we've had centuries of experience at building similar kinds of structures, most of the kinks have been worked out. Those rare CivEng projects that break new ground still have a high risk of unexpected failures. (A 4000% cost overrun is a failure)
Civil Engineering still uses empirical testing to decide if a new technique is reliable, as does "Software Engineering". You just notice it more in SE because that field has more opportunities for innovation and much, much fewer penalties when an experiment fails.
JUnit is a step in the right direction, but there's still a long way to go.
JUnit is a step down a curving road to a dead-end. It won't take us to an ultimate solution (but it will provide benefit in the near-term future). That's because it's not a system to help formally prove code is correct (which some unpopular languages support to small degrees)- instead, Unit Testing is just a way to automate "build, crash, repeat" empirical testing.
No, that's the myth!
Show me one off these voluntarily maimed admins, who carved out all his organs hoping for improved software. They don't exist.
(More realistically, show me one who sacrificed 30% of his annual salary for better software. He also doesn't exist)
True, from day to day, everyone wishes that that jobs were easier.
- "I wish customers would read the web page, instead of calling me for phone support"
However, if those people were fully rational, they'd understand that as soon as their wish comes true, they're out of a job. (An enlightened person will welcome the change as better for the world at large; a luddite would whine, scream, and throw boots in the gears)"I wish we had a train to Chicago instead of me driving this truck for 7 hour streches"
"I wish the servers I maintained didn't crash"
And anyway, IT admins are not the consumers of software. They're not the ones who drive the buyer-seller economy. The actual consumers are other people in the company- and from their perspective, the IT staff are an expense attached to buying the software.
What do you mean by "Sharp's yet-to-ship 5600"?
Do you mean you've order one, but it hasn't arrived yet? Because it's certainly not difficult to order one of those. (They say it's in stock).
No need to go through a speciality importer such as for the more exotic Zauruses.
OpenZaurus still runs as root with a blank password.
(It has exactly the same remote vulnerabilities as the normal Zaurus ROM- after all, it has to be compatible with the same desktop sync program)
As for it being viral, if you don't agree to the terms of the license, you are free to avoid building your work on top of code licensed in this way.
Which is precisely against the definition of "viral". When a virus infects something, the victim doesn't get a choice.
Biological terms more appropriate for the GPL include both cancerous and symbiotic.
GNU is a viral license. If you incorporate GNU code into your projects the price you pay is the loss of control the projects.
That's not what "viral" means. A virus is a creature which infects cells with it's own DNA. It's not something that the victim decides to willingly accept, in exchange for some benefit. It's purely an attacker- a parasite.
If you talk about it as "paying the price", then the correct biological analogy is a "symbiote". You pay something, and get something back for it. This is how ALL software licenses work. The GPL isn't special in this regard- it just requires compensation in code, instead of money.
If those things were done on the server, it would increase network usage for every player, degrading the performance of the entire game.
Somewhat more reasonable would be including code in the client to create fake enemy images behind solid surfaces...
However, if the game client software was smart enough to do that (meaning it could calculate for itself which walls totally blocked off your view of the area), then it might as well just not send 100% concealed enemy pictures to the video card.
The kinds of driver-hacks I'm talking about are possible because the game relies on the video card to decide if an enemy is visible to the player, rather than computing that itself.
(Even better would be for the server to restrict transmitting enemy data for things you cannot see. The original Quake did this- I don't know why they took it out. This would have a side effect of making 40 player games smoother...)
Yes- but the special features can often be toggled with a keystroke. Push a button to enable "x-ray vision", then go back to normal mode after you've located the enemies.
gameworld mechanics that will prevent robots from playing better than human beings.
Oh! Oh! I've got one!
Chess!
And how about... Go?
There certainly are cheats for RTCW, and the sequel.
In fact, one of the best cheats for an FPS is "wallhacking". You install a modified graphics driver that negates the Z value of drawn objects.
That way, distant things appear in front of nearby ones, instead of the reverse. So you can prepare to fire at an enemy before he's even in view. (Especially powerful with indirect weapons, like a rocket launcher with large explosions)
I've seen screenshots of Z-inversion wallhacking in RTCW:ET, but don't remember where they went. Here's one screenshot of a related hack: the alpha-blended trick, where the video driver is modified to make everything translucent.
Cheating based on videodrivers can effect many different games- anything where seeing more clearly could be an advantage.
3. Must be in the dark.
4. Can't walk in front without casting shadow/being blinded.
5. Uses more floor space.
6. Project bulb needs more frequent replacement than LCD screens (not recommended to run them 24/7)
All in all, a projector just feels less space-age than 3 meters of LCD pixels.
GPL religosity aside,
It's not religosity, but legality. To obey copyright laws, they should comply with the license, which means that any binaries must come with the source used to build them. Not patches which can be applied against some other source, and not code for some unspecified later version of the software. All users must get the exact source used to build the binaries they have. (Or "a written offer valid for 3 years", blah blah blah...)
And, it's not just a matter of legal compliance either. Real users are hurt by this- even though the mail archives aren't searchable, it's easy to find cases of the "source code" failing to build because it references external sites that no longer exist. (Which is possibly discouraging more developers from assisting in the project, if the code doesn't seem like a stable place to work)
Open Source is supposed to be about empowering users to contribute their own programming skills to projects they need. How could someone submit a bug fix for OpenZaurus, if she can't even know that the source code she downloaded is the same stuff that's running on the PDA?
kergoth is trying to track the handhelds.org kernels,
The best solution for that, of course, would be to work with them, as part of their tree. But prehaps they're not amenable. (Although they manage to give OpenZaurus a prominent link on their webpages)
However, needing a kernel from a specific source doesn't explain why the buildroot pulls in code for all kinds of things from a dozen places on the internet, or why he can't just make a tarball of the patched-together files whenever a binary release is prepared.
What network hardware are you using?
DCF-650W.
The most "reliable" problem is that TCP sockets freeze up after getting a burst of more than 100k in a short period. The connection stays open, but no data will ever flow through it again.
This makes syncing and many other useful functions impossible.
(However, UDP and ping never fail, and the controls for getting the card initialized at all are easier in OZ)
The worst danger is that you'll lose power in the first quarter-second of the flashing process, turning the unit into a small brick until you mail it in for repair. (And depending on the kind of ROM you're flashing, even this problem might be impossible. It's only a concern using a 3rd party ROM)
Of course, a simultaneous failure of your AC power and battery is impossible on its own. Which is why the flashing software refuses to run unless AC is attached.
It's somewhat the same, actually.
But the thing is, the Zaurus (US version, SL-5500) includes Linux as it's original OS. Neither the official Sharp ROM, nor OpenZaurus, is competitive with Palm or PocketPC for end user convenience and stability.
So, switching in an amateur Linux for the professional one is a fairly minor change. It makes some definite improvements, but also has obvious shortcomings.
Overall, a desktop GNU/Linux like Redhat, SUSE, or Debian is more stable and userfriendly than the Linuxes I've seen on PDAs. (And ironically, the average person is much more forgiving when a desktop crashes than when their PDA flips out)