I travel mostly from the US to somewhere in the EU. Not once have I ever entered the EU without having to collect my luggage and then go through border control. Countries included in this list: UK, Spain, Italy, Germany, Sweden, The Netherlands. Every one of those I had to. Now, once you enter the Schengen Treaty countries, yes, you don't have to, but that's because the EU has decided that there fundamentally aren't borders between Schengen Treaty countries. But seeing that the UK isn't one of the treaty countries, want to guess what you have to do with luggage when you go from the UK to mainland Europe or the other way around?
Incorrect, I've flown multiple times with British Airways between continental Europe and destinations in the US. I've never needed to touch my checked baggage at LHR, it's been checked all the way in both directions. I've also flown from continental Europe to Glasgow with an LHR transit. Checked all the way. But, hey, even if the UK is outside Schengen, the country is part of the customs union (for now...).
I was playing with "Ubuntu for Windows" on Windows 10 last week. While it is an interesting effort (and I was able to upgrade from the default Ubuntu 14.04 (Trusty Tahr) userland to the 16.04 (Xenial Xerus) userland with minimal dificulty), performance does not match that of a Lubuntu 16.04 VM on the same hardware running in VMWare Player. I was running repeated Monte Carlo-type simulations, and the same scripts and executables took twice as long to run under Ubuntu for Windows vs. the VM.
So, while interesting, it is still beta (and is labeled as such, and requires "developer mode" to be enabled in Windows 10), and it's not quite ready for prime time yet.
If you're getting that kind of performance difference, it sounds like you're really bound by I/O or (faulty?) thread synchronization. But, yeah, I would never use WSL for performance. For easy transparent prototyping, it's great and I've basically stopped using cygwin.
If the voice masking wasn't well done, couldn't you end up with an uncanny valley sort of situation with respect to how the applicants sounded? I can imagine a scenario in which the voice sounds "wrong" at a gut level, and that makes some interviewers uncomfortable.
And, overall, what do you think the tech community would be most open to? A person that sounds like a woman, but comes off as a bit of a tomboy (on account of actually being a man), or a man that seems oddly feminine or "weak", "fuzzy" or whatever attributes you would assign to socially acceptable female behavior? And how did men that had their voice masked into female fare, compared to non-masked men?
Take a MS Excel macro made on Windows, and run it in MS Excel on another Window machine...
Excel is horribly broken to the extent where macros stop working if you try to use them on a machine with a different language.
Not anymore than saying that a bash script breaks if you run it on a non-C locale. It MIGHT be true, if you actively rely on other stuff behaving in certain ways. And, if you're completely blind to the issues involved, it might very well happen. I've seen Java and C# code generate invalid SVG files etc by using decimal comma (taken from the current locale), rather than a decimal point. But, again, that doesn't mean that the software itself is broken. The author of Excel macros might, on the other hand, be far more likely than either of these groups to just cobble something together based on what seems to work.
Yeah, that's precisely what you would expect for a vulnerability in user space code. "Just" unzip a 7-zip file and suddenly any file in your home directory can be compromised... or gone. Run a vulnerability scanner on your e-mail server (with insufficient sandboxing), or on your web server for uploading files, and things get... worse.
"Those conflicting forces reduce skill applied in jobs filled by the mostly unqualified." Did you draw this conclusion by collection a lot a data and running the data through your own analysis? Or do you have some other way to prove such a broad accusation? The biggest problem we face to day is from those who use statistics to support their cause and opinions. We are constantly bombarded with poll results and nobody every questions how these results are derived. What statistical methods are being used that allows the pollsters to take a very small sample size and project those results on very large datasets? How do you ask 500 people their opinion on something and then apply those results against 400 million people?
By assuming random sampling, that's how. Whether that assumption is correct is a critical issue, but that is the case for any universe population significantly larger than your sample set. 500,000 or 400 million really does not matter - if you are ignorant of the demographics and how those interact with your sampling strategy, you're not gonna get a correct result.
If, on the other hand, you somehow manage to do random sampling of the true population, 400 people would be enough to nail preferences down to a few percent, (almost) no matter the total population size. And I guess this is the danger of statistics and big data. Intuition says one thing, simple statistical assumptions say another, and a more thorough treatment is rare.
There was one drive maker which actually did this. They had two drive platters at opposite ends, each independent of the other, and either could fail, letting the other completely take over. I've wondered why this isn't more commonplace, perhaps a drive form factor with four heads, all active/active and can handle a head array failing (perhaps lighting up SMART.) This wouldn't just allow for four times the I/O, but allow four different threads to write at the same time, which is useful for virtualization, although these days, virtualization should just go to SSD or a large I/O buffer due to all the random reads/writes.
There was a drive that had two actuators that could access the entire platter. That was the design, but I think in the end the complexity of multiple heads accessing the same sector was problematic because of the ordering of the operations (i.e., one head could write data to the sector that the other head was reading - if you didn't catch this, you would corrupt the data).
Plus, double the heads doubles the chance of a head crash.
It seems like NCQ, write and read caches (sometimes with flash hybrid modes) etc in current drives would bring enough complexity that additional physical heads would also be reasonable to implement. The abstraction in the drive firmware is much thicker these days.
Has to get around stack overflow protection canaries (-fstack-protector-strong or -all), address space randomization, and a non-executable stack and heap. Ubuntu has run -fstack-protector-strong (covers functions calling alloca()) since gcc 4.9 release after 2015-05, according to #1317307. Kees Cook added the -strong feature to gcc, and is part of Ubuntu's compiler team, so it went straight into Ubuntu.
Good luck exploiting this bug.
Denial of service by crashing the process is of course not as nasty as remote code execution, but it can easily be nasty enough, especially if the properties of DNS would allow you to penetrate deep inside networks and services generally believed to be protected. My personal favorite vector here would be XML exposed to parsers that auto-load whatever DTD or other schema that is specified.
The bug can hit you with DNS over TCP as well. While that is somewhat of an oddity, I am not yet confident to say that you can rule it out, especially if you have a MITM that might be able to trigger fallbacks. Since the TCP response could be fragmented over several packets, things rapidly grow beyond iptables capabilities there. (But the "TCP DNS response fragmented over several packets" would thankfully not propagate through layers of caching internal DNS servers.)
If you use C/C++ right, you do not end up writing a JIT compiler for a language never intended for it. This is a bug in v8. Now, we don't know where, but that's the kind of code that does things no one sane should ever do. It is supposed to take shortcuts and patch things on the fly. It's of course fully possible that this exploit is not in a performance-critical path, and then your comment is rather well placed. But I do think that anyone writing C/C++ in this context is a fool himself. It is for all practical purposes impossible to use C without doing bare pointer addressing. It is highly possible to use C++ without doing it, even though such use is not terribly widespread.
It's not like putting a sliced tomato on the kitchen sink in a humid climate will prevent other parts of your kitchen from attracting any mold spores around. Bacteria and prokaryotes are mostly incapable of macrosopic movement (especially in air). They are also able to rapidly expand populations. Therefore, a "colonist" doesn't choose to move to the best spot, foregoing a worse one. They will try everywhere. If they gain a foothold, that foothold is likely to just unleash further colonists into the less hospitable, but still slightly viable, habitats.
Well, for making this "frame rate" theory relevant, the question is not only if anything happens at or close the frame rate, but what is the frame stepping function? And, throwing relativity into the mix, in what reference frame?
A discretized spacetime would mean that the continuous solutions to the Schrödinger/Dirac equations are actually approximations that are better expressed by some discrete time stepping scheme. That could have macroscopic consequences. Especially so if for some weird reason Nature has a rather simple first-order scheme at its frame rate core. But, it does also mean that we would get slightly different results from different objects in free fall, depending on their overall speed relative to the reference frame. This would control the factor between the "local passage of time", and the actual number of "Planck time frames" used by the process. In addition, the discretization of time almost necessitates a discretization of space. This not only means that space has some small grid (not likely either, based on current theory). It also means that there are some absolute directions in space and that some physical processes would behave slightly differently (even if aggregated along macroscopic distances) if they are algined to these directions, or not.
Well, electron states being quantized has helped us to (truly) understand chemistry and create transistors as well as LEDs. By realizing that things are only allowed to make certain transitions under certain conditions, you can "cheat" and build up high-energy states that are far more stable than they really should be. I am not saying we would get macroscopic anti-gravity or a "Faraday cage for gravity", but this is kind of the space where we would get more specific explanations for how you might be able to accompish those things in theory. For very delicate experiments (similar to the one described!) and possibly sub-nanoscale manufacturing procedures, an understanding of a quantized nature of gravity influences might be useful, if only for better understanding the noise in measurements and tolerances.
Even if mass would be quantized, the Newtonian equation is m1m2/r^2. Even with discrete mass quanta (which is also false, see other replies), you would get a continuous spectrum of resulting forces. Inserting relativity here changes the expressions, but it would really just muddle things. So, no, there is no specific reason to believe gravity to be quantized - outside of an actual theory of quantum gravity.
If it is just a bug, then we should expect a quick fix and firmware release from VW. If, however, it was a conspiracy, and there is no way that VW EGR technology can ever be made to pass the NOx requirements (without additional hardware - AdBlu tanks), then VW is screwed.
My point is that a "too good to be true" bug could easily have quite devastating consequences if it's just fixed. If they remove 'false' in the putative "if (isInTest() || (isNOxReductionNeeded() && false) enableEGR();" line and this increases fuel consumption or reduces maximum torque a lot, they cannot simply release that fix.
Embedded automotive control systems and scientific research are quite different domains, but in science I've repeatedly been close to thinking I had solved a problem, just to realize that my benchmark was off and the code was not really working at all. I have not published any of those results (AFAIK) yet, but I've reviewed and seen publications with blatant errors. When you have reached the kind of result you hoped for and believed likely, you are not on guard anymore. Fixing the blatant error might very well mean that the whole work is pointless. The error is trivial, the consequences are not.
The sensors required to detect "test mode" and software driven EGR control hardware are already part of any modern car so there was no decision to "add" them to accomplish this cheat. But there had to be a strategic decision to not to add SNCR, and that is a decision that could only be made at a very high level.
Yes, but that was not a conspiracy. It was very clear in the specs and even highlighted as an advantage. The question is "who knew and approved, at what point, that this design would not work out in practice". Even the idea that smart design of the control regime would make it possible to achieve low emissions without SNCR is not, in itself, equivalent to fraud. It's only when this design becomes all about "detecting test conditions" things get really, really bad.
The linked article makes the point that the sensors and hardware would not be necessary. I think the writer seriously underestimates to what extent a modern car with protection systems will try to juggle different constraints. Things like non-driving wheel rotation (defeated by being on a lab stand) are needed for breaking systems and possibly to some extent to moderate throttle control for stability. Wheel movement patterns are also needed and useful, even if you don't actually have electric power steering.
Regulating the exhaust gas recirculation somehow also makes sense. You might go totally on and off, but you would certainly want to keep it at a sensible level. You want good acceleration and full combustion of fuel while still not emitting to much nitrous oxides. It makes total sense to me that you might want to design your control system to try to judge not only the current emission levels, but also the overall driving pattern (steady straight ahead, repeated stop and go, etc) with some kind of state machine to try to find the best EGR regulation regime. This requires sensors and ways to regulate the feature.
My most innocent guess about how something such as this might have happened was an intent to find a good regime that would give nice bursty performance, while keeping nitrous oxides low overall. Progressively, the control regime was pushed until it ended up in the corner where the case of EGR being properly activated under real-world conditions basically does not happen. Some parts of it might even in the end be a bug between the intended state transitions and the actual ones. Like all bugs that give performance that seem too good to be true on the metrics you really care about (fuel consumption and enjoyable driving), no-one investigated.
Do I think it happened this way? It's hard to say. Probably not. But, in one way, it's even more frightening than an evil conspiracy. It's easy to say "I wouldn't take part in a conspiracy by my employer". It's harder to say "I would never be pressed to write code with goals that could not be fulfilled, eventually find a hack that seemed to work, and maybe ignore investigating why it worked so well"...
Unless it, say, causes a higher energy usage or makes you slightly more prone to parish from an infection. The selection pressure for most of our evoluationary history might just be a tad different than it is today. It works the other way, too, of course. Other threads note the increased risk of getting depressed from all the "bad news you can't fix". A high intelligence might make it harder to just shrud that off, while you could more easily filter it out with lower intelligence. (Just like kids can hear some conversations and really don't take note of the full depth of what's being said.) This phenomenon might be worse today than it used to be.
What is this fusion "ore" you are talking about? Even if we restrict ourselves to deuterium or even tritium, the ocean reserves are plentiful even in the "multiple orders of magntiude" energy consumption case. Longterm, exponential growth will require space exploration and I am all for it in short-term, but let's keep to the facts.
This seems to come out of the peculiar microsoft feature of being able to be an administrator user but without administrator privilege most of the time except when needed, and a lot of work to make this escalation happen in an non-intrusive fashion or be faked depending on context. It's a really complicated beast that no other platform tries to do.
MS up to and including XP (excluding the DOS based family) basically had the same as everyone else, you either were an administrator or you weren't, with facilities to 'runas' an elevated user to handle as-needed. The problem being they had tons of software from the DOS based system failing to use the right section of the registry and filesystem, requiring people to go through pains to run as administrator to run a lot of applications. This meant that most XP users just logged in as administrator.
To mitigate it, they embarked upon crafting this fairly complex thing to make running as administrator user safer most of the time. It's funny because at the same time they started doing more and more to allow even poorly designed DOS-era software to run without administrator. They create union mounts to make an application think it can write to it's application directory even when it cannot (and do sillier things like make 'system32' a different directory depending on whether a 32 or 64 bit application is looking). I do the atypical usage of a non-administrator user full time with UAC prompts nagging me about passwords if needed, and nowadays it doesn't nag any more than sudo does in a modern linux desktop. If I understand this behavior correctly, this usage model might be immune to this risk factor.
While impersonation and other techniques is used a lot more and including larger portions of the API, impersonation itself has been along since NT 3.1. Are you a file server process serving a request from a client? Just create an impersonation context for the user who sent the request and pass that along to the file system. You only need to make sure that you create the right context and tell other services on whose behalf you are doing this. This is not identical to setuid and similar, most importantly because a single thread can keep many impersonation contexts.
That this is part of the application compatibility cache service is almost coincidental, the real problem is in the fact that impersonation services are used, but used incorrectly. Impersonation was part of the original NT design, and for relatively good reason.
you first need to copy that data into another block, erase the original one, write all data back and erase your "tmp" block. The churn on blocks happens a lot faster than what you'd think.
If that's the case, then why are they not copying the data to ram contained on the drive itself? Seems like an awful waste of cycles with a relatively simple fix. Is it just a cost issue?
Any wear levelling worth its salt will not do what the grandparent wrote. You simply do not change one page in a block. If you write a single page, that is handled by mapping that page to another (free) block and maintaining a mapping table for which LBAs are currently stored in what blocks. However, if you are doing single-sector writes, or in turn repeated I/O flushes of the same sector, you still see a lot of write amplification. To keep data integrity, the mapping tables also need to be kept updated in a correct way (or at least uniquely recoverable by scanning through all blocks after a hard power off).
But, well, the difference is that Oracle has actively asked everyone else to quote references to their book. Google has produced a product that only respects those references that Oracle has encouraged anyone to use. If Oracle starts pursuing anyone *writing* Java code for copyright infringement ("hey, you called all methods of ArrayList, in the order they are declared"), that's a different thing.
Has Google copied Javadocs? Those texts are not necessary for technical interoperability. Thus, it would be a very different thing. Public symbols should be just that, public.
Slashdot Mirror
I travel mostly from the US to somewhere in the EU. Not once have I ever entered the EU without having to collect my luggage and then go through border control. Countries included in this list: UK, Spain, Italy, Germany, Sweden, The Netherlands. Every one of those I had to. Now, once you enter the Schengen Treaty countries, yes, you don't have to, but that's because the EU has decided that there fundamentally aren't borders between Schengen Treaty countries. But seeing that the UK isn't one of the treaty countries, want to guess what you have to do with luggage when you go from the UK to mainland Europe or the other way around?
Incorrect, I've flown multiple times with British Airways between continental Europe and destinations in the US. I've never needed to touch my checked baggage at LHR, it's been checked all the way in both directions. I've also flown from continental Europe to Glasgow with an LHR transit. Checked all the way. But, hey, even if the UK is outside Schengen, the country is part of the customs union (for now...).
I was playing with "Ubuntu for Windows" on Windows 10 last week. While it is an interesting effort (and I was able to upgrade from the default Ubuntu 14.04 (Trusty Tahr) userland to the 16.04 (Xenial Xerus) userland with minimal dificulty), performance does not match that of a Lubuntu 16.04 VM on the same hardware running in VMWare Player. I was running repeated Monte Carlo-type simulations, and the same scripts and executables took twice as long to run under Ubuntu for Windows vs. the VM.
So, while interesting, it is still beta (and is labeled as such, and requires "developer mode" to be enabled in Windows 10), and it's not quite ready for prime time yet.
If you're getting that kind of performance difference, it sounds like you're really bound by I/O or (faulty?) thread synchronization. But, yeah, I would never use WSL for performance. For easy transparent prototyping, it's great and I've basically stopped using cygwin.
If the voice masking wasn't well done, couldn't you end up with an uncanny valley sort of situation with respect to how the applicants sounded? I can imagine a scenario in which the voice sounds "wrong" at a gut level, and that makes some interviewers uncomfortable.
And, overall, what do you think the tech community would be most open to? A person that sounds like a woman, but comes off as a bit of a tomboy (on account of actually being a man), or a man that seems oddly feminine or "weak", "fuzzy" or whatever attributes you would assign to socially acceptable female behavior? And how did men that had their voice masked into female fare, compared to non-masked men?
Take a MS Excel macro made on Windows, and run it in MS Excel on another Window machine...
Excel is horribly broken to the extent where macros stop working if you try to use them on a machine with a different language.
Not anymore than saying that a bash script breaks if you run it on a non-C locale. It MIGHT be true, if you actively rely on other stuff behaving in certain ways. And, if you're completely blind to the issues involved, it might very well happen. I've seen Java and C# code generate invalid SVG files etc by using decimal comma (taken from the current locale), rather than a decimal point. But, again, that doesn't mean that the software itself is broken. The author of Excel macros might, on the other hand, be far more likely than either of these groups to just cobble something together based on what seems to work.
Yeah, that's precisely what you would expect for a vulnerability in user space code. "Just" unzip a 7-zip file and suddenly any file in your home directory can be compromised... or gone. Run a vulnerability scanner on your e-mail server (with insufficient sandboxing), or on your web server for uploading files, and things get... worse.
"Those conflicting forces reduce skill applied in jobs filled by the mostly unqualified." Did you draw this conclusion by collection a lot a data and running the data through your own analysis? Or do you have some other way to prove such a broad accusation? The biggest problem we face to day is from those who use statistics to support their cause and opinions. We are constantly bombarded with poll results and nobody every questions how these results are derived. What statistical methods are being used that allows the pollsters to take a very small sample size and project those results on very large datasets? How do you ask 500 people their opinion on something and then apply those results against 400 million people?
By assuming random sampling, that's how. Whether that assumption is correct is a critical issue, but that is the case for any universe population significantly larger than your sample set. 500,000 or 400 million really does not matter - if you are ignorant of the demographics and how those interact with your sampling strategy, you're not gonna get a correct result.
If, on the other hand, you somehow manage to do random sampling of the true population, 400 people would be enough to nail preferences down to a few percent, (almost) no matter the total population size. And I guess this is the danger of statistics and big data. Intuition says one thing, simple statistical assumptions say another, and a more thorough treatment is rare.
There was a drive that had two actuators that could access the entire platter. That was the design, but I think in the end the complexity of multiple heads accessing the same sector was problematic because of the ordering of the operations (i.e., one head could write data to the sector that the other head was reading - if you didn't catch this, you would corrupt the data).
Plus, double the heads doubles the chance of a head crash.
It seems like NCQ, write and read caches (sometimes with flash hybrid modes) etc in current drives would bring enough complexity that additional physical heads would also be reasonable to implement. The abstraction in the drive firmware is much thicker these days.
If they are able to detect lock screen digits versus other things and only find 3 digits, that will result in less than 24 combinations, not more.
Has to get around stack overflow protection canaries (-fstack-protector-strong or -all), address space randomization, and a non-executable stack and heap. Ubuntu has run -fstack-protector-strong (covers functions calling alloca()) since gcc 4.9 release after 2015-05, according to #1317307. Kees Cook added the -strong feature to gcc, and is part of Ubuntu's compiler team, so it went straight into Ubuntu.
Good luck exploiting this bug.
Denial of service by crashing the process is of course not as nasty as remote code execution, but it can easily be nasty enough, especially if the properties of DNS would allow you to penetrate deep inside networks and services generally believed to be protected. My personal favorite vector here would be XML exposed to parsers that auto-load whatever DTD or other schema that is specified.
The bug can hit you with DNS over TCP as well. While that is somewhat of an oddity, I am not yet confident to say that you can rule it out, especially if you have a MITM that might be able to trigger fallbacks. Since the TCP response could be fragmented over several packets, things rapidly grow beyond iptables capabilities there. (But the "TCP DNS response fragmented over several packets" would thankfully not propagate through layers of caching internal DNS servers.)
If you use C/C++ right, you do not end up writing a JIT compiler for a language never intended for it. This is a bug in v8. Now, we don't know where, but that's the kind of code that does things no one sane should ever do. It is supposed to take shortcuts and patch things on the fly. It's of course fully possible that this exploit is not in a performance-critical path, and then your comment is rather well placed. But I do think that anyone writing C/C++ in this context is a fool himself. It is for all practical purposes impossible to use C without doing bare pointer addressing. It is highly possible to use C++ without doing it, even though such use is not terribly widespread.
It's not like putting a sliced tomato on the kitchen sink in a humid climate will prevent other parts of your kitchen from attracting any mold spores around. Bacteria and prokaryotes are mostly incapable of macrosopic movement (especially in air). They are also able to rapidly expand populations. Therefore, a "colonist" doesn't choose to move to the best spot, foregoing a worse one. They will try everywhere. If they gain a foothold, that foothold is likely to just unleash further colonists into the less hospitable, but still slightly viable, habitats.
Well, for making this "frame rate" theory relevant, the question is not only if anything happens at or close the frame rate, but what is the frame stepping function? And, throwing relativity into the mix, in what reference frame?
A discretized spacetime would mean that the continuous solutions to the Schrödinger/Dirac equations are actually approximations that are better expressed by some discrete time stepping scheme. That could have macroscopic consequences. Especially so if for some weird reason Nature has a rather simple first-order scheme at its frame rate core. But, it does also mean that we would get slightly different results from different objects in free fall, depending on their overall speed relative to the reference frame. This would control the factor between the "local passage of time", and the actual number of "Planck time frames" used by the process. In addition, the discretization of time almost necessitates a discretization of space. This not only means that space has some small grid (not likely either, based on current theory). It also means that there are some absolute directions in space and that some physical processes would behave slightly differently (even if aggregated along macroscopic distances) if they are algined to these directions, or not.
Well, electron states being quantized has helped us to (truly) understand chemistry and create transistors as well as LEDs. By realizing that things are only allowed to make certain transitions under certain conditions, you can "cheat" and build up high-energy states that are far more stable than they really should be. I am not saying we would get macroscopic anti-gravity or a "Faraday cage for gravity", but this is kind of the space where we would get more specific explanations for how you might be able to accompish those things in theory. For very delicate experiments (similar to the one described!) and possibly sub-nanoscale manufacturing procedures, an understanding of a quantized nature of gravity influences might be useful, if only for better understanding the noise in measurements and tolerances.
Even if mass would be quantized, the Newtonian equation is m1m2/r^2. Even with discrete mass quanta (which is also false, see other replies), you would get a continuous spectrum of resulting forces. Inserting relativity here changes the expressions, but it would really just muddle things. So, no, there is no specific reason to believe gravity to be quantized - outside of an actual theory of quantum gravity.
If it is just a bug, then we should expect a quick fix and firmware release from VW. If, however, it was a conspiracy, and there is no way that VW EGR technology can ever be made to pass the NOx requirements (without additional hardware - AdBlu tanks), then VW is screwed.
My point is that a "too good to be true" bug could easily have quite devastating consequences if it's just fixed. If they remove 'false' in the putative "if (isInTest() || (isNOxReductionNeeded() && false) enableEGR();" line and this increases fuel consumption or reduces maximum torque a lot, they cannot simply release that fix.
Embedded automotive control systems and scientific research are quite different domains, but in science I've repeatedly been close to thinking I had solved a problem, just to realize that my benchmark was off and the code was not really working at all. I have not published any of those results (AFAIK) yet, but I've reviewed and seen publications with blatant errors. When you have reached the kind of result you hoped for and believed likely, you are not on guard anymore. Fixing the blatant error might very well mean that the whole work is pointless. The error is trivial, the consequences are not.
The sensors required to detect "test mode" and software driven EGR control hardware are already part of any modern car so there was no decision to "add" them to accomplish this cheat. But there had to be a strategic decision to not to add SNCR, and that is a decision that could only be made at a very high level.
Yes, but that was not a conspiracy. It was very clear in the specs and even highlighted as an advantage. The question is "who knew and approved, at what point, that this design would not work out in practice". Even the idea that smart design of the control regime would make it possible to achieve low emissions without SNCR is not, in itself, equivalent to fraud. It's only when this design becomes all about "detecting test conditions" things get really, really bad.
The linked article makes the point that the sensors and hardware would not be necessary. I think the writer seriously underestimates to what extent a modern car with protection systems will try to juggle different constraints. Things like non-driving wheel rotation (defeated by being on a lab stand) are needed for breaking systems and possibly to some extent to moderate throttle control for stability. Wheel movement patterns are also needed and useful, even if you don't actually have electric power steering.
Regulating the exhaust gas recirculation somehow also makes sense. You might go totally on and off, but you would certainly want to keep it at a sensible level. You want good acceleration and full combustion of fuel while still not emitting to much nitrous oxides. It makes total sense to me that you might want to design your control system to try to judge not only the current emission levels, but also the overall driving pattern (steady straight ahead, repeated stop and go, etc) with some kind of state machine to try to find the best EGR regulation regime. This requires sensors and ways to regulate the feature.
My most innocent guess about how something such as this might have happened was an intent to find a good regime that would give nice bursty performance, while keeping nitrous oxides low overall. Progressively, the control regime was pushed until it ended up in the corner where the case of EGR being properly activated under real-world conditions basically does not happen. Some parts of it might even in the end be a bug between the intended state transitions and the actual ones. Like all bugs that give performance that seem too good to be true on the metrics you really care about (fuel consumption and enjoyable driving), no-one investigated.
Do I think it happened this way? It's hard to say. Probably not. But, in one way, it's even more frightening than an evil conspiracy. It's easy to say "I wouldn't take part in a conspiracy by my employer". It's harder to say "I would never be pressed to write code with goals that could not be fulfilled, eventually find a hack that seemed to work, and maybe ignore investigating why it worked so well"...
My attacker is very regular. He kicks my canary machine down every 49.7 days.
Unless it, say, causes a higher energy usage or makes you slightly more prone to parish from an infection. The selection pressure for most of our evoluationary history might just be a tad different than it is today. It works the other way, too, of course. Other threads note the increased risk of getting depressed from all the "bad news you can't fix". A high intelligence might make it harder to just shrud that off, while you could more easily filter it out with lower intelligence. (Just like kids can hear some conversations and really don't take note of the full depth of what's being said.) This phenomenon might be worse today than it used to be.
What is this fusion "ore" you are talking about? Even if we restrict ourselves to deuterium or even tritium, the ocean reserves are plentiful even in the "multiple orders of magntiude" energy consumption case. Longterm, exponential growth will require space exploration and I am all for it in short-term, but let's keep to the facts.
So, did the inhabitants evolve into somewhat benevolent beings of pure energy, or just underground-dwelling mega-brains that like to keep pets?
This seems to come out of the peculiar microsoft feature of being able to be an administrator user but without administrator privilege most of the time except when needed, and a lot of work to make this escalation happen in an non-intrusive fashion or be faked depending on context. It's a really complicated beast that no other platform tries to do.
MS up to and including XP (excluding the DOS based family) basically had the same as everyone else, you either were an administrator or you weren't, with facilities to 'runas' an elevated user to handle as-needed. The problem being they had tons of software from the DOS based system failing to use the right section of the registry and filesystem, requiring people to go through pains to run as administrator to run a lot of applications. This meant that most XP users just logged in as administrator.
To mitigate it, they embarked upon crafting this fairly complex thing to make running as administrator user safer most of the time. It's funny because at the same time they started doing more and more to allow even poorly designed DOS-era software to run without administrator. They create union mounts to make an application think it can write to it's application directory even when it cannot (and do sillier things like make 'system32' a different directory depending on whether a 32 or 64 bit application is looking). I do the atypical usage of a non-administrator user full time with UAC prompts nagging me about passwords if needed, and nowadays it doesn't nag any more than sudo does in a modern linux desktop. If I understand this behavior correctly, this usage model might be immune to this risk factor.
While impersonation and other techniques is used a lot more and including larger portions of the API, impersonation itself has been along since NT 3.1. Are you a file server process serving a request from a client? Just create an impersonation context for the user who sent the request and pass that along to the file system. You only need to make sure that you create the right context and tell other services on whose behalf you are doing this. This is not identical to setuid and similar, most importantly because a single thread can keep many impersonation contexts.
That this is part of the application compatibility cache service is almost coincidental, the real problem is in the fact that impersonation services are used, but used incorrectly. Impersonation was part of the original NT design, and for relatively good reason.
you first need to copy that data into another block, erase the original one, write all data back and erase your "tmp" block. The churn on blocks happens a lot faster than what you'd think.
If that's the case, then why are they not copying the data to ram contained on the drive itself? Seems like an awful waste of cycles with a relatively simple fix. Is it just a cost issue?
Any wear levelling worth its salt will not do what the grandparent wrote. You simply do not change one page in a block. If you write a single page, that is handled by mapping that page to another (free) block and maintaining a mapping table for which LBAs are currently stored in what blocks. However, if you are doing single-sector writes, or in turn repeated I/O flushes of the same sector, you still see a lot of write amplification. To keep data integrity, the mapping tables also need to be kept updated in a correct way (or at least uniquely recoverable by scanning through all blocks after a hard power off).
But, well, the difference is that Oracle has actively asked everyone else to quote references to their book. Google has produced a product that only respects those references that Oracle has encouraged anyone to use. If Oracle starts pursuing anyone *writing* Java code for copyright infringement ("hey, you called all methods of ArrayList, in the order they are declared"), that's a different thing.
Has Google copied Javadocs? Those texts are not necessary for technical interoperability. Thus, it would be a very different thing. Public symbols should be just that, public.