Comment Sigh. We can emulate it. (Score 4, Insightful) 145
So what? We connect another memory device through an FPGA and emulate the error pattern. At least to the extend detected by the software.
So what? We connect another memory device through an FPGA and emulate the error pattern. At least to the extend detected by the software.
In a sense, yes. From what I understand the problem with space debris are the small size and the high kinetic energy. If you've got everything in a big lump it should be easier to de-orbit stuff and get it to burn up in the atmosphere.
What about some gel block, or even better some kind of foam?
Works quite well. It did work before, or course, but the interface is a bit simplified, and font sizes have been adjusted for being viewed from a distance.
I mixed up "endian" with "end-of-line", and we were working in a mixed Windows/Linux environment. The automatic change to native end-of-line that git does sometimes marked files as dirty, which required an extra commit before I could change back to my feature branch. It's quite possible that that process would've smoothed out over time.
That was mostly because code is sometimes not feature complete, or has some debugging/testing bits left in. We had a code review system in place, and I didn't want to increase the workload of the reviewer to check if any commit undid or modified changes of an earlier commit.
I used to use cvs, subversion and perforce. After switching to git, it feels a lot more powerful, at the cost of more things that can go wrong.
My workflow with subversion was:
- regular update: update, check/fix conflicts, continue work
- commit: update, pick files I want to commit with TortoiseSVN, verify the changes in the diff view, write log message, commit, continue work
On GIT:
- regular update: stash my changes, change to master branch, pull, check for errors or dirty files (mostly endian problems), switch to work branch, rebase from master, check for errors or dirty files, unstash my changes, check for errors or dirty files, continue work
- commit: update, stage the files I want to commit, commit them, verify the changes, push
At several stages some obscure thing could go wrong that I needed to look up in the manual or on the internet, or needed to ask someone who used it for longer. That doesn't mean I think GIT is bad, I just feel it takes more time to be fully productive with compared to older systems. And I miss a few minor things from svn, like keyword expansion or properties.
I see where you're coming from, looking at the popularity of cheat cartridges/discs or "trainers" for cracked games there are many people who just want to run through the game without any danger for themselves.
The question is, is it a sign of quality to target those people exclusively? All games are entertainment, but not like a movie they are a game. And part of a game is that you win or loose. Where is the reward for finally completing a risky section, if you haven't failed half a dozen times beforehand? What is worth fixing are unnecessary delays like long loading times to play what should be already in memory or a cutscene you can't skip. But removing the risk means removing the reward as well.
... if you cannot lose?
Gravity is a myth, the Earth sucks.