If you're in the same building as everyone else, sure. However, the company in question outsources, even as far as having everyone work from home. So there's a much smaller chance of building the camaraderie needed to build such advancement options.
This is the fallacy of the broken window, and not the entire story. After the mistake in Bangladesh, the activists learned from their mistakes, and the next country got rid of sweatshops, plus provided education and stipends for the children so that they didn't have to go into those poor situations.
This isn't about forcing those jobs to go away. This is about keeping companies from exploiting these workers. The workers that People Delight are exploiting don't get the benefits tech firms bandy about so freely, can't unionize, don't get the opportunities to advance. There is money to be made there without exploiting, but things don't get better unless you criticize the people doing the exploiting.
Support staff must be hard to find if you have to look beyond the valley. The same argument could be made about having a team of outsourced coders; you can find much cheaper coders if you hire outside of the country, non?
No, what you're doing is further stratifying this country. You don't offer any opportunities to advance. You don't offer the benefits you offer your programmers. You take advantage of income disparity. You take advantage of people who are in smaller towns. If you really wanted to take that well-being and spread it, you'd offer stock options, you'd offer them decent insurance, you'd offer them a future.
If they're so valuable, why are companies like yours trying to keep the customer support people from getting the benefits that the rest of the people working for the company getting? Those people need to eat too, those people are taking risks too, those people have families, have dreams. Your service just furthers the problem of why so many non-technical people struggle in this area.
In other words, part of the problem. The coders get all the perks, the free sodas, stock options, the high salaries, etc. The front line employees get a commute from Stockton and an opportunity for an extra dollar an hour wage next year, unless there's a wage freeze.
In the rest of the world, though, unlocked phones are super common. Also, with sim cards, if my phone dies while I'm out on vacation, I can swap it into my backup phone with a minimum of effort. Software actually makes that harder because all the security benefits of a physical device go out the window. In order to be secure, I'd need to make a secure password, one which I'll probably forget five minutes later. At which point, I'd need to store it on some password aggregator. Thus, when I'd actually need the username and password, I'd not have access to the one device needed to access that information.
Usernames and passwords suck. A lot. We should be striving to get rid of them, not make more places need them.
Client TLS certificates have been a thing since forever, but browser makers keep it a pain in the ass, and too many "modern" software stacks don't even consider leveraging the decades of infrastructure that would make their job easier. Add to the fact that identity aggregators want to be producers, but rarely allow themselves to be consumers and we get stuck in the hell that is identity online.
I'd very much argue that a hardware token is more secure, and less complex, especially with multiple devices. It's a lot easier to remember where you put your smart card than to need to get a password store somewhere shareable, to secure that, to remember to put passwords in the store, etc.
This is called Data Scrambling on Intel processors. There's not a lot of info I can find from the horse's mouth, but the datasheet [1] has a blurb:
The memory controller incorporates a DDR3 Data Scrambling
feature to minimize the impact of excessive di/dt on
the platform DDR3 VRs due to successive 1s and 0s on
the data bus. Past experience has demonstrated that
traffic on the data bus is not random and can have
energy concentrated at specific spectral harmonics
creating high di/dt that is generally limited by data
patterns that excite resonance between the package
inductance and on-die capacitances. As a result, the
memory controller uses a data scrambling feature to
create pseudo-random patterns on the DDR3 data bus to
reduce the impact of any excessive di/dt.
So basically, all the kernel knows is that the data is in there "somewhere", and can be accessed traditionally.
8 and 9 specify manufacturers -- people selling something that connects to the internet. If you're selling, you should have to certify that you've done due diligence. If this is done through NIST standards being created, one of the side effects of this would mean that everyone would get actual guidelines, and almost certainly tools, which could do checking if a device is configured at least semi-properly. If anything, it would mean that vendors would have more impetus to communicate and send patches, because they would have to actually own their problems.
With modern processors, that becomes a much more difficult proposition. For various reasons, processors now scramble addresses before writing to dram. This makes it more difficult to figure out which cells are neighboring, and much more difficult to implement that type of countermeasure.
This feels much like laws that already exist around Attractive/Public Nuisances. A compromised device DDOSing is interfering with others' right to be able to access the internet. The users themselves would in turn have much more impetus to seek remedies, legal or otherwise, to get the devices fixed because they'd then be without the ability to use devices they paid for. In a lot of ways, doing this would put more pressure on the manufacturer, because they would have much less room to wriggle out of their responsibility to ensure their device is actually usable.
Hyper-V has dynamic memory, so memory resources can be reallocated as needed, and has driver hooks so that linux vms can be resized too. There's also Intel's clear containers push which virtualizes for linux but shares a lot of kernel structures between the host and the VM.
In activation, if you're dealing with more than a couple servers, you've almost certainly got volume licensing and a multiple activation key, which means that your install scripts will automatically update for you. Likewise, installing features like ssh and packaging can be automated as well. A lot of the things that people criticize windows for haven't been true for a long time, especially in the enterprise/service area -- there are a lot of tools out there for making things just as easy, if not easier, than *nix.
The collection of supported machines does seem to concentrate mostly on the older systems. The newer ones seem to be examples of the interesting quirks that were in place in the later days -- ATI's WinBIOS for example, or Compaq's machines which used a stripped down copy of Windows 3.1 as the bios utility. Gut feeling for the newer systems is mostly to couple with the newer video cards on the list -- the S3 Trio64 and the 3dfx VooDoo.
Graphics emulation is one of the huge ones. Various graphics chips would give widely different results, sometimes comparably better or worse, sometimes just different. Sound emulation, again, in the old days, sound cards had widely different feature sets, which would result in different sound quality. Then you had the issue of different chipsets which had their own sets of quirks. Compatibility was something that took a good deal of time.
As an experiment, I set up the four outputs of my computer to play a different audio stream simultaneously. Each one took about 1% cpu usage. Next I played 5 videos simultaneously, streamed from a hard disk drive. I only used two monitors there, but that was about 4% CPU usage per video. My computer is admittedly kinda beefy, but I have no doubts that a slower computer wouldn't have trouble with the task.
The landing techniques that are being used are bringing much larger payloads to the Martian surface than were brought in previous landings. Curiosity, for example, is about twice the weight of the Viking landers. In general, we're much more successful at landing and receiving data from mars-bound craft than we were back there; the soviets sent several probes to mars and got minimal data back from them before they failed.
Fast/accurate computing is needed for surface work on Mars because it means that the devices don't have to wait around for commands all the time. Giving more processor power and ability means that more flexible programs can be written to sift through the data and just send back the most interesting parts. Fast and accurate are very much needed for the kinds of lab experiments we're doing on mars.
I would not call TypeScript/Babel making it a non-argument, because those two are separate languages that are compiled to Javascript. The language itself still has those limitations, you're just hiding it under the rug.
Regarding performance, your solution means that in order to understand your site, you need to understand another language and javascript now. At which point, why swap between languages and mindsets when the other language can already do everything javascript does, plus gives you a performance edge?
With the knowledge pool, it really does depend on the sort of application you're making, and how much code is reused and where. If your application has a web-based, and desktop/mobile app, you may very well be better off coding the entire thing in a language more amenable to native compilation.
Knowledge-wise, and long-term developer comfort-wise, Javascript's fast churn is problematic. When big packages' idea of long-term support is three years or less, you're going to be spending a lot of engineering time rewriting your code just to keep things from collapsing into a bug-ridden insecure heap. Examples like Angular.JS show just how brittle the javascript environment is, and how difficult it's going to be to keep a site maintained.
Gut instinct wants to say that it's a bit of an uncanny valley experience as well. Our brains are wired to recognize patterns, and seeing something very organic, but also very mechanical just sets off those deep instinctual alarms that something's not quite right.
The entire details of the exploit are apparently in a 37 page writeup which is yet unreleased. So it's safe to assume that it is requisite on a very specific chain of events that are more likely to happen in an OS like ChromeOS where there are a lot fewer simultaneous actions. Additionally, ChromeOS' multiprocess model means that you don't have to worry nearly as much about those other actions, because the allocators are probably going to be running according to your assumptions.
In a previous job, we'd receive weekly updates of data from a vendor that would need to be imported into the database. There were a few occasions where the update file had errors which would break the application where this data was used. Features like this mean that one can very quickly roll back to previous known good data, and also troubleshoot a problem by comparing results to what they were last week/month/etc.