Does a mechanic cause $5000 worth of damage when he points out that your axle is broken and needs replacement?
Can you cause damage to a system that has intrinsic vulnerabilities?
Obviously people taking advantage of disclosed vulnerabilities should be punished under applicable laws (as with simple copyright violation) for whatever damages they caused, but I tend to agree that you can't really pin damages on the discloser.
Now some other b.s. charge about reckless endangerment or speech issues, but probably not damages.
If you've got old windows software (office productivity especially, Quicken 3.0 or whatever) donate it to wine. I threw some of my old CD's away and made a post about it on my blog (*extremely* low traffic blog) and their wine ninjas found it and one of the project dudes mailed me asking to send them the CD's. Unfortunately I had already thrown them away, but now I make it a point to tell people throwing away old software what you can do with it.
"""One of the biggest problems with text based communication is that people simply can't write well."""
s/write/read/g
I find that the more I write the less likely people are to take the time to understand (while dealing with processing large quantities of text and information). Putting in sarcasm, double-entendre's and the like are counterproductive at best, and firing offenses at worst. For informal communications, the smiley can be helpful.
Now if only I could break myself of the habit of referring to "teh internets" and their "evil haxors" in meetings....
The Debian Policy Manual codifies the whys and hows of basic unix operation. Some of it is debian-specific, but debian is a pretty big chunk of "the world of linux" and their policy manual reflects a whole bunch of that common / shared knowledge. What goes in "/var"? How to be sane with "/etc/foo" v. "~/.foo/"? Cron + Init. Basically if a package does something "not in the debian way", then their policy documentation is designed to be able to point to a section and say: "we'd really prefer something like the following..."
It's a great resource. Also if you really feel like a challenge, grab an older version of debian and do an install. I thought I knew my PC until it blew up back in '99 and I (being tired of windows) installed debian. And proceeded to have to take out every piece of hardware (including memory sticks and floppy drives), putting them back in one by one until I could figure out what was causing XYZ to work or not work. Good times, and you learn a lot.
...are two examples of where something like this was implemented. In AvP, there was a multiplayer mode where the human or the predator had to fight off a bunch of aliens. The aliens died easy, but they re-spawned continuously and could jump onto / off of the walls and stuff. Each class had different vision modes which influenced how you played as well. Good times.
Tribes2 also had the idea of radically different armor classes and a greater ability to choose your role (from Heavy + Mortar + Missiles to Light + Sniper + Cloaking)... coupled with the different game-play modes (Defend the Base v. Conquer the Base, then switch sides), you got pretty close.
The neat thing about Tribes2 was how time and cooperation was a factor. If you had 6 heavies, they would take 20 minutes to get from one side of the map to the other. If you had 5 heavies + 1 light + a Troop Carrier, you'd get across in 1 minute. So there was this time-based and skill-based economic incentive for people to play differing roles (are you good at base-raiding? be a heavy. suck at it? pilot troop carriers. sneaky? shocklance and cloak-pack. twitchy? light armor + laser-rifle. not enough flag-runners? suit up with a light + energy. too many flag-runners? grab a medium armor and missles to support your flag-runners.) *sniff*... to go back in time and play Tribes2 again would be a little slice of heaven.
...except for the ability to access / look at the Javascript object for a dom node in a nice convenient way (ie: document.getElementById('foo') in Firebug Console, v. dir( $('foo') ), v. domInpsect: 'foo'). I'm pretty sure there's a way to get at the JS view of the dom node with firebug, but it's not very straightforward by default.
But you (I) certainly use the Dom inspector less after Firebug, and all hail Joe and his cohorts!!:^)
"""He responded, "I just need to be able to connect to a modem and dial out.""""
Engineer says: "B.S. - Be Specific", what is your app, what is the requirement, why do you need to dial out, what do you need to connect to, etc. And in any case, once the customer asks for "X", signs off on it, and it turns out they really needed "Y", it's best to get that over with as soon as possible and start working on "Y".
The user actually knows *exactly and precisely* what they want, it's just that they have a tough time expressing it most of the time, and it's quite probable that what they want is not possible in the timeline / budget / etc. that they have allocated for that need.
So, figure out what a customer *wants*, keep them FAR away from anything remotely technical, but make sure the technical decisions that the engineering team makes satisfy what the customer *wants*.
I remember that story quite vividly as well: "When doing market research, we realized that mediocre people didn't want a real C++ compiler, they just wanted C++ on the box and *.cpp file extensions so they could bill themselves out ($$$) as C++ programmers. We then spent the next 5 years fixing all of our dork-isms in the C++ compiler to bring it up to standards, but that didn't matter because we had already crushed our competition by making flashy-promises and code wizards and being first to market with a non-compliant compiler." (or something to that effect).
Bzzt. Try again. A DeVry Graduate needs your above list. A Computer Science Graduate needs to know:
Science. Computers.
That means subtract out the requirements gathering, scripting, and overboard requirement of "C++ or else, luser", and shift a few of your "required" classes to required from a group of electives (ie: networking, databases, etc).
Add in a bunch more of algorithms, big-O, discrete math, prob-stat, linear algebra, etc. A lot of your class list sounds great to offer for electives (along with graphics, AI, GA, neural networks, etc), or also a software engineering specialization, but not as core CS courses.
If I were going to add in a 1-semester course of "practical, real-world, non-math-based schtuff", I would focus on TDD / Unit Testing along with the requirements gathering and secure coding practice (they're all basically one and the same: your code does exactly what you intend it to do, no more and no less... but the customer / client can always throw in monkey wrenches at the last minute).
There are two ways to motivate people- carrots and sticks. If they don't change when you beat them with a stick then you shove the carrot... wait, what am I saying.:^)... Stick-like motivation can only go so far, and in many corporate / company cases you personally have very little stick to whack people with. The secret is to find something that "the boss / the owner" is passionate about (it might not be technology, but instead uptime / sales / reliability, etc), and then you work to provide many carrots that will lead your coworkers on the path towards meeting your needs and what will also end up making the boss happy.
Let me give a concrete example. I worked at a startup right around the transition from PHP3-PHP4. There was no such thing as PEAR or MVC frameworks, etc. and there was a wide variety of programming skillz at the shop. We had an existing form-validation framework that was (how to say) heavyweight. All form fields stored in databases, serialize a bazillion objects an every page-submit, session-sizes of 20-30kb for 1-2kb worth of actual data, random page-flow/state bugs, db-synchronization problems, etc. Some people liked it, some people didn't, some people said: "WTF, I will just write straight PHP and do my own ad-hoc input validation, etc" (which was OK in some cases, but made maintainability much more difficult once the form started getting complicated).
Boss recognized that some things needed improvement, but wasn't really capable of getting involved and setting specific technical priority (and that's not really his job). He was kindof a control-freak, though, and was really keen on "seeing all the error messages that a user saw", so that he could go in and try to rewrite the forms or prompts or whatever so they'd be more clear. Anyway, I wired up some stuff so that error messages could be stored in a database ("integer"=="db" or ad-hoc strings during development), errors onsubmit were dumped into a database of $user, $app, $error, $field, $val, $time, and wrote up a little viewer that would pull errors out for sorting / filtering, and a little editor that would let you edit error messages so they were more clear.
Then I sat back. Pretty soon boss was using error-message viewer/editor, the improvments to the framework for form validation indeed ended up fixing bugs and increasing performance both in session sizes as well as development times, and other programmers ended up getting irritated by "fix this error message, change that error message, why can't I see your error messages" stuff. Once all the tools were in place and with some gentle advocation, they took to the new system and pretty much standardized on it *of their own volition*. There really is no other way to "herd cats".
Read the books the OP recommended, and recognize that it's about 20% technology / tool changes, and 80% convincing other people to convince themselves that there is a better way. Build lots of little carrots that *do* in fact make things demonstrably better, and make sure the existing process *is indeed* more painful than the one you are suggesting / building towards. And good luck.
"I am a programmer, not a musician. I want to start a band to play music for my daughter's birthday party but I do not have any instruments, knowledge of how to play music, or band-mates. I can't believe that there are people who will accept money to play music for my daughter (which is what I really want), but that they won't do it for free. I mean, I can go to the store and buy a CD, and buy a CD-player and play that for my daughter for FREE- what is their deal? I would also like to require everyone to wear headphones during the performance so that nobody steals the music, but I would also like it to be nice and loud and have a big stack of speakers (because big speakers are cool)."
If you want to sell MP3's directly to your customers, put up a web-page that says: "MP3's for sale" and take pay-pal (who will also take a rather large % cut of small-dollar sales). When people send you $$$, you email them the MP3's. If that sounds like a lot of work or hassle, accept that you will have to give your MP3's to a 3rd party who will do a better job of selling & servicing customers securely. eCommerce is still moderately difficult. It would be nice if it were easier, then the answer would be "find a web-host that supports Sell-A-Zip-File-3.0" and just do that (which means you're still paying money to a 3rd party to sell your MP3's).
Copyright (c) 1999 Software in the Public Interest This logo or a modified version may be used by anyone to refer to the Debian project, but does not indicate endorsement by the project.
...where is the mozilla/firefox "open use logo license"? I support Debian in all its idiosyncratic glory because they have the guts and the freedom to really take a stand. It's not DFSG-free? It's not in Debian (the official debian, anyway). If that means FireFox => IceWeasel, life is good, because I can modify and redistribute IceWeasel while I can't modify and redistribute FireFox. And that's probably a good thing too, because if Mr. Malware could make "FireFox 9.0 + PopupInfestation" and convince people to download it, then that'd be bad for people who get fooled by that and there wouldn't be a thing Mozilla foundation could do about it.
Did you ever play Tribes 2? They had kills, and points for kills or flag-captures, but no matter what anyone else was trying to do, you could have fun trying to do what you wanted to do (ie: stop them, guard base, etc). It was understood that a heavy base defender would have less points (generally) than a light flag-runner, or that a pilot might not have very many points at all. And even if you were a points-whore, that usually meant you were running across the map like a retarded monkey trying to cap the enemys flag, meaning they safely kept out of the way of anybody defending, turret-farming, or piloting vehicles (which was also fun). It became less fun when people did a whole bunch of team-switching, but you would have that problem in just about any game.
For (QA) test databases, it's generally not enough to just have a separate instance, you also need to support the following capabilities:
1- "Clone" whatever is most recent on production
2- Revert to "known good QA state" (ie: big red reset button)
3- Dump current state for later use.
You need to be able to clone so that ad-hoc testing can be run against production data w/o making production impact. This doesn't have to be live, but can be like a once-a-week/once-a-month activity, or rotate out a slave DB every once in a while, or have your DB people test your backups / etc.
You need the ability to revert to a known good state so that specific tests can be run and those can be more easily automated. Like: search "foo", 7 results found (not 6, not 8, not "it was 8 a few seconds ago but now it's 9 because there's a new result that was just added)... the more confident QA is in the data, the more confident (and/or prone-to-automation) their can be.
The ability to dump out DB state is a very distant third, but can be helpful for post-testing analysis or being able to modify a particular DB snapshot to fit some particular testing needs and then dump that out to the file-system for later use.
QA is hard, thank you for trying to make it easier.
All Other MP3 Players: MMM MMM MMM...tell them it because the iPod has a good user-focused design. Then say: "simplicity, complexity, common use cases, easy to use, reliable, etc" It should be easy if *YOU* can remember to be customer/user focused when you present your argument.
But don't get your hopes up. Unless you are golfing with the CEO/CTO, you are already an outsider, and your words mean no more than the buzzing of flies in the wind to the people who already have the power make those $$$-and-time decisions. If they are not already making them, they will require more than 1-2 hours of discussion to bring them around.
> There are several reasons why by itself won't work...
Of course, IANAEDDM, and a slashbox is not enough space to fully explain good development practices.
>...Q's regarding configuration options...
Or run debian in "no questions, defaults only" mode, or FAI or debconf answers, etc.
>... configuration files for all the packages is perfect for the appliance.
Hrm... Appliance... Toaster... All the same... Toaster configurations... Probably not an insurmountable problem.
> an appliance like this needs to last a long time in the field. One of the problems with Debian is that policy demands they only support the OS until a new stable is declared. This may mean a need to do full upgrades on live or semi-live boxes...
One- have you *seen* Debian's release cycle?:^)
Two- have you ever *run* apt-get update ; apt-get upgrade? Even if the "remote repository" is http://127.0.0.1/debs-copied-locally-for-updates/* .deb and the "firmware update command" is: scp newfirmware.deb device.my.net:/var/local-archive/debs-copied-local ly-for-updates/
'nuff said, no harm intended. Fun discussion and fun to think about.
...but if you're using Debian, I would highly recommend that you spend a quality week or two *READING* the wonderful documentation debian has and read / ask a few questions on their mailing lists.
Once you understand the package-management system of the SOFTWARE YOU ARE BASING YOUR BUSINESS OFF OF, the answer to your question will become clear... nay- simple.
- Generous use of depends, requires, conflicts, provides, etc. (or maybe up-rev eg: kernel-image-2.6.8-1.deb to kernel-image-2.6.8-1-MyCompany-1.deb, these are the things you can ask for advice on Debian / Ubuntu lists).
- Source control all files used in any of those *.deb packages, and make an automated build process that can take your source-control tree and generate your packages at any time of the day or night.
- Set up internal repositories, ie: http://apt.mycompany.com/stable/.../testing/.../nightly/, etc. and integrate that with your testing / deployment infrastucture....but most of all, please READ the documentation that Debian has put together. In few words, it allows mostly volunteers in their spare time to do exactly what you are trying to do and with a high degree of reliability. The documentation in Debian Policy is the first stop (and most likely the last) for almost anything you are trying to do. When you see the types of bug-reports that are filed against packages that go against policy (ie: incorrect depends, provides, etc) you will see what types of mistakes are possible, and you should seriously consider how to check the work that you've done to make it more likely that your work would not have the same types of bugs filed against it.
"""The nature of comedy is such that it gets old quickly, and innovation is everything. Racing games and FPS's don't suffer from these problems."""
It is obvious you have you never played the Indy 500 racing game. Driving around in a fricking circle for however many hours it took on a 286 to do it? Now *that* gets old quickly.:^)
I listed to the hour long talk yesterday, consider what he actually says is:
- Yahoo wasn't in the search business before google (they used outsourced providers and have only recently bought / brought "search" in-house)
- There are (presumably) reasonably large fixed costs to search (ie: database of the entire internet)
- MSN is at a *stable* distant third place (~15% market share) even with all their inherent microsofty advantages
- MSN have no stable base of advertisers (to help recuperate the large-ish fixed costs)...of course all that changes when you have $N billion in the bank and aren't afraid to lose it.
Slashdot Mirror
http://www.robertames.com/blog.cgi/entries/links/patents-feb-2005.html
Mah blog. I has it. And a decent write-up of the origins of the expression when it occurred to me to research it.
--Robert
That's an interesting argument...
Does a mechanic cause $5000 worth of damage when he points out that your axle is broken and needs replacement?
Can you cause damage to a system that has intrinsic vulnerabilities?
Obviously people taking advantage of disclosed vulnerabilities should be punished under applicable laws (as with simple copyright violation) for whatever damages they caused, but I tend to agree that you can't really pin damages on the discloser.
Now some other b.s. charge about reckless endangerment or speech issues, but probably not damages.
--Robert
If you've got old windows software (office productivity especially, Quicken 3.0 or whatever) donate it to wine. I threw some of my old CD's away and made a post about it on my blog (*extremely* low traffic blog) and their wine ninjas found it and one of the project dudes mailed me asking to send them the CD's. Unfortunately I had already thrown them away, but now I make it a point to tell people throwing away old software what you can do with it.
--Robert
"""One of the biggest problems with text based communication is that people simply can't write well."""
s/write/read/g
I find that the more I write the less likely people are to take the time to understand (while dealing with processing large quantities of text and information). Putting in sarcasm, double-entendre's and the like are counterproductive at best, and firing offenses at worst. For informal communications, the smiley can be helpful.
Now if only I could break myself of the habit of referring to "teh internets" and their "evil haxors" in meetings....
--Robert
http://yodel.yahoo.com/2007/05/22/one-small-step-f or-email-one-giant-leap-for-internet-safety/
It also has some nice background information on DKIM.
--Robert
The Debian Policy Manual codifies the whys and hows of basic unix operation. Some of it is debian-specific, but debian is a pretty big chunk of "the world of linux" and their policy manual reflects a whole bunch of that common / shared knowledge. What goes in "/var"? How to be sane with "/etc/foo" v. "~/.foo/"? Cron + Init. Basically if a package does something "not in the debian way", then their policy documentation is designed to be able to point to a section and say: "we'd really prefer something like the following..."
It's a great resource. Also if you really feel like a challenge, grab an older version of debian and do an install. I thought I knew my PC until it blew up back in '99 and I (being tired of windows) installed debian. And proceeded to have to take out every piece of hardware (including memory sticks and floppy drives), putting them back in one by one until I could figure out what was causing XYZ to work or not work. Good times, and you learn a lot.
--Robert
...are two examples of where something like this was implemented. In AvP, there was a multiplayer mode where the human or the predator had to fight off a bunch of aliens. The aliens died easy, but they re-spawned continuously and could jump onto / off of the walls and stuff. Each class had different vision modes which influenced how you played as well. Good times.
o r_(computer_game)#Screenshots
... coupled with the different game-play modes (Defend the Base v. Conquer the Base, then switch sides), you got pretty close.
... to go back in time and play Tribes2 again would be a little slice of heaven.
http://en.wikipedia.org/wiki/Aliens_versus_Predat
Tribes2 also had the idea of radically different armor classes and a greater ability to choose your role (from Heavy + Mortar + Missiles to Light + Sniper + Cloaking)
http://en.wikipedia.org/wiki/Tribes_2#Armor
The neat thing about Tribes2 was how time and cooperation was a factor. If you had 6 heavies, they would take 20 minutes to get from one side of the map to the other. If you had 5 heavies + 1 light + a Troop Carrier, you'd get across in 1 minute. So there was this time-based and skill-based economic incentive for people to play differing roles (are you good at base-raiding? be a heavy. suck at it? pilot troop carriers. sneaky? shocklance and cloak-pack. twitchy? light armor + laser-rifle. not enough flag-runners? suit up with a light + energy. too many flag-runners? grab a medium armor and missles to support your flag-runners.) *sniff*
--Robert
...except for the ability to access / look at the Javascript object for a dom node in a nice convenient way (ie: document.getElementById('foo') in Firebug Console, v. dir( $('foo') ), v. domInpsect: 'foo'). I'm pretty sure there's a way to get at the JS view of the dom node with firebug, but it's not very straightforward by default.
:^)
But you (I) certainly use the Dom inspector less after Firebug, and all hail Joe and his cohorts!!
--Robert
TDD, JUnit (or equivalent), FIT. Well-tested, independent tiers. GUI test as a last resort, or with humans.
--Robert
"""He responded, "I just need to be able to connect to a modem and dial out.""""
Engineer says: "B.S. - Be Specific", what is your app, what is the requirement, why do you need to dial out, what do you need to connect to, etc. And in any case, once the customer asks for "X", signs off on it, and it turns out they really needed "Y", it's best to get that over with as soon as possible and start working on "Y".
The user actually knows *exactly and precisely* what they want, it's just that they have a tough time expressing it most of the time, and it's quite probable that what they want is not possible in the timeline / budget / etc. that they have allocated for that need.
So, figure out what a customer *wants*, keep them FAR away from anything remotely technical, but make sure the technical decisions that the engineering team makes satisfy what the customer *wants*.
--Robert
Might it be this one: Rapid Development by Steve McConnell?
I remember that story quite vividly as well: "When doing market research, we realized that mediocre people didn't want a real C++ compiler, they just wanted C++ on the box and *.cpp file extensions so they could bill themselves out ($$$) as C++ programmers. We then spent the next 5 years fixing all of our dork-isms in the C++ compiler to bring it up to standards, but that didn't matter because we had already crushed our competition by making flashy-promises and code wizards and being first to market with a non-compliant compiler." (or something to that effect).
--Robert
Bzzt. Try again. A DeVry Graduate needs your above list. A Computer Science Graduate needs to know:
Science. Computers.
That means subtract out the requirements gathering, scripting, and overboard requirement of "C++ or else, luser", and shift a few of your "required" classes to required from a group of electives (ie: networking, databases, etc).
Add in a bunch more of algorithms, big-O, discrete math, prob-stat, linear algebra, etc. A lot of your class list sounds great to offer for electives (along with graphics, AI, GA, neural networks, etc), or also a software engineering specialization, but not as core CS courses.
If I were going to add in a 1-semester course of "practical, real-world, non-math-based schtuff", I would focus on TDD / Unit Testing along with the requirements gathering and secure coding practice (they're all basically one and the same: your code does exactly what you intend it to do, no more and no less... but the customer / client can always throw in monkey wrenches at the last minute).
--Robert
There are two ways to motivate people- carrots and sticks. If they don't change when you beat them with a stick then you shove the carrot... wait, what am I saying. :^) ... Stick-like motivation can only go so far, and in many corporate / company cases you personally have very little stick to whack people with. The secret is to find something that "the boss / the owner" is passionate about (it might not be technology, but instead uptime / sales / reliability, etc), and then you work to provide many carrots that will lead your coworkers on the path towards meeting your needs and what will also end up making the boss happy.
Let me give a concrete example. I worked at a startup right around the transition from PHP3-PHP4. There was no such thing as PEAR or MVC frameworks, etc. and there was a wide variety of programming skillz at the shop. We had an existing form-validation framework that was (how to say) heavyweight. All form fields stored in databases, serialize a bazillion objects an every page-submit, session-sizes of 20-30kb for 1-2kb worth of actual data, random page-flow/state bugs, db-synchronization problems, etc. Some people liked it, some people didn't, some people said: "WTF, I will just write straight PHP and do my own ad-hoc input validation, etc" (which was OK in some cases, but made maintainability much more difficult once the form started getting complicated).
Boss recognized that some things needed improvement, but wasn't really capable of getting involved and setting specific technical priority (and that's not really his job). He was kindof a control-freak, though, and was really keen on "seeing all the error messages that a user saw", so that he could go in and try to rewrite the forms or prompts or whatever so they'd be more clear. Anyway, I wired up some stuff so that error messages could be stored in a database ("integer"=="db" or ad-hoc strings during development), errors onsubmit were dumped into a database of $user, $app, $error, $field, $val, $time, and wrote up a little viewer that would pull errors out for sorting / filtering, and a little editor that would let you edit error messages so they were more clear.
Then I sat back. Pretty soon boss was using error-message viewer/editor, the improvments to the framework for form validation indeed ended up fixing bugs and increasing performance both in session sizes as well as development times, and other programmers ended up getting irritated by "fix this error message, change that error message, why can't I see your error messages" stuff. Once all the tools were in place and with some gentle advocation, they took to the new system and pretty much standardized on it *of their own volition*. There really is no other way to "herd cats".
Read the books the OP recommended, and recognize that it's about 20% technology / tool changes, and 80% convincing other people to convince themselves that there is a better way. Build lots of little carrots that *do* in fact make things demonstrably better, and make sure the existing process *is indeed* more painful than the one you are suggesting / building towards. And good luck.
--Robert
"I am a programmer, not a musician. I want to start a band to play music for my daughter's birthday party but I do not have any instruments, knowledge of how to play music, or band-mates. I can't believe that there are people who will accept money to play music for my daughter (which is what I really want), but that they won't do it for free. I mean, I can go to the store and buy a CD, and buy a CD-player and play that for my daughter for FREE- what is their deal? I would also like to require everyone to wear headphones during the performance so that nobody steals the music, but I would also like it to be nice and loud and have a big stack of speakers (because big speakers are cool)."
If you want to sell MP3's directly to your customers, put up a web-page that says: "MP3's for sale" and take pay-pal (who will also take a rather large % cut of small-dollar sales). When people send you $$$, you email them the MP3's. If that sounds like a lot of work or hassle, accept that you will have to give your MP3's to a 3rd party who will do a better job of selling & servicing customers securely. eCommerce is still moderately difficult. It would be nice if it were easier, then the answer would be "find a web-host that supports Sell-A-Zip-File-3.0" and just do that (which means you're still paying money to a 3rd party to sell your MP3's).
Sorry for the snark, but I'm in a snarky mood.
--Robert
I need to come up with a "voting checklist" thing:
Your proposed solution will not work because it fails to account for:
[x] vote selling
[x] voter intimidation (vote for FOO or I kill your grandma)
[x] computers can't be trusted
[x] physical, visual, human-eyeball recounts are impossible
--Robert
--Robert
--Robert
Did you ever play Tribes 2? They had kills, and points for kills or flag-captures, but no matter what anyone else was trying to do, you could have fun trying to do what you wanted to do (ie: stop them, guard base, etc). It was understood that a heavy base defender would have less points (generally) than a light flag-runner, or that a pilot might not have very many points at all. And even if you were a points-whore, that usually meant you were running across the map like a retarded monkey trying to cap the enemys flag, meaning they safely kept out of the way of anybody defending, turret-farming, or piloting vehicles (which was also fun). It became less fun when people did a whole bunch of team-switching, but you would have that problem in just about any game.
--Robert
For (QA) test databases, it's generally not enough to just have a separate instance, you also need to support the following capabilities:
... the more confident QA is in the data, the more confident (and/or prone-to-automation) their can be.
1- "Clone" whatever is most recent on production
2- Revert to "known good QA state" (ie: big red reset button)
3- Dump current state for later use.
You need to be able to clone so that ad-hoc testing can be run against production data w/o making production impact. This doesn't have to be live, but can be like a once-a-week/once-a-month activity, or rotate out a slave DB every once in a while, or have your DB people test your backups / etc.
You need the ability to revert to a known good state so that specific tests can be run and those can be more easily automated. Like: search "foo", 7 results found (not 6, not 8, not "it was 8 a few seconds ago but now it's 9 because there's a new result that was just added)
The ability to dump out DB state is a very distant third, but can be helpful for post-testing analysis or being able to modify a particular DB snapshot to fit some particular testing needs and then dump that out to the file-system for later use.
QA is hard, thank you for trying to make it easier.
--Robert
Don't know if this discussion is "too old", but I heard a different explanation, almost diametrically opposed to this interpretation.
--Robert
...and give examples with charts.
...tell them it because the iPod has a good user-focused design. Then say: "simplicity, complexity, common use cases, easy to use, reliable, etc" It should be easy if *YOU* can remember to be customer/user focused when you present your argument.
The example you should give is iPod. Say this:
iPod Sales: MMM MMM MMM MMM MMM MMM MMM MMM MMM
All Other MP3 Players: MMM MMM MMM
But don't get your hopes up. Unless you are golfing with the CEO/CTO, you are already an outsider, and your words mean no more than the buzzing of flies in the wind to the people who already have the power make those $$$-and-time decisions. If they are not already making them, they will require more than 1-2 hours of discussion to bring them around.
--Robert
> There are several reasons why by itself won't work...
...Q's regarding configuration options...
... configuration files for all the packages is perfect for the appliance.
:^)
* .deb and the "firmware update command" is: scp newfirmware.deb device.my.net:/var/local-archive/debs-copied-local ly-for-updates/
Of course, IANAEDDM, and a slashbox is not enough space to fully explain good development practices.
>
Or run debian in "no questions, defaults only" mode, or FAI or debconf answers, etc.
>
Hrm... Appliance... Toaster... All the same... Toaster configurations... Probably not an insurmountable problem.
> an appliance like this needs to last a long time in the field. One of the problems with Debian is that policy demands they only support the OS until a new stable is declared. This may mean a need to do full upgrades on live or semi-live boxes...
One- have you *seen* Debian's release cycle?
Two- have you ever *run* apt-get update ; apt-get upgrade? Even if the "remote repository" is http://127.0.0.1/debs-copied-locally-for-updates/
'nuff said, no harm intended. Fun discussion and fun to think about.
--Robert
...but if you're using Debian, I would highly recommend that you spend a quality week or two *READING* the wonderful documentation debian has and read / ask a few questions on their mailing lists.
.../testing/ .../nightly/, etc. and integrate that with your testing / deployment infrastucture. ...but most of all, please READ the documentation that Debian has put together. In few words, it allows mostly volunteers in their spare time to do exactly what you are trying to do and with a high degree of reliability. The documentation in Debian Policy is the first stop (and most likely the last) for almost anything you are trying to do. When you see the types of bug-reports that are filed against packages that go against policy (ie: incorrect depends, provides, etc) you will see what types of mistakes are possible, and you should seriously consider how to check the work that you've done to make it more likely that your work would not have the same types of bugs filed against it.
Once you understand the package-management system of the SOFTWARE YOU ARE BASING YOUR BUSINESS OFF OF, the answer to your question will become clear... nay- simple.
- MyCompanySoftware-1_0.deb, MyCompanyKernel-1_0.deb, MyCompanyOtherStuff-1_0.deb
- Generous use of depends, requires, conflicts, provides, etc. (or maybe up-rev eg: kernel-image-2.6.8-1.deb to kernel-image-2.6.8-1-MyCompany-1.deb, these are the things you can ask for advice on Debian / Ubuntu lists).
- Source control all files used in any of those *.deb packages, and make an automated build process that can take your source-control tree and generate your packages at any time of the day or night.
- Set up internal repositories, ie: http://apt.mycompany.com/stable/
--Robert
"""The nature of comedy is such that it gets old quickly, and innovation is everything. Racing games and FPS's don't suffer from these problems."""
:^)
It is obvious you have you never played the Indy 500 racing game. Driving around in a fricking circle for however many hours it took on a 286 to do it? Now *that* gets old quickly.
--Robert
Dude, chill out- the're internet years... sheesh.
--Robert
I listed to the hour long talk yesterday, consider what he actually says is:
...of course all that changes when you have $N billion in the bank and aren't afraid to lose it.
- Yahoo wasn't in the search business before google (they used outsourced providers and have only recently bought / brought "search" in-house)
- There are (presumably) reasonably large fixed costs to search (ie: database of the entire internet)
- MSN is at a *stable* distant third place (~15% market share) even with all their inherent microsofty advantages
- MSN have no stable base of advertisers (to help recuperate the large-ish fixed costs)
--Robert