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.
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.
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.
>>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.
How were the images generated? Was it just hand-edited text files that were printed out, or did they have some type of drawing program? It would be cool if they had created a program with a 3d model of the cat - an animation of which was then rendered to ASCII:) I suppose it would have been possible given the technology at the time but also quite challenging - who knows:)
It's probably nothing, probably. But I'm getting a small discrepancy in the file sizes...no, no, it's well within acceptable limits. Continue to stage 2.
Right, thanks for the correction.
Yes I guess you can still make good deals there. In the old days I went there for C64 stuff:P
There's also still the Virgin Megastore that have tons of records (Tower of Records is closed as far as I remember):)
I've been to London tons of times and there was always lots of stuff to do and see.
Oh you mean he should dress up like all the chavs (I believe you call it?) you see everywhere on the streets?;) I'm sure his normal clothes will be fine:)
There's a big Science Museum (I think it is just called that) which is nice to see.
If you're into war-stuff, go to to the Imperial War Museum.
In the old days I used to go to Tottanham Court Road to buy electronics and computer games - they always had much cooler stuff than you could get here (Denmark). But now that all this stuff has become much more mainstream it's not that exciting. Just a lot of small electronics shops.
You might consider going to Greenwich (easy to get to from London) to see the Greenwich Meridian and lots of associated museums. It's a UNESCO World Heritage Site btw. Other trips could be Oxford or Windsor. I think you can also do a tour to Stonehenge but I haven't tried that myself.
If you're into high street shopping, Regent Street (starting at Picadilly Circus) and Oxford Street (which intersects RS) are the places to go. Of course, Harrods (Knightsbridge) is a must too:)
Be sure to bring an umbrella or buy one there - always raining;)
Be sure to go to their many great pubs and clubs. Since I'm gay I mostly went to those places (in the area around Old Compton Street) but otherwise I think they are passing flyers around at the evening in the area around Picadilly Circus, so you can see what is going on.
Right, however alpha radiation is the suspected cause of some DRAM failures. The problem is the alpha radiation emitted by the decaying Carbon-14 atoms in the plastic of the module itself.
The program might tag you as gay but clearly having gay friends doesn'tmean that you are gay - it's just a correlation. And as you say, it probably only works for people who have a large number of friends on Facebook since the coincidences that you describe would be much less likely to significantly affect the overall percentage.
The point of my post was just that I was wondering who something so simple would be considered news- (and MIT-)worthy. I remember when entering Facebook that I was fully aware that now people who didn't yet know I was gay, would find out (even if I didn't 'advertise it') simply based on who I was adding as friends, what was being written on my wall, invitations etc. So I agree with them it is sort of a privacy issue but on the other hand it is so obvious so anyone creating a profile should have thought this through - sadly they might not.
This is old news (and really pretty obvious) and have been known in the gay community since FB started:) I have ~250 friends and being gay, quite a few of my friends are gay too. Whenever I click on some new person I can usually tell whether that person is gay (at least if it's a guy) or not, simply based on the number of gay friends we have in common (i.e. I don't even need to look at that person's friends individually to see whom of them are gay). So if we don't have any friends in common at all, it's usually a sign that the person isn't gay. Now, being from a small country (Denmark, 5.5 mio. citizens) implies a smaller gay community, but I would still think this observation would be valid in other countries at least within cities.
The reason this works is of course that within all communities there are certain people who have _a lot_ of friends on Facebook and sort of serve as "magnets", in the sense that someone in the same community is likely to sooner or later run into that person and be added as a friend on Facebook - or at least run into one out of the "magnet" persons you are friends with.
Regrettably, this is wrong too. getline() is part of the standard C/C++ library which comes with Visual C++. Hence, it IS a bug in Visual C++. Note also that the poster provided a link detalining how to circumvent the bug by changing a couple of lines in the string.h file - which comes with Visual C++.
The error is totally unrelated to the platform SDK. The platform SDK provides headers, libs and docs for the Win32 API, the native Windows API and does not provide standard functions, such as getline().
Intel's CPU's have been superscalar since P6 (Pentium Pro). They can execute 3-4 instructions per clock under optimal conditions (yes all the way through the pipeline). They have out-of-order execution, speculative execution, register renaming etc. However, there's a limit to how much you can execute in parallel at the instruction level.
Could you elaborate on what Intel's CPU's are missing and what Edward Lee was warning about?
You missed the point. You seem to think the point is that the article confuses language with runtime environment or some more benign mistake like that. However, the point is that the languages mentioned are simply not scripting languages or related to scripting languages. Java is a language but not a scripting language..NET is a platform for running intermediate code compiled from various languages (many of which are not scripting languages either). ActiveX is a technology for running/hosting native code (certainly not scripting language code) in the browser.
A much more elegant approach would be for ACPI to query the o/s about each device/feature, if it was able to recognize it or not. If not, the BIOS could disable it.
I prefer this to the BIOS asking the o/s "Hey are you Windows XP?" and if the answer is "yes", tries to figure out what Windows XP might support. Operating systems are not static and device drivers in Windows can insert themselves as filters in the ACPI stack and might thus extend ACPI support. In that case, you don't want the BIOS to leave out a device just based on osname. However, this solution is essentially equivalent to the simpler approach of presenting the full device list to the o/s and have it decide what it can use. This is actually how ACPI is supposed to work today, but the problem is Windows presents devices it doesn't recognize with an exclamation point. Many manufacturers solve this by providing INF files that enables Windows to recognize the devices. However, some BIOS manufacturers apparently want to get rid of these exclamation points altogether (so they aren't seen even right after install) and goes to the extend of removing devices from the ACPI tables based on expectations on what the o/s might support.
Finally, you must agree that when all o/s'es now pretend to be Windows, this "feature" of ACPI has become completely unusable.
By the way, you make it sound much better than it is. It's not that the BIOS shuts down unsupported devices (which are typically low-level system devices likes high-precision timers) to save power. Rather, the device is logically removed from the ACPI table so the o/s doesn't see it and hence you solve the problem, at least cosmetically.
I think this came about my boss in a motherboard company getting annoyed with the exclamation marks and an ambitious employee saying "Hey, I can solve this..." without thinking about the longer term consequences for the industry.
Slashdot Mirror
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.
How were the images generated? Was it just hand-edited text files that were printed out, or did they have some type of drawing program? It would be cool if they had created a program with a 3d model of the cat - an animation of which was then rendered to ASCII :) I suppose it would have been possible given the technology at the time but also quite challenging - who knows :)
It's probably nothing, probably. But I'm getting a small discrepancy in the file sizes...no, no, it's well within acceptable limits. Continue to stage 2.
Right, thanks for the correction. Yes I guess you can still make good deals there. In the old days I went there for C64 stuff :P
There's also still the Virgin Megastore that have tons of records (Tower of Records is closed as far as I remember) :)
I've been to London tons of times and there was always lots of stuff to do and see.
Oh you mean he should dress up like all the chavs (I believe you call it?) you see everywhere on the streets? ;) I'm sure his normal clothes will be fine :)
There's a big Science Museum (I think it is just called that) which is nice to see. If you're into war-stuff, go to to the Imperial War Museum. In the old days I used to go to Tottanham Court Road to buy electronics and computer games - they always had much cooler stuff than you could get here (Denmark). But now that all this stuff has become much more mainstream it's not that exciting. Just a lot of small electronics shops. You might consider going to Greenwich (easy to get to from London) to see the Greenwich Meridian and lots of associated museums. It's a UNESCO World Heritage Site btw. Other trips could be Oxford or Windsor. I think you can also do a tour to Stonehenge but I haven't tried that myself. If you're into high street shopping, Regent Street (starting at Picadilly Circus) and Oxford Street (which intersects RS) are the places to go. Of course, Harrods (Knightsbridge) is a must too :)
Be sure to bring an umbrella or buy one there - always raining ;)
Be sure to go to their many great pubs and clubs. Since I'm gay I mostly went to those places (in the area around Old Compton Street) but otherwise I think they are passing flyers around at the evening in the area around Picadilly Circus, so you can see what is going on.
Right, however alpha radiation is the suspected cause of some DRAM failures. The problem is the alpha radiation emitted by the decaying Carbon-14 atoms in the plastic of the module itself.
The program might tag you as gay but clearly having gay friends doesn'tmean that you are gay - it's just a correlation. And as you say, it probably only works for people who have a large number of friends on Facebook since the coincidences that you describe would be much less likely to significantly affect the overall percentage. The point of my post was just that I was wondering who something so simple would be considered news- (and MIT-)worthy. I remember when entering Facebook that I was fully aware that now people who didn't yet know I was gay, would find out (even if I didn't 'advertise it') simply based on who I was adding as friends, what was being written on my wall, invitations etc. So I agree with them it is sort of a privacy issue but on the other hand it is so obvious so anyone creating a profile should have thought this through - sadly they might not.
This is old news (and really pretty obvious) and have been known in the gay community since FB started :) I have ~250 friends and being gay, quite a few of my friends are gay too. Whenever I click on some new person I can usually tell whether that person is gay (at least if it's a guy) or not, simply based on the number of gay friends we have in common (i.e. I don't even need to look at that person's friends individually to see whom of them are gay). So if we don't have any friends in common at all, it's usually a sign that the person isn't gay. Now, being from a small country (Denmark, 5.5 mio. citizens) implies a smaller gay community, but I would still think this observation would be valid in other countries at least within cities.
The reason this works is of course that within all communities there are certain people who have _a lot_ of friends on Facebook and sort of serve as "magnets", in the sense that someone in the same community is likely to sooner or later run into that person and be added as a friend on Facebook - or at least run into one out of the "magnet" persons you are friends with.
Regrettably, this is wrong too. getline() is part of the standard C/C++ library which comes with Visual C++. Hence, it IS a bug in Visual C++. Note also that the poster provided a link detalining how to circumvent the bug by changing a couple of lines in the string.h file - which comes with Visual C++. The error is totally unrelated to the platform SDK. The platform SDK provides headers, libs and docs for the Win32 API, the native Windows API and does not provide standard functions, such as getline().
Intel's CPU's have been superscalar since P6 (Pentium Pro). They can execute 3-4 instructions per clock under optimal conditions (yes all the way through the pipeline). They have out-of-order execution, speculative execution, register renaming etc. However, there's a limit to how much you can execute in parallel at the instruction level.
Could you elaborate on what Intel's CPU's are missing and what Edward Lee was warning about?
You missed the point. You seem to think the point is that the article confuses language with runtime environment or some more benign mistake like that. However, the point is that the languages mentioned are simply not scripting languages or related to scripting languages. Java is a language but not a scripting language. .NET is a platform for running intermediate code compiled from various languages (many of which are not scripting languages either). ActiveX is a technology for running/hosting native code (certainly not scripting language code) in the browser.
A much more elegant approach would be for ACPI to query the o/s about each device/feature, if it was able to recognize it or not. If not, the BIOS could disable it. I prefer this to the BIOS asking the o/s "Hey are you Windows XP?" and if the answer is "yes", tries to figure out what Windows XP might support. Operating systems are not static and device drivers in Windows can insert themselves as filters in the ACPI stack and might thus extend ACPI support. In that case, you don't want the BIOS to leave out a device just based on osname. However, this solution is essentially equivalent to the simpler approach of presenting the full device list to the o/s and have it decide what it can use. This is actually how ACPI is supposed to work today, but the problem is Windows presents devices it doesn't recognize with an exclamation point. Many manufacturers solve this by providing INF files that enables Windows to recognize the devices. However, some BIOS manufacturers apparently want to get rid of these exclamation points altogether (so they aren't seen even right after install) and goes to the extend of removing devices from the ACPI tables based on expectations on what the o/s might support. Finally, you must agree that when all o/s'es now pretend to be Windows, this "feature" of ACPI has become completely unusable. By the way, you make it sound much better than it is. It's not that the BIOS shuts down unsupported devices (which are typically low-level system devices likes high-precision timers) to save power. Rather, the device is logically removed from the ACPI table so the o/s doesn't see it and hence you solve the problem, at least cosmetically. I think this came about my boss in a motherboard company getting annoyed with the exclamation marks and an ambitious employee saying "Hey, I can solve this..." without thinking about the longer term consequences for the industry.