I have to agree - I can definitely see how one would try to preserve as much as possible. But at the end of the day, what you are going to capture on videos will only be a very small percentage of her personality. The only thing that will feel like a "high fidelity" representation of what she was like will be in your head: The memory of those special moments that are quintessential to that person and where you never happen to have a video camera running when it happens.

Also be careful not to overdo this video recording. As other posters suggested, I would try to make the most of the time you have left together in terms of being together. Travelling is an obvioius thing if you like it and can afford it, but it can also be smaller things that matter to you. Then occationally you can take a picture or recording of that, just like you did prior to this happening to you. Don't take this wrong, I think you should take some photos and do some records, it's just that it seems you are so focused on it that you will always think you didn't do enough. So just set your expectation to something realistic. And ask yourself if you will/should watch hours and hours of footage of her after she is gone and if that is something you would wish your loved ones would do if you passed away?

I can't help thinking if all this recording won't disturb the natural grieving processes of the brain. Maybe it is better to remember things the way the brain wants to remember them. Some memories will fade away and there will be things where you ask yourself "Why can't I remember this?" or "Why didn't I ask this?". But this is just part of the healing process. Initially after a traumatic experience, you are thinking about it all the time, say at least every second. The healing process consists of a continuous extension of this interval between being reminded of the trauma. So after a 1 week maybe you can go a minute without being reminded of it. After 1 month, maybe you can go half an our without being reminded of it. Part of this process, I suspect, involves deletion/blurring of memories - pushing them very farther and farther back in the 'database' and untying them from their relationship to everyday objects and experiences, so that you are not reminded of it all the time. As harsh and as it may sound, you will have to move on and focus on the people around you both for your own and other people's sake. I can't help but thinking if constant, digital reminders can interfere with this process.

Computer science is not a subset of mathematics - rather, mathematics is a subset of computer science. Any question in mathematics can be restated as a question about Turing machines. The question "Can the statement x be proven theory T?" can be restated as, does Turing machine PM(x,T) halt, where PM is a rather simple Turing machine that tries out all potential proofs of x using axioms of theory T (usually there's inifinitely many proofs to try) and halts if it finds a valid proof. You could say that complexity theory contains the answer to all mathematical problems, which is exactly why (in a very tangible sense for those familiar with the attempts at the problem including approaches based on circuit complexity) the problem P ?= NP is so hard to solve.

You are absolutely right. Also, if you rewrite you constantly have to make the choice "Do I keep this thing working the same way as in the old app". This could be on multiple levels, i.e. how you present something in the GUI, how something is internally in the code, how it is represented in the database etc.

More often than not, there will be a lot of pressure to keep at least some of the things the same as before. And often keeping those things the same will force you into a lot of choices of the old app. You might find youself just cloning/hand-converting the old app.

On the other hand, every time you change something as compared to the old app, there will be complaints from customers since likely there will be some scenario that wasn't as easy as before. Furthermore, even if every change is for the better, just the fact that it works differently may upset customers as they have to retrain their employees. Even if everything works the same but just looks slightly different due to different GUI, that can be a huge issue as well since all training material with screen shots have to be updated!

As described in my previous post, I went through this whole process and this was for an automated conversion process which by its nature preserved the functional aspects. But just the slight variations in how the GUI looked were a huge issue but those we managed to get the customer swallow. However, other aspects I would also consider minor and generally equivalent (i.e. the exact tab order of elements, exact keyboard behaviour in list boxes) turned out to be huge issues whenever there was a difference - so I went to great lengths to preserve as much as I could. Consider how hard and not the least uninteresting it would be if you are not just auto-converting the code, but are implementing from scratch!

Lesson: Only convert or rewrite when you really have to. Make sure your existing customers' cost with the change is factored in as well as they will surely factor it in when considering your product.

Right, I noticed that after I posted - there paragraphs were there in what I pasted in :-)

I think the IEEE view is totally backwards. My advice would be to never start out by thinking of secondary factors like like how old the code base is, how messy it is, programming language it is written in etc. Instead, look at the bottom line: What does it cost for the business right now that the code is bad. Is there a new feature we can't make, or can we see it is taking us too much time to make changes, do we have quality problems with those changes. Further, it s important to at least try to quantify each of these points and how much they cost. Then quantify the cost of a rewrite (including risk of cost overruns, setback in the market, lower quality in the beginning etc.). Then discount the cost of a rewrite with the rate of interest and compare the long term costs of either approach. Only then can you make a qualified decision. Often this isn't a hard exercise, because very often one will quickly see that the cost of the rewrite isn't worth it - the potential productivity gains from the rewrite can not catch up with the cost of the rewrite even over longer periods of time. Probably the rewrite should only be undertaken if it can pay for itself over a relatively short timespan since there's a major risk the product won't even exist or be relevant at that time. In most cases (when we are thinking about an app that has some maturity) only a major refactoring could make sense. Only very rarely does it make sense to throw out everytime. One of the situations that are hard are: What do I do with this app written in strange unsupported language XYZ, functioning fairly well, maintainable with some effort, but looking totally outdated (say GUI that looks like a Win 3.1 program etc.) and that can't inter-op with other languages etc. If the provider of XYZ doesn't provide a path to move the code to another platform, and one isn't available in the market you could try to do it yourself, which has risks as well and might not get all benefits (see my other post of such a project). Otherwise you might be either stuck with an app that appears outdated (and may be accumulating problems due to a buggy and unmaintained runtime etc.) OR have to pay the full cost of a reimplementation. Given that the conversion project might not be that bad after all and may not be as hard as you think.

