The point of the university's policy isn't to get students to take them to class.
The point is to ensure all students have their own computer that is suitable for doing classwork, thereby eliminating the unfairness inherent when richer students can afford their own PC while poorer students have to compete for usage of underpowered lab computers.
If you're going to mandate that all students have their own computers, than it just makes sense to pick laptop over desktop. A laptop means you can work anywhere -- coffee shop, library, student center, dorm room, etc -- and it also means that if a teacher wants to do an interactive lesson now and then by stepping students through something on the computer, they can just ask students to bring their laptops to that lesson.
NOTE: This is a repost... I forgot to enter my credentials before posting the last one as AC. Please moderate this one and not the other one. Thanks.
This debate (about how to, or whether it's even possible to, viably replace fossil fuels with some other energy source) has appeared on Slashdot many times recently. I see a lot of people missing the big picture.
Fossil fuels are not a root energy source. They are just an efficient form of matter for storing collected energy. Energy only comes from one root source, and that's the transformation of matter to energy via spontaneous nuclear reaction.
Another thing worth noting: collecting and storing energy is a slow process compared to how quickly we use it up. That's why we're stuck. Fossil fuels took millions of years to store up their energy, and now we're using it up way faster than it took to store it. No solution we come up with will truly work unless it's faster to store up the energy than it is to use it up.
Now, on with the lesson... all energy on Earth came from one of three places: (1) nuclear energy emitted by the sun, (2) nuclear energy emitted by the earth's core, or (3) nuclear energy emitted by man-made nuclear reactors. That's it. There are no other significant root sources of energy here on our little planet.
Fossil fuels are basically an organic form of "solar cell plus battery", with the solar collection happening beneath the earth's atmosphere. They are the result of plants collecting the sun's radiation and storing in the form of organic matter (and of animals who eat the plants and each other for energy and then ultimately die and decompose). Even if you had a 100% efficient solar cell and a 100% perfect battery, it would take a long damn time to store up enough energy to run your car for an hour. A solar solution, where the solar collection takes place beneath the earth's atmosphere, is clearly not going to work.
The same problem is going to therefore exist with any approach involving organic compounds grown on the earth's surface, because all of those approaches are just variations on solar power. Almost all energy stored in organic matter on this planet is just collected solar energy, because the very top node of the food chain for almost living things is the sun. (Yes, there are technically some exceptions, such as microorganisms that live in the bottom of hot springs, but in that case they are consuming heat energy generated by the nuclear reaction of the earth's core).
The only viable solutions to the fossil fuel shortage are: (1) tapping into the earth's core, (2) somehow getting an energy collector beyond the earth's atmosphere and closer to the sun, or (3) using man-made nuclear reactors. Any approach that involves merely trying to extract stored solar energy from organic compounds grown on the earth's surface is doomed to failure because that process takes longer than the process of using up the energy.
I don't think it's fair to dismiss the decline in worker productivity as being solely attributal to a lack of prioritization. Even if you *know* which task is the most important you still have to context switch to process and prioritize incoming information.
Phone rings -- "yes, hello?.. no.. sorry.. yes.. i understand.. no i can't help you with that right now... ok.. i promise i'll look at it in a second."
[back to task]
Instant message -- "Dude!!! HRPROD22-NA01 is down, WTF?" "I know, I know, but I'm working on something else right now, it's next in the queue, i promise you."
and so on and so on, ad nauseum.
You know, it is possible to turn a phone's ringer off or to simply unplug the phone, just like it's possible to close down IM programs. If you need uninterrupted time to focus on a task requiring concentration, then just get rid of all possibly forms of distraction, shut down your e-mail client, lock yourself in your office and stick a post-it on the door saying "do not disturb -- e-mail only". Get your work done, and then go read queued-up e-mails later when you're done with your task.
There are some major probems (for gamers and game-makers) that plague the whole concept of PC gaming:
1. It's easier for PC games to be pirated, so it's less lucrative an enterprise.
2. Unlike a console, where every unit is identical hardware, PCs have infinitely many hardware combinations. It's impossible to test for them all. It's also impossible for non-technical / non-computer people to clearly find the answer to the question, "can my computer run this game well?"
3. Unlike a console, where you just put in the game and turn on the power, on your PC you first have to troubleshoot hardware lockups and software crashes, download and install drivers, install the game, configure your game controller, configure the game's performance settings, etc...
4. Sometimes, despite your best technically-competent troubleshooting efforts (eating up valuable hours of your life), a particular game will just refuse to run on a given PC without locking up or crashing or performing way slower than it should on that hardware. No one can figure out why, and none of the involved companies seem to care about fixing it, even when the problem is being experienced by boatloads of people camped out in online support forums.
5. Consoles are much cheaper than PCs.
6. PC game controllers are notorious for sucking compared to console game controllers. In my experience the only way to get a good game controller on a PC is to go buy a console controller and a USB converter box from Lik-Sang.
7. You can't easily play games on a PC on your big-screen TV while sitting on your couch in the den. Yes, I know it's possible to get a PC to display on a TV, but you have to be pretty technically-competent to do that. And then, it's not a comfortable way to use your PC for other common tasks you'd want to use it for, such as web browsing or typing up Word docs. And who wants to have to lug their PC back and forth all the time between a computer desk and the den?
8. PC hardware tends to have a higher failure rate, in my experience, due to the variety of non-integrated components from a variety of different sources, never tested together. Consoles are completely integrated designs, engineered to be a lot more durable.
9. PCs still have delicate little connectors with lots of pins that have to be carefully inserted the right way. Consoles always have tough connectors that can only fit one way, such that constant abuse by rowdy teens or children doesnt' destroy them.
I'm a developer on a product team at a huge software company. I've worked on 6 shipped releases of the same product, and I've worked within the same core feature areas for about 3 of those releases. More than half my time each release cycle is spent helping the feature team to identify user scenarios and optimize ways to solve them.
One of these core feature areas had frustratingly low usage and user-satisfaction ratings for years, until we got serious about feeling users' pain. It took lots of usability testing, using the right tests and asking the right questions, to finally expose a number of thematic problems users were having. It took even more usability testing on many iterations of designs to find approaches that really solved those problems well for most users.
The most educational lesson in all of this was that the things the product team suspected were user pain points were often not so, and the things the product team thought were fine were often problematic. In other words, the product team's very educated guesses were frequently wrong. These were people who had worked on the same product, on the same feature areas, for years, often looking into bugs and suggestions sent in by real end-users. If anyone was qualified to make an educated guess, it was these people, and yet they were often wrong.
We didn't make huge technical changes under the hood or introduce loads of new power-user functionality. We didn't just try to pile hacky bug fixes on top of the existing user experience. We didn't just try to optimize the performance or speed of the existing feature. We listened to what real users were telling us, and we squarely addressed their frustrations and confusions.
In the latest round of usability testing, the feature scored more than double the old user-satisfaction numbers, and there will be even more improvements made to address more user feedback gathered from that testing. We anticipate that when the next release ships, this feature area will have dramatically improved user-satisfaction and significantly reduced abandonment.
Now, I think about my Kubuntu installation on my PC at home, and about the variety of open-source applications that I use on it, and I skeptically wonder: is the same kind of feedback loop and concern for non-technical users applied in the open-source world? It seems like most developers of open-source software spend more time developing what they think is cool, or what other geeks might want, than trying to identify and eliminate the pain experienced by non-technical users. Even when some open-source projects (say, GNOME, KDE, or Firefox) are genuinely trying to make things easier for non-technical folk, they are often just flying blind, copying the UI of commercial software or taking wild personal guesses at what they think non-technical users want. Their guesses, although well-intentioned, are often completely wrong.
The moral of my story: you have to approach identifying user needs in a scientific way, or you'll almost never get it right. You have to perform your own research and perform it frequently as the design evolves/iterates. And no matter how crazy the results of that research seem to you, the software designer/developer, you should still trust in them.
This is just another example of a company not understanding the only real path to long-term successs (pleasing customers) and foolishly being tempted by the path that has been proven many times to lead to failure (forcing your own unwanted agenda upon customers).
In the end, market forces will teach Skype (just as they have taught so many other companies) that you can't place your own motives over customer satisfaction and survive in the long term.
Most people feel free to state their thoughts more directly, without sugar-coating, in e-mail. Many of these same people have been socially conditioned to not do that in face-to-face interactions. The same person who writes, "That way of doing it is wrong," to a coworker in e-mail would never think of uttering the same words verbally face-to-face, even if they genuinely hold that opinion.
On the flip side, most people mistakenly interpret e-mails as offensive because they mistakenly intrepret any sugar-uncoated message as a personal attack against them, regardless of the medium. The person who implemented the flawed approach, who is told, "That way of doing it is wrong," whether by e-mail or verbally, tends to mistkanely interpret the comment as a judgement on their performance rather than as a merely factual observation about the approach itself.
In other words, recipients of communication seem to always be eagerly looking for any opportunity to twist anything they hear or read into a negative judgement against their character. I don't know why that's the case, but it seems to be a general truth of human nature.
One theory of mine is that most people are fundamentally insecure and constantly worry about what other people think of them, and so they tend to anticipate that anything said by anyone must be about them and must be negative.
Well, multiplayer online gaming is the main appeal of the entire XBOX platform. If you want fun one-player adventure/action games, you buy something made by Nintendo. If you want as-good-as-it-gets-on-a-console multiplayer FPS games and multiplayer sports games, you get an XBOX.
And, unfortunately, the mainstream gaming crowd (which is unfortunately no longer the "geek gamer" crowd, but is in fact more like a bunch of drunken frat boy ricer wannabes who only play "cool" games) tends to gravitate toward the XBOX type of game library (lots of sports and multiplayer FPS type crap).
Well, in C++ at least, the best way is to employ a few simple techniques with extreme dilligence:
1. With each line of code, handle all possible failure cases, however unexpected or unlikely, gracefully in retail builds.
2. Do not use Asserts or empty catch blocks as your only form of "error handling".
3. Standardize on using either "function return values" or "exceptions" as your form of error passing up the stack in your codebase, and stick to it.
4. Never ignore exceptions or function return values unless it's intentional and for good reason. To indicate that choice, cast the function call explicitly to (void) to make it clear that ignoring the result is intentional, and add a comment documenting the reasoning.
You should never just have an Assert, ever, anywhere, because it will do exactly zilch in retail builds. You should *always* use asserts in combination with code that takes appropriate action in the event the assert happens to be violated for whatever reason. I'm actually much more of a fan of utilizing a carefully-crafted "Ensure" macro, which always evaluates the condition in retail builds, asserts if the condition evaluates to false, and then has either a "goto" label to jump to the relevant point (such as function clean-up and exit) or a function call pointer (which is the handler to execute upon failure).
Similarly, you should not just eat exceptions in most cases. Only do so when you're clearly being intentional about it, and add a comment to point out that the empty catch handler is intentional and explain why.
Standardizing the way you let functions pass errors back to their callers (either by function result, or by exception throwing) is important because when you get a mix of approaches you have to perform acrobatic coding to properly handle failure cases. Stick with one or the other. Obviously anything can throw an exception at any time, so you should always trap exceptions... but ideally each function traps its own exceptions and then returns an appropriate result code to its caller, or else all the functions in your app are "void" return type and throw exceptions containing error codes to communicate failure back to the caller.
Usually the programming language barrier is only a minor one. As long as you generally understand pretty common computer science and programming principles, you can pick up on any new language relatively quickly.
Usually the much larger barrier (to employees within a company switching to different projects/products) is all the "insider knowledge" about the architecture of the codebase, build process, runtime architecture, awarness of the existence of shared libraries/functions in the codebase that should be picked up and used rather than reinventing the wheel, etc. In my experience it can take anywhere from 6 months to 2 years for even a very competent and experienced developer to learn all that stuff well enough to be fully productive on a new codebase.
Also, in my experience, the biggest way to combat that is not with documentation, but through quality face-to-face education and quality code analysis/understanding tools such as Source Insight. Anything that allows you to more easily grep the architecture of the codebase and find existing helper functions across a huge codebase is a major help. And it's also my opinion that whenever a new project or development cycle begins, it would save all the newer developers a lot of pain and time if the seasoned developers on the project/product would proactively host educational training sessions outlining the high-level architecture of the code/build process/etc.
I personally think that the anti-DRM clause is much more sensible in the context of the Creative Commons licenses, than in software licenses. If you create valuable and useful content that other people want to be able to use (catchy tunes, funny animation, good icons), I would suggest you protect that _content_ by saying that it cannot be used in any content-protection schemes.
The problem with Linus's suggestion is that it won't result in DRM-free software and standards taking hold. If some content demands that it cannot be DRMed, but the vast majority of software and file formats require DRM, then guess what will happen? The content just won't get used/consumed, in favor of other similar content that permits DRMing. There's almost no motivation in this scheme for content producers to release their content under such a license, and there's no motivation for developers to write the software. Classic chicken-and-egg problem.
The GPL v3 approach breaks that chicken-and-egg scenario by forcing the creation and adoption of DRM-free software and standards. It guarantees that the software tools will get built first, even without the content, if necessary. Then when the tools reach critical mass, the content will naturally follow.
Of course, in the end, having *both* types of licenses (DRM-free content, and DRM-free software) would be great. But the DRM-free software license (GPL v3) has to come first.
While I share your frustration with users not tending to read or understand things, it's really not the user's fault. It's the fault of the software for not presenting text in ways that make it compelling for users to read it and for not phrasing text in layman's terms that ordinary people can understand.
For example, on the latest Vista Beta my friend was playing with on his laptop, it said...
"Do you want to allow Explorer.exe to do [some action]?"
Most users would be lost at the "explore.exe" part.:(
I completely agree. That's why I said that part of good usability is explaining things in layman's terms, rather than in techno-babble that grandma wouldn't understand. Microsoft has *never* done a good job of that, although it's certainly done a better job than most Linux distros have.
So then what your saying is... Providing the user with a very detailed & descriptive "Yes/No" dialog before installing Screensavers 2000 Plus, is "foolproof design"?
No, what I'm saying is that it would be foolproof if you provided the user with a dialog that says something like this:
WARNING! The program 'Screensavers 2000 Plus' is trying to write to a restricted area of your system. This may be an attempt to hijack your computer. Only grant this program access to carry out this operation if you are a computer expert and you truly know that this program has a legitimate reason to be attempting such an operation.
To grant 'Screensavers 2000 Plus' permission to carry out this operation, enter credentials for an administrative account below.
USERNAME: [ ]
PASSWORD: [ ]
[Grant Permission] [Deny Access]
Note that a visible timer on the dialog would count down for some reasonable duration (say, 10 seconds?) to force you to read the dialog before the "Grant Permission" button would be enabled.
If this kind of confirmation and education were built into the OS at every level, then yes, the system would be as foolproof as you can possibly make it. You have to admit that with a dialog like that, even Grandma can probably make the right choice.
Slashdot Mirror
The point of the university's policy isn't to get students to take them to class.
The point is to ensure all students have their own computer that is suitable for doing classwork, thereby eliminating the unfairness inherent when richer students can afford their own PC while poorer students have to compete for usage of underpowered lab computers.
If you're going to mandate that all students have their own computers, than it just makes sense to pick laptop over desktop. A laptop means you can work anywhere -- coffee shop, library, student center, dorm room, etc -- and it also means that if a teacher wants to do an interactive lesson now and then by stepping students through something on the computer, they can just ask students to bring their laptops to that lesson.
Just use a white-board or a series of post-it notes.
NOTE: This is a repost... I forgot to enter my credentials before posting the last one as AC. Please moderate this one and not the other one. Thanks.
This debate (about how to, or whether it's even possible to, viably replace fossil fuels with some other energy source) has appeared on Slashdot many times recently. I see a lot of people missing the big picture.
Fossil fuels are not a root energy source. They are just an efficient form of matter for storing collected energy. Energy only comes from one root source, and that's the transformation of matter to energy via spontaneous nuclear reaction.
Another thing worth noting: collecting and storing energy is a slow process compared to how quickly we use it up. That's why we're stuck. Fossil fuels took millions of years to store up their energy, and now we're using it up way faster than it took to store it. No solution we come up with will truly work unless it's faster to store up the energy than it is to use it up.
Now, on with the lesson... all energy on Earth came from one of three places: (1) nuclear energy emitted by the sun, (2) nuclear energy emitted by the earth's core, or (3) nuclear energy emitted by man-made nuclear reactors. That's it. There are no other significant root sources of energy here on our little planet.
Fossil fuels are basically an organic form of "solar cell plus battery", with the solar collection happening beneath the earth's atmosphere. They are the result of plants collecting the sun's radiation and storing in the form of organic matter (and of animals who eat the plants and each other for energy and then ultimately die and decompose). Even if you had a 100% efficient solar cell and a 100% perfect battery, it would take a long damn time to store up enough energy to run your car for an hour. A solar solution, where the solar collection takes place beneath the earth's atmosphere, is clearly not going to work.
The same problem is going to therefore exist with any approach involving organic compounds grown on the earth's surface, because all of those approaches are just variations on solar power. Almost all energy stored in organic matter on this planet is just collected solar energy, because the very top node of the food chain for almost living things is the sun. (Yes, there are technically some exceptions, such as microorganisms that live in the bottom of hot springs, but in that case they are consuming heat energy generated by the nuclear reaction of the earth's core).
The only viable solutions to the fossil fuel shortage are: (1) tapping into the earth's core, (2) somehow getting an energy collector beyond the earth's atmosphere and closer to the sun, or (3) using man-made nuclear reactors. Any approach that involves merely trying to extract stored solar energy from organic compounds grown on the earth's surface is doomed to failure because that process takes longer than the process of using up the energy.
Entire NYT Staff Held as "Enemy Combatants" at Guantanamo Bay
I don't think it's fair to dismiss the decline in worker productivity as being solely attributal to a lack of prioritization. Even if you *know* which task is the most important you still have to context switch to process and prioritize incoming information.
.. no.. sorry.. yes.. i understand.. no i can't help you with that right now... ok.. i promise i'll look at it in a second."
Phone rings -- "yes, hello?
[back to task]
Instant message -- "Dude!!! HRPROD22-NA01 is down, WTF?"
"I know, I know, but I'm working on something else right now, it's next in the queue, i promise you."
and so on and so on, ad nauseum.
You know, it is possible to turn a phone's ringer off or to simply unplug the phone, just like it's possible to close down IM programs. If you need uninterrupted time to focus on a task requiring concentration, then just get rid of all possibly forms of distraction, shut down your e-mail client, lock yourself in your office and stick a post-it on the door saying "do not disturb -- e-mail only". Get your work done, and then go read queued-up e-mails later when you're done with your task.
Why stop with "Mobuntu?"
I want to create a really screwed up version of Ubuntu so I can call it "FUBARuntu".
WARNING:
By logging onto the XBOX Live service, you understand and agree that you may from time to time hear Steve Ballmer threatening to "fucking kill" you.
No shit. That judge should be our president.
There are some major probems (for gamers and game-makers) that plague the whole concept of PC gaming:
1. It's easier for PC games to be pirated, so it's less lucrative an enterprise.
2. Unlike a console, where every unit is identical hardware, PCs have infinitely many hardware combinations. It's impossible to test for them all. It's also impossible for non-technical / non-computer people to clearly find the answer to the question, "can my computer run this game well?"
3. Unlike a console, where you just put in the game and turn on the power, on your PC you first have to troubleshoot hardware lockups and software crashes, download and install drivers, install the game, configure your game controller, configure the game's performance settings, etc...
4. Sometimes, despite your best technically-competent troubleshooting efforts (eating up valuable hours of your life), a particular game will just refuse to run on a given PC without locking up or crashing or performing way slower than it should on that hardware. No one can figure out why, and none of the involved companies seem to care about fixing it, even when the problem is being experienced by boatloads of people camped out in online support forums.
5. Consoles are much cheaper than PCs.
6. PC game controllers are notorious for sucking compared to console game controllers. In my experience the only way to get a good game controller on a PC is to go buy a console controller and a USB converter box from Lik-Sang.
7. You can't easily play games on a PC on your big-screen TV while sitting on your couch in the den. Yes, I know it's possible to get a PC to display on a TV, but you have to be pretty technically-competent to do that. And then, it's not a comfortable way to use your PC for other common tasks you'd want to use it for, such as web browsing or typing up Word docs. And who wants to have to lug their PC back and forth all the time between a computer desk and the den?
8. PC hardware tends to have a higher failure rate, in my experience, due to the variety of non-integrated components from a variety of different sources, never tested together. Consoles are completely integrated designs, engineered to be a lot more durable.
9. PCs still have delicate little connectors with lots of pins that have to be carefully inserted the right way. Consoles always have tough connectors that can only fit one way, such that constant abuse by rowdy teens or children doesnt' destroy them.
I'm a developer on a product team at a huge software company. I've worked on 6 shipped releases of the same product, and I've worked within the same core feature areas for about 3 of those releases. More than half my time each release cycle is spent helping the feature team to identify user scenarios and optimize ways to solve them.
One of these core feature areas had frustratingly low usage and user-satisfaction ratings for years, until we got serious about feeling users' pain. It took lots of usability testing, using the right tests and asking the right questions, to finally expose a number of thematic problems users were having. It took even more usability testing on many iterations of designs to find approaches that really solved those problems well for most users.
The most educational lesson in all of this was that the things the product team suspected were user pain points were often not so, and the things the product team thought were fine were often problematic. In other words, the product team's very educated guesses were frequently wrong. These were people who had worked on the same product, on the same feature areas, for years, often looking into bugs and suggestions sent in by real end-users. If anyone was qualified to make an educated guess, it was these people, and yet they were often wrong.
We didn't make huge technical changes under the hood or introduce loads of new power-user functionality. We didn't just try to pile hacky bug fixes on top of the existing user experience. We didn't just try to optimize the performance or speed of the existing feature. We listened to what real users were telling us, and we squarely addressed their frustrations and confusions.
In the latest round of usability testing, the feature scored more than double the old user-satisfaction numbers, and there will be even more improvements made to address more user feedback gathered from that testing. We anticipate that when the next release ships, this feature area will have dramatically improved user-satisfaction and significantly reduced abandonment.
Now, I think about my Kubuntu installation on my PC at home, and about the variety of open-source applications that I use on it, and I skeptically wonder: is the same kind of feedback loop and concern for non-technical users applied in the open-source world? It seems like most developers of open-source software spend more time developing what they think is cool, or what other geeks might want, than trying to identify and eliminate the pain experienced by non-technical users. Even when some open-source projects (say, GNOME, KDE, or Firefox) are genuinely trying to make things easier for non-technical folk, they are often just flying blind, copying the UI of commercial software or taking wild personal guesses at what they think non-technical users want. Their guesses, although well-intentioned, are often completely wrong.
The moral of my story: you have to approach identifying user needs in a scientific way, or you'll almost never get it right. You have to perform your own research and perform it frequently as the design evolves/iterates. And no matter how crazy the results of that research seem to you, the software designer/developer, you should still trust in them.
If prostitutes are really worried about their own safety, then why are they prostitutes in the first place?
Idiots!
This is just another example of a company not understanding the only real path to long-term successs (pleasing customers) and foolishly being tempted by the path that has been proven many times to lead to failure (forcing your own unwanted agenda upon customers).
In the end, market forces will teach Skype (just as they have taught so many other companies) that you can't place your own motives over customer satisfaction and survive in the long term.
Most people feel free to state their thoughts more directly, without sugar-coating, in e-mail. Many of these same people have been socially conditioned to not do that in face-to-face interactions. The same person who writes, "That way of doing it is wrong," to a coworker in e-mail would never think of uttering the same words verbally face-to-face, even if they genuinely hold that opinion.
On the flip side, most people mistakenly interpret e-mails as offensive because they mistakenly intrepret any sugar-uncoated message as a personal attack against them, regardless of the medium. The person who implemented the flawed approach, who is told, "That way of doing it is wrong," whether by e-mail or verbally, tends to mistkanely interpret the comment as a judgement on their performance rather than as a merely factual observation about the approach itself.
In other words, recipients of communication seem to always be eagerly looking for any opportunity to twist anything they hear or read into a negative judgement against their character. I don't know why that's the case, but it seems to be a general truth of human nature.
One theory of mine is that most people are fundamentally insecure and constantly worry about what other people think of them, and so they tend to anticipate that anything said by anyone must be about them and must be negative.
Blogger
Not Found
The requested URL was not found on this server. Please visit the Blogger homepage or the Blogger Knowledge Base for further assistance.
Home | About | Knowledge | Help | Developers | Gear | Privacy | Copyright © 1999 - 2005 Google
Either way though, it's still far cheaper than going to blockbuster (or any other video store)
That's not the point. It's the principle of the thing. It's about corporate integrity.
If they'll take a secretive punitive action like this one against paying customers, then they can't be trusted. Period.
Well, multiplayer online gaming is the main appeal of the entire XBOX platform. If you want fun one-player adventure/action games, you buy something made by Nintendo. If you want as-good-as-it-gets-on-a-console multiplayer FPS games and multiplayer sports games, you get an XBOX.
And, unfortunately, the mainstream gaming crowd (which is unfortunately no longer the "geek gamer" crowd, but is in fact more like a bunch of drunken frat boy ricer wannabes who only play "cool" games) tends to gravitate toward the XBOX type of game library (lots of sports and multiplayer FPS type crap).
Is this a sign of things to come for the other radio stations, that broadcast over the Internet?
Yes.
Will digital music distribution fall solely to giants like XM and iTunes?
Yes.
Next "Ask Slashdot", please!
Well, in C++ at least, the best way is to employ a few simple techniques with extreme dilligence:
1. With each line of code, handle all possible failure cases, however unexpected or unlikely, gracefully in retail builds.
2. Do not use Asserts or empty catch blocks as your only form of "error handling".
3. Standardize on using either "function return values" or "exceptions" as your form of error passing up the stack in your codebase, and stick to it.
4. Never ignore exceptions or function return values unless it's intentional and for good reason. To indicate that choice, cast the function call explicitly to (void) to make it clear that ignoring the result is intentional, and add a comment documenting the reasoning.
You should never just have an Assert, ever, anywhere, because it will do exactly zilch in retail builds. You should *always* use asserts in combination with code that takes appropriate action in the event the assert happens to be violated for whatever reason. I'm actually much more of a fan of utilizing a carefully-crafted "Ensure" macro, which always evaluates the condition in retail builds, asserts if the condition evaluates to false, and then has either a "goto" label to jump to the relevant point (such as function clean-up and exit) or a function call pointer (which is the handler to execute upon failure).
Similarly, you should not just eat exceptions in most cases. Only do so when you're clearly being intentional about it, and add a comment to point out that the empty catch handler is intentional and explain why.
Standardizing the way you let functions pass errors back to their callers (either by function result, or by exception throwing) is important because when you get a mix of approaches you have to perform acrobatic coding to properly handle failure cases. Stick with one or the other. Obviously anything can throw an exception at any time, so you should always trap exceptions... but ideally each function traps its own exceptions and then returns an appropriate result code to its caller, or else all the functions in your app are "void" return type and throw exceptions containing error codes to communicate failure back to the caller.
1. Ask slashdot for business plan. ....?
2.
3. PROFIT!
Just what does a slashdotting sound like?
"Ride of the Valkyries" (aka "Kill the Wabbit"), no doubt.
Usually the programming language barrier is only a minor one. As long as you generally understand pretty common computer science and programming principles, you can pick up on any new language relatively quickly.
Usually the much larger barrier (to employees within a company switching to different projects/products) is all the "insider knowledge" about the architecture of the codebase, build process, runtime architecture, awarness of the existence of shared libraries/functions in the codebase that should be picked up and used rather than reinventing the wheel, etc. In my experience it can take anywhere from 6 months to 2 years for even a very competent and experienced developer to learn all that stuff well enough to be fully productive on a new codebase.
Also, in my experience, the biggest way to combat that is not with documentation, but through quality face-to-face education and quality code analysis/understanding tools such as Source Insight. Anything that allows you to more easily grep the architecture of the codebase and find existing helper functions across a huge codebase is a major help. And it's also my opinion that whenever a new project or development cycle begins, it would save all the newer developers a lot of pain and time if the seasoned developers on the project/product would proactively host educational training sessions outlining the high-level architecture of the code/build process/etc.
I personally think that the anti-DRM clause is much more sensible in the context of the Creative Commons licenses, than in software licenses. If you create valuable and useful content that other people want to be able to use (catchy tunes, funny animation, good icons), I would suggest you protect that _content_ by saying that it cannot be used in any content-protection schemes.
The problem with Linus's suggestion is that it won't result in DRM-free software and standards taking hold. If some content demands that it cannot be DRMed, but the vast majority of software and file formats require DRM, then guess what will happen? The content just won't get used/consumed, in favor of other similar content that permits DRMing. There's almost no motivation in this scheme for content producers to release their content under such a license, and there's no motivation for developers to write the software. Classic chicken-and-egg problem.
The GPL v3 approach breaks that chicken-and-egg scenario by forcing the creation and adoption of DRM-free software and standards. It guarantees that the software tools will get built first, even without the content, if necessary. Then when the tools reach critical mass, the content will naturally follow.
Of course, in the end, having *both* types of licenses (DRM-free content, and DRM-free software) would be great. But the DRM-free software license (GPL v3) has to come first.
While I share your frustration with users not tending to read or understand things, it's really not the user's fault. It's the fault of the software for not presenting text in ways that make it compelling for users to read it and for not phrasing text in layman's terms that ordinary people can understand.
For example, on the latest Vista Beta my friend was playing with on his laptop, it said...
:(
"Do you want to allow Explorer.exe to do [some action]?"
Most users would be lost at the "explore.exe" part.
I completely agree. That's why I said that part of good usability is explaining things in layman's terms, rather than in techno-babble that grandma wouldn't understand. Microsoft has *never* done a good job of that, although it's certainly done a better job than most Linux distros have.
So then what your saying is... Providing the user with a very detailed & descriptive "Yes/No" dialog before installing Screensavers 2000 Plus, is "foolproof design"?
No, what I'm saying is that it would be foolproof if you provided the user with a dialog that says something like this:
WARNING!
The program 'Screensavers 2000 Plus' is trying to write to a restricted area of
your system. This may be an attempt to hijack your computer. Only grant this program
access to carry out this operation if you are a computer expert and you truly know that
this program has a legitimate reason to be attempting such an operation.
To grant 'Screensavers 2000 Plus' permission to carry out this operation, enter credentials for an administrative account below.
USERNAME: [ ]
PASSWORD: [ ]
[Grant Permission] [Deny Access]
Note that a visible timer on the dialog would count down for some reasonable duration (say, 10 seconds?) to force you to read the dialog before the "Grant Permission" button would be enabled.
If this kind of confirmation and education were built into the OS at every level, then yes, the system would be as foolproof as you can possibly make it. You have to admit that with a dialog like that, even Grandma can probably make the right choice.