You might be somebody who would love to have 60fps 4K video, but have the misfortune of living in some place where a 4mbps connection is the fastest one available.
Embedded assignment in C came from a different era - one when both computers and compiler technology were much more limited. Using it made it possible to generate more efficient code for the common sequence of operations where you want to calculate a new value and both save it and make a test based on it.
Let's look at the code that a naive compiler would produce for two hypothetical sequences. (These are given in a simple hypothetical assembly language, but the examples are representative of what real code would have looked like. Details such as which register was used, relevant to the PDP-11 but not to many of its predecessors, are omitted.) First, the straightforward one without embedded assignment:
a=b
LOAD A
STORE B
if (a)...
LOAD A
BEQ NOTA
(code that follows the comparison)
NOTA: (code after the if)
Next up, the code generated when the conditional assignment is used:
if (a=b)...
LOAD A
STORE B
BEQ NOTA
(code that follows the comparison)
NOTA: (code after the if)
The redundant load operation is now gone, yielding a 25% reduction in code size and execution time for this test on computers that were in use when C was invented.
The original implementations of C had to run on computers that were hopelessly limited by modern standards; a typical configuration would be a PDP-11 with 16K bytes of memory. To put that into perspective, that is less powerful than the microcontroller that runs your neighborhood traffic light. Any decent modern C compiler will recognize the unnecessary load and optimize it out unless a is declared volatile, a declaration that didn't exist back in the early days of C because there was also no such thing as register variables, let alone compilers that would automatically promote some variables to that status. But the compiler that ran on that 16K PDP-11 did not perform that optimization, and attempting to add that capability to the compiler would have resulted in something too slow to be usable.
It's a bit more complicated than just decompressing the images. I suspect the browsers are keeping the complete HTML rendering of as many open tabs as possible so you can switch to them instantly. They are also keeping any Javascript code on the pages active (if not actually running) so they will be in the same state as when you left them. If each tab had to be re-rendered when you switched to it there would be a noticeable lag when you switch, and users wouldn't like that.
Memory may be cheap, though not as cheap as it was a couple of years ago; the street price of RAM has nearly doubled since then. But lots of low-end laptops have rather low limits on how much RAM you can install, like Bay Trail laptops with 4GB, and mobile devices like phones and tablets can't be upgraded at all and are likely to have a measly 2GB.
Your suggestion of letting the user set a limit is a good one. Firefox can't possibly know what the application mix of every user will be. If, for example, you load Firefox and a bunch of tabs and then launch Photoshop or Eclipse, Firefox is likely to have grabbed more of your RAM that it really should have. That's a likely usage pattern for somebody who uses webmail at work. You start your day by reading your email and checking your calendar, and then launch your work applications after you have gotten through it.
That doesn't necessarily mean that Firefox is leaking memory. It could mean that it is keeping it for its own reuse rather than releasing it back to the system. If the expectation is that the browser user will soon need the memory again (perhaps by opening 19 new tabs), that is likely to be more efficient than releasing it to the system pool and then later asking for it again. On the other hand, if the user next needs all that memory to run something OTHER than Firefox it's not so good.
The Chrome model of using a separate process for each tab leads more naturally to release of memory to the system, as there is no alternative when the tab's process is terminated.
Not caching uncompressed graphics, as you are suggesting, is an interesting possibility for memory-limited systems. To see whether it is a net gain it would be necessary to build a browser that did it, preferably by doing a modification of an existing browser like Firefox (so you could compare apples to apples) rather than creating a completely new one.
Some old titles haven't been released in newer formats, either because of lack of interest or because the rights have gotten hopelessly tangled. (In addition to the rights to the film itself, music rights are often an issue; licensing all the songs in an old movie or TV show can be prohibitively expensive. Ask any fan of WKRP in Cincinnati.) Even if you wanted to spend the money, you can't replace them with DVDs or digital downloads.
For some obscure movies there isn't much point to buying the DVD version. The only DVDs available come from low-budget companies that produced them by transferring a VHS tape or some equally bad source. Those DVDs look no better than the tape you already have.
Symbian can't really be said to have ever dominated the smartphone market, despite its large market share. Most of the Symbian devices were never used in a way that we would recognize as smartphone use; there was little use of apps at all and users never installed any additional apps.
Netbooks were a passing fad because they weren't quite good enough, and part of the reason they weren't quite good enough is that Microsoft imposed artificial restrictions on their hardware (display size and resolution, RAM) in an attempt to protect their main Windows business. The new crop of low cost Windows laptops will be good enough, because now they have competition from Chromebooks and they have to match the competition. It's likely that some of them will BE Chromebooks with a different keyboard and software load; I expect to see an Acer W720 soon (with either a hard drive or a larger SSD) though they might not call it that.
I have had no sympathy for IE ever since Microsoft used their then-monopoly power in operating systems to destroy Netscape. I believe that the correct government response to Microsoft's actions would have been to require them to withdraw IE from the market (stop development, stop including it in future versions of Windows, and modify microsoft.com to refuse connections from it).
They really couldn't allow WP7-WP8 upgrades because the WP7 devices didn't have enough computing power. Notably, WP7 only supported a single processor core so none of the phones on the market included a dual or quad core CPU.
The people I feel really got shafted were buyers of WP7.5 phones. That came out very shortly before WP8, so people with phones less than a year old were out in the cold. What I think Microsoft should have done is given a free WP8 phone to everybody who bought a WP7.5 phone; there were so few sold that MS could have easily afforded it and it would have bought them some much needed market credibility.
Some web sites are strictly informational and gather no PII (personally identifiable information) or no information at all. There is no good reason for such a site to use HTTPS - there are no security issues associated with its use. Punishing the search rank of such a site for not using HTTPS is unfair.
The amount of the T-Mobile network that does 3G on the 1700MHz AWS band is dropping with time. In markets where T-Mobile has introduced LTE, they have moved 3G HSPA+ coverage to the 1900MHz band and refarmed the AWS band for LTE. This unfortunately means lower data speeds for the owners of non-LTE phones in some cases, because they had HSPA+ 42 on the AWS band but only HSPA+ 21 on 1900MHz (T-Mobile owns less 1900MHz spectrum so they are unable to deploy HSPA+ 42 there), but it does improve compatibility for people who bring AT&T phones over to T-Mobile service.
T-Mobile and AT&T are ahead of Verizon and Sprint in battery life because of their use of GSM. GSM is a widely used global standard while CDMA is mostly found in North America, so power efficiency of the GSM radio probably gets more attention. GSM reception is also less computationally intensive; the spread spectrum methods used by CDMA take more work to decode. This all has some impact even if you never talk on the phone, because it is using power to maintain its connection on the network.
Talk time is a more complex equation. Both standards use power control, so battery life is lower in weak signal areas. A CDMA radio has more stringent signal linearity requirements - it must maintain constant power and constant signal delay across the entire spread spectrum - that make it less efficient than a GSM radio.
Then there is data power consumption. That is a complex calculus of amounts of data, bands and modes used for data communication, and network congestion. AT&T and T-Mobile have a mix of LTE, HSPA+, and HSDPA, and heaven forbid, EDGE in remote areas. (T-Mobile had HSPA+ 42 in some areas though they no longer offer that speed in areas with LTE coverage; AT&T topped out at HSPA+ 21.) Verizon and Sprint mix LTE with 1xEV-DO and 1xRTT; their non-LTE networks are much slower, so any data transmission on those networks takes longer and uses more power.
Sony is hardly going to disappear; their huge presence as a media company (movies and music) will guarantee that. And they have pockets of excellence in hardware. Their still and video cameras have been very nice ever since they started supporting standard SD cards in addition to MemoryStick. Their phone division has stepped up its game and is building some excellent Android devices. Their home audio equipment is also good, though that's not a growth market. The PS4 is doing OK. And they make outstanding 4K projectors for theater use.
But the company is doing badly in a lot of markets that used to be strong points for them. They have abandoned desktop and laptop computers, and now e-readers. They are nearly irrelevant in portable audio. Television was once their flagship product, but they are now nearly invisible in the TV market except for the ultra-high-end niche.
What we are seeing now is Sony reconfiguring itself to be a company that can survive. Getting out of markets where they can no longer be competitive is part of that. It is true that they COULD have been strong in some of those markets had they made better products and not insisted on over-controlling DRM. But Sony is a long way from dead, unlike Radio Shack. (Radio Shack is doing the right things now - lessening their dependence on postpaid phones while staying big in prepaid, and making a push for the maker market - but it's probably five years too late; they no longer have the necessary financial reserves to execute their current plan.)
To be fair, SQL isn't an end user tool; it's meant for software developers and system administrators. Those people will be familiar with that rather standard bit of industry jargon. The objection is more valid for the other things on your list.
Hardware video acceleration only helps you if you are using codecs that existed before the chip was manufactured. Widespread use of next-generation codecs such as H.265 is coming soon along with 4K content, so the ability to decode new video formats in software (possibly OpenCL GPU-assisted software) will matter. The extra power consumption for software decoding is death in a mobile environment because of the battery life hit, but using a few extra watts isn't that big a deal on a system that is plugged in.
Voice recognition is a non-starter in many situations; either there is too much background noise for it to work reliably (using the phone in a club or in the subway) or talking is socially unacceptable (sitting in a restaurant, checking email during a meeting).
In the past, you made an album as a musician and you got $1 or $2. After you paid out your advances, and the accounting game was rigged to make it very difficult to do that. Now you make the album yourself, and you actually make $10 when you sell a copy of it at your gig. Or you put your songs on iTunes and make 50 cents per song sale. (This is all assuming you DON'T have a major label contract.)
One fundamental difference. Improving the JPEG encoding used by Facebook would reduce their bandwidth use without requiring users or browser developers to do anything. Moving to H.265 or VP9 video encoding requires two things: that browsers add support for those video formats (some have already done that), and users upgrade to browser versions that include the support.
Most likely, Facebook would not transcode existing images; unless they saved the originally uploaded files (rather than the transcoded ones they made when they were uploaded) that would involve generation loss and thus a degradation of image quality. They would use the new encoder when they transcode new uploads. YouTube DOES retain the original uploads (though they did not in the early days which is why many older videos are only available in 240p or 144p) so they have been able to re-encode videos as new formats become available.
Slashdot Mirror
You might be somebody who would love to have 60fps 4K video, but have the misfortune of living in some place where a 4mbps connection is the fastest one available.
Embedded assignment in C came from a different era - one when both computers and compiler technology were much more limited. Using it made it possible to generate more efficient code for the common sequence of operations where you want to calculate a new value and both save it and make a test based on it.
Let's look at the code that a naive compiler would produce for two hypothetical sequences. (These are given in a simple hypothetical assembly language, but the examples are representative of what real code would have looked like. Details such as which register was used, relevant to the PDP-11 but not to many of its predecessors, are omitted.) First, the straightforward one without embedded assignment:
a=b
LOAD A
STORE B
if (a)...
LOAD A
BEQ NOTA
(code that follows the comparison)
NOTA: (code after the if)
Next up, the code generated when the conditional assignment is used: ...
if (a=b)
LOAD A
STORE B
BEQ NOTA
(code that follows the comparison)
NOTA: (code after the if)
The redundant load operation is now gone, yielding a 25% reduction in code size and execution time for this test on computers that were in use when C was invented.
The original implementations of C had to run on computers that were hopelessly limited by modern standards; a typical configuration would be a PDP-11 with 16K bytes of memory. To put that into perspective, that is less powerful than the microcontroller that runs your neighborhood traffic light. Any decent modern C compiler will recognize the unnecessary load and optimize it out unless a is declared volatile, a declaration that didn't exist back in the early days of C because there was also no such thing as register variables, let alone compilers that would automatically promote some variables to that status. But the compiler that ran on that 16K PDP-11 did not perform that optimization, and attempting to add that capability to the compiler would have resulted in something too slow to be usable.
It's a bit more complicated than just decompressing the images. I suspect the browsers are keeping the complete HTML rendering of as many open tabs as possible so you can switch to them instantly. They are also keeping any Javascript code on the pages active (if not actually running) so they will be in the same state as when you left them. If each tab had to be re-rendered when you switched to it there would be a noticeable lag when you switch, and users wouldn't like that.
Memory may be cheap, though not as cheap as it was a couple of years ago; the street price of RAM has nearly doubled since then. But lots of low-end laptops have rather low limits on how much RAM you can install, like Bay Trail laptops with 4GB, and mobile devices like phones and tablets can't be upgraded at all and are likely to have a measly 2GB.
Your suggestion of letting the user set a limit is a good one. Firefox can't possibly know what the application mix of every user will be. If, for example, you load Firefox and a bunch of tabs and then launch Photoshop or Eclipse, Firefox is likely to have grabbed more of your RAM that it really should have. That's a likely usage pattern for somebody who uses webmail at work. You start your day by reading your email and checking your calendar, and then launch your work applications after you have gotten through it.
That doesn't necessarily mean that Firefox is leaking memory. It could mean that it is keeping it for its own reuse rather than releasing it back to the system. If the expectation is that the browser user will soon need the memory again (perhaps by opening 19 new tabs), that is likely to be more efficient than releasing it to the system pool and then later asking for it again. On the other hand, if the user next needs all that memory to run something OTHER than Firefox it's not so good.
The Chrome model of using a separate process for each tab leads more naturally to release of memory to the system, as there is no alternative when the tab's process is terminated.
Not caching uncompressed graphics, as you are suggesting, is an interesting possibility for memory-limited systems. To see whether it is a net gain it would be necessary to build a browser that did it, preferably by doing a modification of an existing browser like Firefox (so you could compare apples to apples) rather than creating a completely new one.
Couldn't you build that kernel yourself? Or does it refuse to build with that set of choices?
Some old titles haven't been released in newer formats, either because of lack of interest or because the rights have gotten hopelessly tangled. (In addition to the rights to the film itself, music rights are often an issue; licensing all the songs in an old movie or TV show can be prohibitively expensive. Ask any fan of WKRP in Cincinnati.) Even if you wanted to spend the money, you can't replace them with DVDs or digital downloads.
For some obscure movies there isn't much point to buying the DVD version. The only DVDs available come from low-budget companies that produced them by transferring a VHS tape or some equally bad source. Those DVDs look no better than the tape you already have.
Symbian can't really be said to have ever dominated the smartphone market, despite its large market share. Most of the Symbian devices were never used in a way that we would recognize as smartphone use; there was little use of apps at all and users never installed any additional apps.
Netbooks were a passing fad because they weren't quite good enough, and part of the reason they weren't quite good enough is that Microsoft imposed artificial restrictions on their hardware (display size and resolution, RAM) in an attempt to protect their main Windows business. The new crop of low cost Windows laptops will be good enough, because now they have competition from Chromebooks and they have to match the competition. It's likely that some of them will BE Chromebooks with a different keyboard and software load; I expect to see an Acer W720 soon (with either a hard drive or a larger SSD) though they might not call it that.
EC2 has also suffered significant outages. All online services will have one somewhere along the way.
I have had no sympathy for IE ever since Microsoft used their then-monopoly power in operating systems to destroy Netscape. I believe that the correct government response to Microsoft's actions would have been to require them to withdraw IE from the market (stop development, stop including it in future versions of Windows, and modify microsoft.com to refuse connections from it).
They really couldn't allow WP7-WP8 upgrades because the WP7 devices didn't have enough computing power. Notably, WP7 only supported a single processor core so none of the phones on the market included a dual or quad core CPU.
The people I feel really got shafted were buyers of WP7.5 phones. That came out very shortly before WP8, so people with phones less than a year old were out in the cold. What I think Microsoft should have done is given a free WP8 phone to everybody who bought a WP7.5 phone; there were so few sold that MS could have easily afforded it and it would have bought them some much needed market credibility.
Some web sites are strictly informational and gather no PII (personally identifiable information) or no information at all. There is no good reason for such a site to use HTTPS - there are no security issues associated with its use. Punishing the search rank of such a site for not using HTTPS is unfair.
The amount of the T-Mobile network that does 3G on the 1700MHz AWS band is dropping with time. In markets where T-Mobile has introduced LTE, they have moved 3G HSPA+ coverage to the 1900MHz band and refarmed the AWS band for LTE. This unfortunately means lower data speeds for the owners of non-LTE phones in some cases, because they had HSPA+ 42 on the AWS band but only HSPA+ 21 on 1900MHz (T-Mobile owns less 1900MHz spectrum so they are unable to deploy HSPA+ 42 there), but it does improve compatibility for people who bring AT&T phones over to T-Mobile service.
T-Mobile and AT&T are ahead of Verizon and Sprint in battery life because of their use of GSM. GSM is a widely used global standard while CDMA is mostly found in North America, so power efficiency of the GSM radio probably gets more attention. GSM reception is also less computationally intensive; the spread spectrum methods used by CDMA take more work to decode. This all has some impact even if you never talk on the phone, because it is using power to maintain its connection on the network.
Talk time is a more complex equation. Both standards use power control, so battery life is lower in weak signal areas. A CDMA radio has more stringent signal linearity requirements - it must maintain constant power and constant signal delay across the entire spread spectrum - that make it less efficient than a GSM radio.
Then there is data power consumption. That is a complex calculus of amounts of data, bands and modes used for data communication, and network congestion. AT&T and T-Mobile have a mix of LTE, HSPA+, and HSDPA, and heaven forbid, EDGE in remote areas. (T-Mobile had HSPA+ 42 in some areas though they no longer offer that speed in areas with LTE coverage; AT&T topped out at HSPA+ 21.) Verizon and Sprint mix LTE with 1xEV-DO and 1xRTT; their non-LTE networks are much slower, so any data transmission on those networks takes longer and uses more power.
Sony is hardly going to disappear; their huge presence as a media company (movies and music) will guarantee that. And they have pockets of excellence in hardware. Their still and video cameras have been very nice ever since they started supporting standard SD cards in addition to MemoryStick. Their phone division has stepped up its game and is building some excellent Android devices. Their home audio equipment is also good, though that's not a growth market. The PS4 is doing OK. And they make outstanding 4K projectors for theater use.
But the company is doing badly in a lot of markets that used to be strong points for them. They have abandoned desktop and laptop computers, and now e-readers. They are nearly irrelevant in portable audio. Television was once their flagship product, but they are now nearly invisible in the TV market except for the ultra-high-end niche.
What we are seeing now is Sony reconfiguring itself to be a company that can survive. Getting out of markets where they can no longer be competitive is part of that. It is true that they COULD have been strong in some of those markets had they made better products and not insisted on over-controlling DRM. But Sony is a long way from dead, unlike Radio Shack. (Radio Shack is doing the right things now - lessening their dependence on postpaid phones while staying big in prepaid, and making a push for the maker market - but it's probably five years too late; they no longer have the necessary financial reserves to execute their current plan.)
To be fair, SQL isn't an end user tool; it's meant for software developers and system administrators. Those people will be familiar with that rather standard bit of industry jargon. The objection is more valid for the other things on your list.
Hardware video acceleration only helps you if you are using codecs that existed before the chip was manufactured. Widespread use of next-generation codecs such as H.265 is coming soon along with 4K content, so the ability to decode new video formats in software (possibly OpenCL GPU-assisted software) will matter. The extra power consumption for software decoding is death in a mobile environment because of the battery life hit, but using a few extra watts isn't that big a deal on a system that is plugged in.
OK Cupid's experiments don't bother me as much as Facebook's do because online dating is already a big social experiment.
What ultra portable laptop? Macbook Air, Surface Pro, Chromebooks, Ultrabooks. The category is alive and well.
They don't? What about all that texting?
Voice recognition is a non-starter in many situations; either there is too much background noise for it to work reliably (using the phone in a club or in the subway) or talking is socially unacceptable (sitting in a restaurant, checking email during a meeting).
In the past, you made an album as a musician and you got $1 or $2. After you paid out your advances, and the accounting game was rigged to make it very difficult to do that. Now you make the album yourself, and you actually make $10 when you sell a copy of it at your gig. Or you put your songs on iTunes and make 50 cents per song sale. (This is all assuming you DON'T have a major label contract.)
One fundamental difference. Improving the JPEG encoding used by Facebook would reduce their bandwidth use without requiring users or browser developers to do anything. Moving to H.265 or VP9 video encoding requires two things: that browsers add support for those video formats (some have already done that), and users upgrade to browser versions that include the support.
Most likely, Facebook would not transcode existing images; unless they saved the originally uploaded files (rather than the transcoded ones they made when they were uploaded) that would involve generation loss and thus a degradation of image quality. They would use the new encoder when they transcode new uploads. YouTube DOES retain the original uploads (though they did not in the early days which is why many older videos are only available in 240p or 144p) so they have been able to re-encode videos as new formats become available.