I went through porting a ~400K application to Java. It was written in an unsupported, obsolete, early 90'ies "drag and drop" RAD system with a relatively simple language core. The program was highly mature and very functional even for competing programs. To port it, I wrote a conversion program that converted it function-by-function to Java. Additionally, I reimplemented the runtime library myself. The system had a couple of interesting specialities that made it fun to convert, because they were challenging to emulate in Java. Some of it called out to native C libraries (via a JNI mechanism, that I also had to implement) but also a strange type of global variables where a variable was shared among multiple processes. Additionally, it was possible to link fields in the GUI directly to storage locations (i.e. row in a table could be linked to the text fields of a dialog) so that the two would update it each other. There were various types of reflection possible and some simple message system for GUI. It took around 6 months of work. The project had to be done very fast for strategic reason. A multi-man effort to rewrite the application had spent 2 years to port just parts of the application. Of course not all the benefits was derived from my automated conversion. The original code was not that readable by today's standards, and it became slightly worse through conversion. But not all the "hand-written" converted code was that readable either, and some of it has already gone through heavy refactoring. No one included myself got much understanding out of the code but at least modern tools like Eclipse can be used to inspect, debug and extend it. Still, now 4 years after the completion of the project the code is still in production. New functionality has been written from scratch but the old code is still a significant (decreasing but probably still around 50%) part of the full application and has been maintained via bug fixes. There's no plan to reimplement just for 'reimplementation's sakef' but they might get reimplemented when they have to be significantly extended. It was also a fun project for me to. However, the code for the runtime library I wrote, that bridges the gap between the conventions of the original runtime system and Java's ssystem, is a bit horrifying to say the least. Fortunately, once it was done it worked quite well and has required no fixing for years. However, actually I now have to look into it again to make it work on another platform. It feels like reopening the Chernobyl concrete sarcophagus ;-) Fun and challenging, but I only change something on the day's where I feel at the top of my game :P

I don't think the part about the NAND chips is true. The bad block management takes place internally in the controller using a spare pool and is not under user control by any means. Hence, when you format a flash drive you won't actually see any bad blocks since they will have been remapped internally by the controller. I haven't seen a bad block in 13-14 years. It is possible that if a sector should at some later point become bad, that the controller will report the sector as unreadable until it has been rewritten again (after being remapped to the spare pool) but that is just to prevent the o/s from relying on invalid data.

I knew it would some day be possible to have full-HD on my old C64 :-)

As you say no one really knows since the ability of features to come and go were not anticipated by the law. Yet, BTW, it might also be possible to argue the case on standard consumer law if one considers the "right to receive updates" (since they are important to the continued operation of the device) as part of the whole product, like a subscription. I'm not sure if that would fly, but if it did you might have a case asince the "product" was defective. I guess the situation is somewhat similar to if one purchased a subscription for a newspaper on, say, Amazon, and then then the news outlet stopped sending you newspapers. Who do you have a case against - Amazon or the outlet?

I plan to file my own lawsuit after pursuing some less drastic steps first. These things take time - I think there's a lot of action going on from consumers around the world, but every step can take several weeks and this update has been out for just two weeks. There are benefits to individuals pursuing the case themselves since different legal arguments can be tried. I would be surprised if all those legal arguments are going to fail in all of the numerous juristictions where the system has been sold :) BTW, I didn't install the update. I hope the case can be resolved before new movies/games that can't be played start coming out :)

I agree that general consumer law in the EU dictates that the contract is with the retailer, not with the manufacturer (Sony in this case). Having said that, I think it might be possible to argue the case on other grounds than consumer laws. How about just general liability? After all, Sony is putting out an update that is ruining the devices. Shouldn't they be liable for that (compare to the case where the update totally wrecks the system). Additionally, they are putting other measures in place that ruin the device even if you don't install the update. Not just for their own Playstation Network but also with respect to your ability to play new games and Bluray movies. From this point of view, I don't see how anyone could have a case against the retailer, since the product was fine as sold. It was an external factor - Sony - that through its actions, deliberately ruined the product. It would be comparable to Sony breaking in and hitting your PS3 with a baseball bat. That is the legal argument I plan to use in my lawsuit against Sony. I don't want to sue the retailer since they did nothing wrong.

I think that is a pretty substantial difference from a legal point of view: I bought my PS3 to do A and B, now it only does A OR B.

>>Don't buy a PS3! It's that simple. So what is your suggestion for all of us who already bought a PS3 and have been using this feature? The issue is not new users but the existing users!

Wrong! I have the manual and it says no such thing. I bought one of the later models that still had the Linux support. In fact, the feature was advertised on box, explained in the manual (and no warnings) and was available with the firmware that came from the factory. Sony has advertised the capability in numerous interviews (saying it is one of the most powerful features). They have a section on their web site dedicated to it. They hired a company to make the first official Linux distro which was also sold as an product for $50 (yes, a physical DVD with this Sony-sponsored Linux "For Playstation 3). Sony got a tax credit from the EU by reclassifying their system from "game console" to "computer", saving 2.2% tax I believe. Given all these facts I find it highly improbable Sony could force people to install a firmware update that removes the feature. I think Sony -- probably out of arrogance -- didn't think this through at all. They were probably just in shock a weakness was found in their PS3 system (Geohot's hack) and didn't think this through. Maybe now they are discussing whether to backtrack or go through - probably the bean counters are working over time because it is NOT going to be a free lunch for them to remove OtherOS support. They will potentially have to refund anyone that cares.

False advertising and defective product.