With low value commodities like games, music etc. there never reaches a point where the market is so saturated that targeting the biggest group doesn't make sense. In our fictional example, you'd need 100% of one of the niche groups to buy your game to equal the success of only 20% of the mainstream group buying your game.
I'm quite confident that the market is so saturated that it is very hard to get even close to 20% of the mainstream customers to buy your mainstream product. The question is how many you could get to buy a niche product, and what price you could sell it at.
Are people who don't like the mainstream products going to buy them anyway or save their money for that one niche product, they really like? Maybe there are people who would rather own a single niche product than three mainstream products. If you are targeting those, twice the cost for a niche product wouldn't be a problem. But even for a niche product decreasing the price is going to increase the customer base.
I can understand why aiming for mainstream market share leads to homogenization initially. But why does it keep doing that? Doesn't there come a point where another mainstream game is going to lose out due to tough competition from the number of games they are competing with? At that point one would think niche markets would start looking attractive.
They can't make ordinary Search ad-free because ads on the search parge are where almost all of their money comes from.
Of course I am not suggesting that they remove all ads from their free products. I know that is not realistic, and in most cases those ads are actually relevant. (With the exception of most of the ads in YouTube, which are very obnoxious.)
I was suggesting that in addition to their current ad placements, they have a service where you can search only in ads. That service is obviously not going to have as many users as their primary search. But it is a service that would not require many users to be profitable.
People who choose to go and search in just ads are much more likely to click on an ad, than users who use the standard search. As such the price per click doesn't have to be nearly as high in that section. Queries that on the front page would get only a single ad could give a lot more results in the ads only section. In that section the page should display all the matching ads (up to 10 per page) regardless of how low their bids are. Minimum prices per click shouldn't apply in that section, so the lowest bid (placing in the last position of the results) would actually get the clicks for free, if users choose to click it.
In other words, in that section lack of budget from the advertiser shouldn't prevent their page from being reached by a user, who is truly interested in following that ad.
That suggestion isn't very related to the thread. The only connection is that both my websearch suggestion and my adssearch suggestion involve creating a new subdomain for the specialized search. Though there may be users interested in being able to do a websearch without any ads at all, I don't think there are enough who are really willing to pay for it. And personally, I wouldn't even want such a page, even if I could get it for free. I like having the ads on the search page, though I would prefer if they'd all be moved back to their original location to the right of the search results.
Google can do whatever they want on their search results. However, they're *not* allowed to (say) push Maps at the expense of Bing and others, solely because of their dominant position in search.
When you type a search on google.com, it will perform a search in both Google websearch and in Google Maps (as well as other Google search engines) and merge the results together as a single result page. Some say doing this is pushing Google Maps at the expense of Bing.
As far as I know Google does not have a feature allowing users to chose to get results from Google websearch mixed with search results from Bing Maps. I don't even know if Bing has an API that would permit this in the first place. Moreover Google wouldn't be able to give guarantees about the reliability of such a service. My guess is that if such a construction was ever introduced, Bing would frequently fail to provide an answer within the very strict latency limits that Google enforces internally. The result would be that the Bing Maps search results would frequently disappear from the search results because they simply hadn't arrived before the result page was sent to the user. That would in turn lead to people making up stories about Google applying censorship on Bing Maps results.
The same sort of timeout issue could also happen with search results from Google Maps. But it is less likely due to both services being hosted within the same production environment. There are actually Site Reliability Engineers at Google responsible for dealing with such situations, and they have access to loads of detailed timing information that will allow them to pinpoint the cause of any such problems and fix them. Doing the same across two different production environments run by two different companies can never achieve the same level of transparency for the people running the systems. And I can assure you that the Site Reliability Engineers at Google don't want to be bothered every 15 minutes with reports of results not being delivered within the deadline, when they have no way of pinpointing the cause of the problem let alone do something about it.
In short if Google search wanted to display Bing Maps results on equal terms with Google Maps results, then Microsoft would need to hand over all the data to Google such that the Bing Maps search could be executed within the Google production environment. I don't think either company want that to happen.
So is a product, which merges Google websearch results with Google Maps results, allowed to exist in the first place?
Web search was Google's primary business, which is why they stopped doing it. Sounds strange? Nevertheless that is roughly what happened.
Initially there was google.com, and it was a web search engine. Later Google started introducing other kinds of searches, which would be hosted on subpages/subdomains of google.com. Since web search was the primary business, it remained on the front page.
At some point Google thought it would be good for the users if they could type in their search query in one place and get merged results from all of the different kinds of search, which Google is offering. That was introduced a few years ago, and it was considered such a great idea, that it would go on the front page, displacing the web search.
All the other kinds of search still had their own URLs, on which the individual kind of search could be used. But Google websearch never had such a page in the first place, because it had been on the front page. So now Google is no longer offering websearch alone.
Google should reintroduce the websearch on a subdomain like web.google.com or similar. And it should also introduce a subdomain for the merged search like everything.google.com (or something shorter). Having those existing as separate pages allowing you to search them separately is both a service to the users, who sometimes want to search specific kind of content, and also clears up some of the confusion leading to stories like this one.
Once those two kind of searches each have their own page, the remaining question is which of them users should see when they just go to google.com. At that point authorities will sound even more stupid, once they come and say, you are not allowed to show all search results from the front page, only web search. But it would be less of a problem for Google to comply, because even if it does comply, the search page with all results, which users prefer, will still exist on a slightly longer URL.
While they are at it. I think they should also introduce ads.google.com or something like that, where you can go if you specifically want to search in ads. Payment rules should be slightly different for such a page. A larger percentage of users are likely to click on an ad on such a page, and the price per click should be adjusted down accordingly. Additionally those are users who want to see the ads, and thus should be shown any appropriate ads, even if the advertiser is out of budget.
nokias real browser sucks a** with 256 so good luck running it on 32mbytes minus OS
From 2007 until 2011 I had a Nokia for work. I don't know how much memory it had, but certainly not enough to run the browser reliably. It would frequently report that it did not have enough memory to open some page. And loading pages took ages.
But of course comparing such an old Nokia to Android phones I got 3 and 4 years later will of course come out with the Android phones ahead. Most of that will be due to the development happened during those years, and less due to the different operating system. I just haven't used more recent Nokia phones.
unless this "security researcher" can show a way to eavesdrop on that connection to nokias servers this is a total non-story.
No. Anybody who can get access to those proxies will then have access to lots of data, which users didn't expect to exist in clear anywhere between their phone and the site they are using. Additionally we don't know how well those proxies validate the certificates of the servers. Even if the connection from the phone to the proxy is secured a mitm attack on the connection from the proxy to the https server could be feasible, if the proxy accepts any certificate on the server.
even more practically these proxies can be used to get around on bans on websites.
Until the ban is applied directly to the proxies in which case a site you may have been able to access in the first place gets blocked. And some countries may decide to ban connections from the phones to those proxies, because they cannot see what you are trying to access.
An alternative connection only make you less likely to experience such filtering if the browser can automatically detect that filtering is happening, and then switch to the other method.
The issue is that the phone is not good enough to run a real browser. So instead the mini browser get simplified instructions from the servers where the actual HTML parser is.
So basically you are running a remote browser on Nokia's or Opera's servers.
If that's what Nokia is doing, then the article is totally inaccurate. In the article there is no suggestion the phone isn't capable of running a full browser. The proxies are just used to compress the data better before being sent to the client.
The reason Nokia is able to do this is that they control the browser. According to the article browsers on Nokia phones are delivered with a certificate, that allows Nokia to perform this MITM attack. They call it a feature and provide a plausible explanation of what benefit it has for the users. However enabling such a risky feature without user consent is a really bad move and means users should no longer trust Nokia products as much as they have done in the past.
You have to run the Linpack benchmark and report that.
And I guess no distributed computing platform is ever going to score in top 500 according to that benchmark. The communication performance between nodes is very important to most parallel algorithms. Any decent benchmark would take that into account. A real super computer has much faster communication between the nodes, than what you can achieve across the Internet. Both throughput and latency matters. There are some specific problems which can be split into parts that can be computed independently by nodes without communication between them, but most super computers are used for tasks, that do not fall into that class.
At some point I heard the rule of thumb, that when you are building a super computer, you divide your funds in three equal parts. One of those was to be spent on the interconnect. I don't recall what the other two were supposed to be spend on.
Did you confront the vendor? If so what did they say?
I handed over the information to a colleague, who was handling the interaction with that vendor. So I don't know if the vendor was confronted with this, or what their reaction was. Soon thereafter I transferred to a development project which would get us out of the vendor-lock-in, which we had found ourselves in.
based on when you had a job that will soon be replaced by a robot
I used to work as an engineer at Google. I did not work in a data center, but I did interact enough with the people working there to know that they are much more intelligent than a robot. If somebody had come to our team with a robot telling us, this robot can do the same work as a person in the data center at a fifth the price of a person, we would have responded: "Go away, we don't want your robot."
I worked at Google for multiple years, and during that time I did not even once need to work with a Microsoft product.
I interviewed lots of people applying for jobs at Google. I may have come across resumes, which stated that the candidate could use Microsoft Office. I always considered that a pointless piece of information to waste space on in a resume. I don't care which office suites the candidate knows. I would judge candidates on skills that were more important to the job than the use of an office suite. Sometimes phone interviews would cover some programming skills, and we would have the candidate write code to solve a specific task. In order to let the interviewer see the code as the candidate was writing it, this was done using Google Docs.
But if the sector is completely unreadable or returns incorrect CRC (that is, drive's internal CRC that is irrelevant of how the drive is formatted) then the drive will return an error to the operating system and you will be notified of it. The drive does not automatically reallocate such sectors as it will wait until the OS tries to write data to the broken sector before the drive reallocates it exactly for the reason that there wouldn't be silent corruption to files without users' knowledge.
That is all correct. If you are lucky, retrying the read may help. If the hard disk does not receive any writes for that sector, it does not get relocated. If the hard disk repeatedly receives read requests for that sector, it will try to read it each time it gets a read request. If eventually the read succeeds, then the sector gets relocated at that time.
So relocated sectors doesn't mean lost data. However relocated sectors is a warning sign that the drive may be dying. The study on hard drive failures, which Google did a few years back found that even a single relocated sector meant a significant increase in the likelihood of the disk failing.
Two DOA RMAs for the same part. And yes, that's happened to me again since that first time.
I have experienced that as well. I won't name the vendor, but I was working for one of their largest customers. At one time I investigated a DOA case in more detail. We had records about all our previous RMA cases, and it turns out I could find the serial number of the DOA part in multiple previous RMA cases. Once I knew this sort of thing was happening, I looked through our records and found many individual serial numbers which we had created RMA cases for more than once.
So it appears that sometimes the faulty part returned in an RMA case is simply put in the stash of new parts to be shipped to customers.
the idea of writing every sector and then using smartctl seems to be a good one.
In the past I have done a sequential write of all sectors with pseudo-random data, followed by a verification read to ensure that every sector contained the value I had written to it. Other than actually testing most of the surface of the disk, it would also catch any drive lying about its capacity. I don't know if there are hard drives, which lie about their capacity, but I have seen it on SD cards.
That is you enslaving men even as they venture out into the stars. "Dont go too far bold adventurer, you owe us and we shall be paid, no matter how far afield you wander."
I think there need to be a distinction between going there yourself and sending a robot to do it. Any person who is prepared to leave Earth and settle on an uninhabited celestial body can reasonably claim ownership of the area in which he settles. But if you build a robot to go and mine resources, and perhaps use some of those resources to build more robots, which can harvest even more resources, while you are staying back on Earth simply reaping the profits, then you shouldn't be able to claim ownership in the same way.
ECC RAM does reduce the rate of such errors, but it does not eliminate them. I have seen undetected single bit errors on systems that were entirely using ECC RAM. I am not saying the errors happened in the RAM, it could have happened on the bus or even inside the CPU. Once you start handling multiple PB of data, such errors show up, even if you are using ECC RAM. Using good hardware helps, but no matter how good hardware you choose, you shouldn't trust it. You need end-to-end integrity at a higher level, that is how we noticed that undetected bit errors had been introduced by the hardware.
The integrity checks at the lower level only protects data for a small part of the flow. With gaps between the part of the data flow protected by one checksum and the part protected by another checksum, there is a window for errors to be introduced. You can design for such low level integrity checks to overlap and thereby giving you something that is as good in detecting random corruption as an end-to-end integrity check. But it requires lots of understanding of how the hardware operates at the very lowest levels to design for such an overlap of of integrity checks. A design with a single end-to-end integrity check has much less risk of introducing windows for corruption through design flaws.
OpenDNS does have a history of hijacking connections by forging DNS replies. At some time in the past attempting to look up google.com on any of the OpenDNS servers would actually give you an IP address owned by OpenDNS. OpenDNS has stopped hijacking of google.com domains. I don't know what convinced OpenDNS to stop doing that.
I've seen a lot of people suggest "just use Google DNS", but frankly it's a disturbing trend (unless, naturally, your existing DNS provider is even less trustworthy.)
Many other DNS providers have a history of sending incorrect DNS replies in order to hijack connections. Those hijackings are mostly aimed at http connections, but due to the way the protocol works, there is no way to distinguish, and other connections will be hijacked as well.
Google Public DNS has never manufactured such incorrect DNS replies. Given that track record Google Public DNS is one of the most trustworthy DNS services.
Criticism against Google Public DNS generally has the form: "If I had access to all that information, I would find way to profit from it. So, that must be Google's plan as well." Whenever you see criticism matching that form, you should assume it is slander regardless of who it is aimed against. Instead look for documentation.
Often when companies are snooping on information, they are leaving some way to find out. For example if you can document, that simply looking up a domain name through Google Public DNS can cause that domain name to show up in other places, then you'd have a case. But you'd have to use something unique. I just attempted the following experiment: I send a lookup of 3fb25482acdae1c8f977889ac870275630d9807a.some-random-string.org to 8.8.8.8 and to 8.8.4.4. If the random string at some point in the future shows up in a Google search, then that would be suspicious. Just for tracking purposes, the first label in that domain name is actually SHA1 of the random string, I used.
A filesystem approach is the only way to ensure end-to-end data integrity
Integrity checks in the file system certainly provides much better guarantees than integrity checks on the storage level. And anybody designing file systems today should build integrity checks into their file systems. But the higher a layer you move the integrity checks to, the closer you get to real end-to-end integrity. File system integrity checks don't protect data while it is sitting in memory.
If you copy a file from one file system to another, it can still be corrupted in transit. Even if both source and destination file system have build in integrity checks, the copy could get corrupted in the process. But if the source and destination file systems both have integrity checks, they could provide some API to facilitate simpler integrity checks at the higher level. For example if both source and destination file system use a hash-tree for integrity checks, there could be an ioctl to retrieve the root of said hash-tree. Then the cp command could call this after copying and compare hashes of source and destination.
There is 16-bit Real-Mode, 32-bit Real-Mode, and 32-bit Protected Mode.
Actually protected mode was introduced on the 286, which was 16 bit only. The 32 bit mode only came later with the 386. On the 386 protected mode was extended from 16 to 32 bits, but remained fully backward compatible. In protected mode you can switch between 16 and 32 bit code. As far as I remember the segment descriptor decides if a segment contains 16 or 32 bit code.
You can, for instance, write the boot loader in pure 32-bit Real Mode, but you would still be limited to 1 MB until you switch from Real Mode to Protected Mode.
I suppose the limit is actually 16 bit segment and 16 bit offset addressing, which means you can address slightly more than 1MB, but it is not a linear address space.
you can indeed go from 16-bit mode directly to 64-bit mode with the AMD64/Intel64 instruction sets.
What I get from your links is that it is possible to do it, even though the documentation states something else. What I recalled was what the documentation said.
you do not need to do anything special to go from 16-bit real-mode to 32-bit real mode aside from changing what instructions you are using.
As far as I recall it is still called protected mode even if you don't enable paging.
What would it be compatible with, exactly speaking?
When I say compatible I mean it has 16, 32, and 64 bit modes. Just as you can write a BIOS replacement that switches to 64 bit mode as the first thing it does, you could write one which on a CPU starting in 64 bit modes switches directly to 16 bit mode. The choice between 16 and 64 bit mode could be made by the motherboard pulling a specific pin high or low while the CPU is being reset. Or a step could be taken directly to have the CPU power on in 64 bit mode regardless of any inputs. Obviously the BIOS would have to be modified slightly to work with a CPU starting in 64 bit mode. Operating systems don't have to be modified because of this.
Operating systems that expect to start in 16-bit mode wouldn't boot on it.
Lots of code gets executed before the operating system even starts to boot. There can be many switches between 16, 32, and 64 bit modes before the first operating system code gets executed. Changing what mode is active when the CPU powers up and changing what mode is active when control transfers from BIOS to bootloader as well as from bootloader to OS are three different choices, which can be made independently of each other.
You have to change all three of them to be 64 bit mode before you can even consider removing the 16 and 32 bit modes from the CPUs. If CPU manufacturers want to get rid of those old modes, they need to first produce CPUs that can power on in 64 bit mode, otherwise there can't be a BIOS with no 16 bit dependencies.
But I guess the CPU manufacturers don't really care about that cruft being carried along since it is just a tiny corner of silicon, which has already been developed and works well enough for what is needed during boot.
Slashdot Mirror
I'm quite confident that the market is so saturated that it is very hard to get even close to 20% of the mainstream customers to buy your mainstream product. The question is how many you could get to buy a niche product, and what price you could sell it at.
Are people who don't like the mainstream products going to buy them anyway or save their money for that one niche product, they really like? Maybe there are people who would rather own a single niche product than three mainstream products. If you are targeting those, twice the cost for a niche product wouldn't be a problem. But even for a niche product decreasing the price is going to increase the customer base.
I can understand why aiming for mainstream market share leads to homogenization initially. But why does it keep doing that? Doesn't there come a point where another mainstream game is going to lose out due to tough competition from the number of games they are competing with? At that point one would think niche markets would start looking attractive.
Of course I am not suggesting that they remove all ads from their free products. I know that is not realistic, and in most cases those ads are actually relevant. (With the exception of most of the ads in YouTube, which are very obnoxious.)
I was suggesting that in addition to their current ad placements, they have a service where you can search only in ads. That service is obviously not going to have as many users as their primary search. But it is a service that would not require many users to be profitable.
People who choose to go and search in just ads are much more likely to click on an ad, than users who use the standard search. As such the price per click doesn't have to be nearly as high in that section. Queries that on the front page would get only a single ad could give a lot more results in the ads only section. In that section the page should display all the matching ads (up to 10 per page) regardless of how low their bids are. Minimum prices per click shouldn't apply in that section, so the lowest bid (placing in the last position of the results) would actually get the clicks for free, if users choose to click it.
In other words, in that section lack of budget from the advertiser shouldn't prevent their page from being reached by a user, who is truly interested in following that ad.
That suggestion isn't very related to the thread. The only connection is that both my websearch suggestion and my adssearch suggestion involve creating a new subdomain for the specialized search. Though there may be users interested in being able to do a websearch without any ads at all, I don't think there are enough who are really willing to pay for it. And personally, I wouldn't even want such a page, even if I could get it for free. I like having the ads on the search page, though I would prefer if they'd all be moved back to their original location to the right of the search results.
When you type a search on google.com, it will perform a search in both Google websearch and in Google Maps (as well as other Google search engines) and merge the results together as a single result page. Some say doing this is pushing Google Maps at the expense of Bing.
As far as I know Google does not have a feature allowing users to chose to get results from Google websearch mixed with search results from Bing Maps. I don't even know if Bing has an API that would permit this in the first place. Moreover Google wouldn't be able to give guarantees about the reliability of such a service. My guess is that if such a construction was ever introduced, Bing would frequently fail to provide an answer within the very strict latency limits that Google enforces internally. The result would be that the Bing Maps search results would frequently disappear from the search results because they simply hadn't arrived before the result page was sent to the user. That would in turn lead to people making up stories about Google applying censorship on Bing Maps results.
The same sort of timeout issue could also happen with search results from Google Maps. But it is less likely due to both services being hosted within the same production environment. There are actually Site Reliability Engineers at Google responsible for dealing with such situations, and they have access to loads of detailed timing information that will allow them to pinpoint the cause of any such problems and fix them. Doing the same across two different production environments run by two different companies can never achieve the same level of transparency for the people running the systems. And I can assure you that the Site Reliability Engineers at Google don't want to be bothered every 15 minutes with reports of results not being delivered within the deadline, when they have no way of pinpointing the cause of the problem let alone do something about it.
In short if Google search wanted to display Bing Maps results on equal terms with Google Maps results, then Microsoft would need to hand over all the data to Google such that the Bing Maps search could be executed within the Google production environment. I don't think either company want that to happen.
So is a product, which merges Google websearch results with Google Maps results, allowed to exist in the first place?
Web search was Google's primary business, which is why they stopped doing it. Sounds strange? Nevertheless that is roughly what happened.
Initially there was google.com, and it was a web search engine. Later Google started introducing other kinds of searches, which would be hosted on subpages/subdomains of google.com. Since web search was the primary business, it remained on the front page.
At some point Google thought it would be good for the users if they could type in their search query in one place and get merged results from all of the different kinds of search, which Google is offering. That was introduced a few years ago, and it was considered such a great idea, that it would go on the front page, displacing the web search.
All the other kinds of search still had their own URLs, on which the individual kind of search could be used. But Google websearch never had such a page in the first place, because it had been on the front page. So now Google is no longer offering websearch alone.
Google should reintroduce the websearch on a subdomain like web.google.com or similar. And it should also introduce a subdomain for the merged search like everything.google.com (or something shorter). Having those existing as separate pages allowing you to search them separately is both a service to the users, who sometimes want to search specific kind of content, and also clears up some of the confusion leading to stories like this one.
Once those two kind of searches each have their own page, the remaining question is which of them users should see when they just go to google.com. At that point authorities will sound even more stupid, once they come and say, you are not allowed to show all search results from the front page, only web search. But it would be less of a problem for Google to comply, because even if it does comply, the search page with all results, which users prefer, will still exist on a slightly longer URL.
While they are at it. I think they should also introduce ads.google.com or something like that, where you can go if you specifically want to search in ads. Payment rules should be slightly different for such a page. A larger percentage of users are likely to click on an ad on such a page, and the price per click should be adjusted down accordingly. Additionally those are users who want to see the ads, and thus should be shown any appropriate ads, even if the advertiser is out of budget.
From 2007 until 2011 I had a Nokia for work. I don't know how much memory it had, but certainly not enough to run the browser reliably. It would frequently report that it did not have enough memory to open some page. And loading pages took ages.
But of course comparing such an old Nokia to Android phones I got 3 and 4 years later will of course come out with the Android phones ahead. Most of that will be due to the development happened during those years, and less due to the different operating system. I just haven't used more recent Nokia phones.
No. Anybody who can get access to those proxies will then have access to lots of data, which users didn't expect to exist in clear anywhere between their phone and the site they are using. Additionally we don't know how well those proxies validate the certificates of the servers. Even if the connection from the phone to the proxy is secured a mitm attack on the connection from the proxy to the https server could be feasible, if the proxy accepts any certificate on the server.
Until the ban is applied directly to the proxies in which case a site you may have been able to access in the first place gets blocked. And some countries may decide to ban connections from the phones to those proxies, because they cannot see what you are trying to access.
An alternative connection only make you less likely to experience such filtering if the browser can automatically detect that filtering is happening, and then switch to the other method.
The issue is that the phone is not good enough to run a real browser. So instead the mini browser get simplified instructions from the servers where the actual HTML parser is. So basically you are running a remote browser on Nokia's or Opera's servers.
If that's what Nokia is doing, then the article is totally inaccurate. In the article there is no suggestion the phone isn't capable of running a full browser. The proxies are just used to compress the data better before being sent to the client.
There must be serious flaws in HTTPS if they can decrypt the traffic for hosts that they don't control the certs for.
They control the browser. According to the article, the necessary certificate is installed on phones as Nokia ships them.
The reason Nokia is able to do this is that they control the browser. According to the article browsers on Nokia phones are delivered with a certificate, that allows Nokia to perform this MITM attack. They call it a feature and provide a plausible explanation of what benefit it has for the users. However enabling such a risky feature without user consent is a really bad move and means users should no longer trust Nokia products as much as they have done in the past.
You have to run the Linpack benchmark and report that.
And I guess no distributed computing platform is ever going to score in top 500 according to that benchmark. The communication performance between nodes is very important to most parallel algorithms. Any decent benchmark would take that into account. A real super computer has much faster communication between the nodes, than what you can achieve across the Internet. Both throughput and latency matters. There are some specific problems which can be split into parts that can be computed independently by nodes without communication between them, but most super computers are used for tasks, that do not fall into that class.
At some point I heard the rule of thumb, that when you are building a super computer, you divide your funds in three equal parts. One of those was to be spent on the interconnect. I don't recall what the other two were supposed to be spend on.
I handed over the information to a colleague, who was handling the interaction with that vendor. So I don't know if the vendor was confronted with this, or what their reaction was. Soon thereafter I transferred to a development project which would get us out of the vendor-lock-in, which we had found ourselves in.
I used to work as an engineer at Google. I did not work in a data center, but I did interact enough with the people working there to know that they are much more intelligent than a robot. If somebody had come to our team with a robot telling us, this robot can do the same work as a person in the data center at a fifth the price of a person, we would have responded: "Go away, we don't want your robot."
I worked at Google for multiple years, and during that time I did not even once need to work with a Microsoft product.
I interviewed lots of people applying for jobs at Google. I may have come across resumes, which stated that the candidate could use Microsoft Office. I always considered that a pointless piece of information to waste space on in a resume. I don't care which office suites the candidate knows. I would judge candidates on skills that were more important to the job than the use of an office suite. Sometimes phone interviews would cover some programming skills, and we would have the candidate write code to solve a specific task. In order to let the interviewer see the code as the candidate was writing it, this was done using Google Docs.
That is all correct. If you are lucky, retrying the read may help. If the hard disk does not receive any writes for that sector, it does not get relocated. If the hard disk repeatedly receives read requests for that sector, it will try to read it each time it gets a read request. If eventually the read succeeds, then the sector gets relocated at that time.
So relocated sectors doesn't mean lost data. However relocated sectors is a warning sign that the drive may be dying. The study on hard drive failures, which Google did a few years back found that even a single relocated sector meant a significant increase in the likelihood of the disk failing.
I have experienced that as well. I won't name the vendor, but I was working for one of their largest customers. At one time I investigated a DOA case in more detail. We had records about all our previous RMA cases, and it turns out I could find the serial number of the DOA part in multiple previous RMA cases. Once I knew this sort of thing was happening, I looked through our records and found many individual serial numbers which we had created RMA cases for more than once.
So it appears that sometimes the faulty part returned in an RMA case is simply put in the stash of new parts to be shipped to customers.
In the past I have done a sequential write of all sectors with pseudo-random data, followed by a verification read to ensure that every sector contained the value I had written to it. Other than actually testing most of the surface of the disk, it would also catch any drive lying about its capacity. I don't know if there are hard drives, which lie about their capacity, but I have seen it on SD cards.
I think there need to be a distinction between going there yourself and sending a robot to do it. Any person who is prepared to leave Earth and settle on an uninhabited celestial body can reasonably claim ownership of the area in which he settles. But if you build a robot to go and mine resources, and perhaps use some of those resources to build more robots, which can harvest even more resources, while you are staying back on Earth simply reaping the profits, then you shouldn't be able to claim ownership in the same way.
ECC RAM does reduce the rate of such errors, but it does not eliminate them. I have seen undetected single bit errors on systems that were entirely using ECC RAM. I am not saying the errors happened in the RAM, it could have happened on the bus or even inside the CPU. Once you start handling multiple PB of data, such errors show up, even if you are using ECC RAM. Using good hardware helps, but no matter how good hardware you choose, you shouldn't trust it. You need end-to-end integrity at a higher level, that is how we noticed that undetected bit errors had been introduced by the hardware.
The integrity checks at the lower level only protects data for a small part of the flow. With gaps between the part of the data flow protected by one checksum and the part protected by another checksum, there is a window for errors to be introduced. You can design for such low level integrity checks to overlap and thereby giving you something that is as good in detecting random corruption as an end-to-end integrity check. But it requires lots of understanding of how the hardware operates at the very lowest levels to design for such an overlap of of integrity checks. A design with a single end-to-end integrity check has much less risk of introducing windows for corruption through design flaws.
I have a translation solution that can get those XP clients to talk to IPv6 servers (it works a bit like NAT46).
OpenDNS does have a history of hijacking connections by forging DNS replies. At some time in the past attempting to look up google.com on any of the OpenDNS servers would actually give you an IP address owned by OpenDNS. OpenDNS has stopped hijacking of google.com domains. I don't know what convinced OpenDNS to stop doing that.
Many other DNS providers have a history of sending incorrect DNS replies in order to hijack connections. Those hijackings are mostly aimed at http connections, but due to the way the protocol works, there is no way to distinguish, and other connections will be hijacked as well.
Google Public DNS has never manufactured such incorrect DNS replies. Given that track record Google Public DNS is one of the most trustworthy DNS services.
Criticism against Google Public DNS generally has the form: "If I had access to all that information, I would find way to profit from it. So, that must be Google's plan as well." Whenever you see criticism matching that form, you should assume it is slander regardless of who it is aimed against. Instead look for documentation.
Often when companies are snooping on information, they are leaving some way to find out. For example if you can document, that simply looking up a domain name through Google Public DNS can cause that domain name to show up in other places, then you'd have a case. But you'd have to use something unique. I just attempted the following experiment: I send a lookup of 3fb25482acdae1c8f977889ac870275630d9807a.some-random-string.org to 8.8.8.8 and to 8.8.4.4. If the random string at some point in the future shows up in a Google search, then that would be suspicious. Just for tracking purposes, the first label in that domain name is actually SHA1 of the random string, I used.
Integrity checks in the file system certainly provides much better guarantees than integrity checks on the storage level. And anybody designing file systems today should build integrity checks into their file systems. But the higher a layer you move the integrity checks to, the closer you get to real end-to-end integrity. File system integrity checks don't protect data while it is sitting in memory.
If you copy a file from one file system to another, it can still be corrupted in transit. Even if both source and destination file system have build in integrity checks, the copy could get corrupted in the process. But if the source and destination file systems both have integrity checks, they could provide some API to facilitate simpler integrity checks at the higher level. For example if both source and destination file system use a hash-tree for integrity checks, there could be an ioctl to retrieve the root of said hash-tree. Then the cp command could call this after copying and compare hashes of source and destination.
Actually protected mode was introduced on the 286, which was 16 bit only. The 32 bit mode only came later with the 386. On the 386 protected mode was extended from 16 to 32 bits, but remained fully backward compatible. In protected mode you can switch between 16 and 32 bit code. As far as I remember the segment descriptor decides if a segment contains 16 or 32 bit code.
I suppose the limit is actually 16 bit segment and 16 bit offset addressing, which means you can address slightly more than 1MB, but it is not a linear address space.
What I get from your links is that it is possible to do it, even though the documentation states something else. What I recalled was what the documentation said.
As far as I recall it is still called protected mode even if you don't enable paging.
When I say compatible I mean it has 16, 32, and 64 bit modes. Just as you can write a BIOS replacement that switches to 64 bit mode as the first thing it does, you could write one which on a CPU starting in 64 bit modes switches directly to 16 bit mode. The choice between 16 and 64 bit mode could be made by the motherboard pulling a specific pin high or low while the CPU is being reset. Or a step could be taken directly to have the CPU power on in 64 bit mode regardless of any inputs. Obviously the BIOS would have to be modified slightly to work with a CPU starting in 64 bit mode. Operating systems don't have to be modified because of this.
Lots of code gets executed before the operating system even starts to boot. There can be many switches between 16, 32, and 64 bit modes before the first operating system code gets executed. Changing what mode is active when the CPU powers up and changing what mode is active when control transfers from BIOS to bootloader as well as from bootloader to OS are three different choices, which can be made independently of each other.
You have to change all three of them to be 64 bit mode before you can even consider removing the 16 and 32 bit modes from the CPUs. If CPU manufacturers want to get rid of those old modes, they need to first produce CPUs that can power on in 64 bit mode, otherwise there can't be a BIOS with no 16 bit dependencies.
But I guess the CPU manufacturers don't really care about that cruft being carried along since it is just a tiny corner of silicon, which has already been developed and works well enough for what is needed during boot.