Physicists often have no idea how malware actually works. Arthur C. Clarke's 3001 had a plot line that involved throwing a logic bomb at the monolith to break it and described a vault on the moon where samples of the most dangerous malware were contained for future study. It made no sense. All malware is similar to biological viruses in one respect: it is highly specific to the host organism and the host organism adapts via intelligent design, not evolution. Some of the most successful malware spreads with the aid of human interaction, because it's much harder to patch the users than the system.
The problem for an alien trying to write malware is that they would also need examples of our technology to study to find the vulnerabilities. Imagine trying to write macOS malware if you have only a Windows machine (and not even a Mac VM). You might be able to guess some similarities from the way that system calls work on x86, but it would be really hard and you'd probably need a lot of tries before you got something that even vaguely worked (and with no feedback until you got one that worked then you'd be sending out a load of code before you got anything working). This example is a bit easier, because you might try targeting something like WebAssembly or JavaScript to explore the target system. Aliens wouldn't have this option. If they needed human intervention, then they'd need to understand human psychology, which is about as difficult to learn remotely as human technology.
There's also the problem of latency. If they're sending out signals that we can detect with existing telescopes, then they're limited by the speed of light. If they're trying to do this from home, then at best they're looking at 8-10 year round trip times. One or two attempts gets you from DOS to Windows 7. Trying to develop malware with that kind of moving target is insanely difficult. Alternatively, if they're close enough that the latency isn't an issue then we probably don't have to worry about information attacks: if they are able to sit above our planet and control enough energy to reach here from another star, then 'do what we say or we will drop large rocks on you until you're all dead' would work fine as a threat. Sure, it lacks subtlety, but then it's far less likely to be mistranslated...
Nextcloud is a horrible mess of PHP with a fairly obnoxious license (AGPLv3), but it's currently the best option. They have desktop and mobile clients that work just like DropBox (e.g. auto-upload of photos, automatic syncing) and a bunch of plugins for other useful things (RSS aggregation, notes) and include CalDAV and CardDAV servers so that you can easily share calendars with your family.
The difficulty is that you can fire someone for no reason, but they may be able to sue for wrongful dismissal if there is an underlying reason that you don't tell them.
I had a quick look at Mycroft and it looks as if it needs to phone home to some third-party server. If I were to build such a thing, the primary requirement would be no network connection from the process that did speech recognition - it should trigger other actions in other processes that might connect to the network, but no process should be both network connected and able to access my microphone.
CMU Sphinx makes it easy to write something that listens for phrases and performs actions based on them.
RAM is byte addressable. Or, practically, cache-line addressable. You read and write to DRAM in chunks of 64 bytes on most modern processors. Flash is byte-writeable but only cell-erasable. If you want to erase and overwrite, you have to do so in chunks of the cell size, which is typically a multiple of the exposed block size (4KB on modern machines). It would be possible to design a cache controller that always flushed 8KB chunks back to main memory, but then it would be really slow. That said, you could more easily design a fourth-level cache that worked at a page granularity and used DRAM so you'd flush from DRAM to SSD in some multiple of page granularity. That's more or less what HP's The Machine is doing.
Your co-worker was probably not thinking very clearly. Back then, floppy disks were 360KB and so 10MB was under 30 floppy disks worth of capacity. A few years later, floppy disks were up to 1.44KB and stayed there, while hard disks grew to 500MB or more. At that size, it looks hard to fill. Then CDs came out and could store the equivalent of 450 floppy disks and that seemed a huge amount. A 2GB hard disk could store 3 CDs and still have space!
I bought my first flash SSD in 1994 (I think, maybe 1995). It was for my Psion Series 3, had a capacity of 128KB, and cost £30. It was a single cell, so you could write to it but not erase without erasing the entire disk, so you needed to do a backup and restore to replace all of the data. At about that time, a 1GB hard disk cost around £100-150 (I don't remember exactly what, but I remember being amazed when the price dropped to under 10p/MB a little bit later). Let's say £120, for the sake of argument. That meant that the cost of a hard disk, per GB, was about 8,000 times less than the cost of flash.
It's been a couple of years since I last bought any disks (my last two laptops have had SSDs, but the newer one is now over four years old and has a 1TB SSD). It looks as if 500GB SSDs now cost about £120, which is about the same price as a 5TB hard disk. That's a difference of about a factor of 10 in price - a big jump from a factor of 8,000. I'd expect that gap to close pretty soon.
Perhaps more important is the bottom end. You can get a 120GB SSD for about £30, or a 500GB hard disk for the same price. Note that now we're down to a factor of four difference in price. For a lot of users (e.g. corporate desktops where important files are stored on a server), the difference in utility between 120GB and 500GB capacity isn't that great, but the difference in performance between SSD and hard disk is a lot more noticeable, so it makes sense to go with the SSD.
This is the real problem for hard disk: if enterprise, mobile, and low-end desktops move to SSDs, where do you get the volume to pay for R&D on the next generation?
I'm going to skip answering most of the replies, since they seem to be people insisting on missing the point, but around Storm/Ororo Munroe, think of it as the difference between Storm being a supporting character in the X-Men movies (really) and an Origins movie for Storm, depicting her past growing up in Africa, and finding an identity.
I think this misses bigger problem: the writing for Storm was really bad. She was a completely two-dimensional character, with no development, no story arc. She was just there. I don't mind that being black wasn't portrayed as an important part of her identity, I mind that there were literally no memorable aspects to her identity. The role of the black female X-Man was to stand near the white X-Men and agree with them. She wasn't portrayed as a person with independent agency who was adding a lot to the team, she was portrayed as a cardboard cutout with superpowers.
Contrast this with Blade. He had back story, which led to his complex motivations. He was on a team with an old white dude, but he was the one that set the agenda for what they'd be doing and who led most of the action. The other characters in the film were defined by their relationship to him. Most importantly, he wasn't a character whose identity was defined by his colour (except in the sense that it made him more able to go out in sunlight than the pasty white evil vampires). He was a character who had interesting development and kicked ass, who happened to be black. You could have taken the Blade story line and, with minor tweaks, made him pretty much any ethnicity and it would still have worked (though given that you'd also be ruling out Samuel L. Jackson as well, you'd find it difficult to cast an actor who would pull off the character as well).
If you read science fiction from the '60s, a lot of writers have the same problem with female characters: they can't figure out how to give them personalities, so they make them gender stereotypes plus some special ability. Hollywood still has this problem: they can't write a character for whom gender or race is a contributor to their personality, they either write cardboard cutouts or generic stereotypes plus some superpower.
I expect one to write code but be to dumb to know that he has to save it as HTML to run it in a browser or to develop it in a browser. Sorry, what kind of strange mind does one need to have, to wake up in the morning and think: "I like to learn programming!" and 5 minutes later powers up a web browser?
I expect them to think that because that's what kids think in response to most things related to computers now: and once they've asked their favourite search engine, they'll get a load of links to sites that let you write code within a browser directly. If they don't and they ask a person (did you know that the prompt at the Apple II was something you could program in the first time you saw it, or did you need a person or book to explain it?) then that person can provide them with a template that they can write code in.
Which part of: you switch on an Apple ][ and you end up in a REPL interpreter did you not get?
As I've said elsewhere in this thread, a BASIC REPL is a great way of learning to write 5- to 10-line programs, but the lack of a debugger (or a visual editor) made it painful to write more complex programs. These are both available on any modern system, as a result of having a web browser.
Agreed on Spawn, but I don't see Blade as an antihero. In addition, the X-Men films have all featured Storm as one of the main characters (black and female), though perhaps they don't count because she was part of a team (and, I think, the one with the fewest lines and no character development).
There were two hypotheses regarding this that I remember. The first was that pirated copies make it easier for people to determine that the film is actually crap and so not worth paying money to see: if you know someone who has pirated it and they tell you to avoid it, you might. The second was that a load of people much prefer watching films at home, but will go to the cinema for a hyped thing if that's the only way of seeing it. I don't have much sympathy with either: depending on limited knowledge to sell a crappy product and imposing artificial scarcity on a particular distribution chain are not things that should be encouraged.
Last time I did ARM they could be driven in either little-endian or big-endian mode based on flags in the AIRCR register.
That's there for a specific customer who wants to keep networking code originally written for big-endian MIPS and never ported to a little-endian machine in existence and other people are strongly discouraged from using it. As I recall, you can disable SETEND in EL0 (so you trap and can detect that the user has done it and switch back on interrupt if they have). This isn't an issue for emulated x86 code, because it will be running in little-endian mode on a machine that is intended to run in little-endian mode. I thought that AArch64 had removed SETEND, but I could be mistaken.
So Microsoft isn't going to stop you from changing endianess on the fly. No doubt in coming months we'll be seeing WebASM and Javascript attacks crashing Windows 10 ARM devices because of this.
You'd have to persuade the JIT to generate a SETEND instruction, which sounds difficult.
Huh? The Windows NT kernel was originally brought up on the Intel i860 (RISC processor) and then ported to x86, to make sure that it was portable and didn't include any x86isms outside of the HAL. They've been maintaining ports to other architectures internally since then to ensure that it keeps this property.
If you read Tanenbaum's Modern Operating Systems, you'll see a good comparison of the NT kernel to a couple of UNIX systems and it comes off pretty well in the comparison.
And Intel's claim is that if executing an instruction uses a patented process it doesn't matter if you execute it in hardware or translate the instruction and execute that - you still need a patent license or you will be sued.
There is some awful case law from a MIPS lawsuit that lends some weight to this. MIPS patented a pair of instructions to do unaligned loads and stores more efficiently than doing a shift-and-mask. A competitor created a MIPS-compatible CPU that trapped on these instructions and emulated them in software. MIPS claimed that this violated their patent and, in a shocking lack of judgement, the court agreed with them.
Nope. Microsoft bought Connectix for their VirtualPC for Windows product, which became Microsoft VirtualPC and then was merged into their other virtualisation platforms, but Connectix was better known for VirtualPC for Mac (which had one release after Microsoft bought them and was then killed, largely because IBM's PowerPC 970 didn't include the instructions that made byte swapping cheap): an x86 emulator that ran on PowerPC. It was pretty good for the time and ran a useable GUI on a 1.25GHz PowerPC. It did a bunch of work to detect uses of condition codes and skip generating them if they're not used, which is one of the pain points when emulating x86.
It depends a bit on what those patents cover. You can't patent the idea of a 128-bit vector, so it must be on details of specific instructions. ARM has had a 128-bit vector unit for quite a long time and a lot of SSE instructions map trivially to NEON equivalents. If those instructions are the ones that are covered by the patents, then ARM will already have a cross-licensing agreement in place to cover them.
It will expect everything it sees to have the x86 structure alignment
The structure alignment rules for anything that's not a packed structure are likely to be the same for both. You may have some issues with stack frame layouts, but that's a separate issue.
x86 and x64 code handles misaligned pointers transparently, though occasionally at a enormous performance hit if they span a page boundary. ARM code does not
That isn't true for any ARM core released in the last 10 years, possibly the last 15 years.
However NT kernels are architected so that you can't have page faults when you're running a raised IRQL, because if you're doing that you hold a spinlock
That's far more important: you don't want to be trapping out to an emulator in an interrupt context. You also probably don't want to stick the emulator in the kernel in the first place, because that's a nice big attack surface for malware to play with.
x86-64 would be a nice to have but the idea is to get developers releasing arm64 binaries, not rely on emulation indefinitely.
I suspect that they're hoping, given the slow adoption of Win64, that anything that's been released as a Win64 app is under active development and so easy to get working on ARM. The emulator is intended for legacy things where no one has the source code (or, at least, the people that do have no incentive to support an ARM build).
Loading x86 code into a process that's running native ARM code just isn't going to work
I would be shocked if they weren't doing this, because that's how modern high-performance application emulators work: you compile all of the system libraries as native code and insert shims for communicating between them. ARM and x86 are both little endian, so that difficulty goes away. I'd be surprised if struct layouts were different between Windows/ARM and Windows/x86. Calling conventions need translating when you go to and from emulation, but that's trivial.
That said, I expect that most of the things like the shell are AArch64 binaries, which makes this kind of thing a lot harder.
I'm not sure about software, but a Harvard study a few years ago found a strong correlation between music purchase and music piracy: i.e. the people that pirated the most music also bought the most music.
There have been a bunch of studies that show that piracy doesn't harm sales (though the most recent one by the EU found that cinema sales in the first week of a summer blockbuster release were the exception). There are a few that indicate that piracy actually increases sales (you lose some sales from freeloaders, but more people that wouldn't have bought anyway pirate and advertise the product for free, which increases overall sales). People pirate for a variety of reasons. The top ones are:
They don't want to pay because they don't think the product is worth the money (won't pay for it if they can't pirate, not a lost sale).
They want to pay for it, but can't afford it (no lost sale, but if they pirate your stuff now then they are likely to buy your stuff in the future if they end up with more disposable income. Especially true for children.)
It's not available in a format / region that is useful to them (won't buy unless you change your sales practices, but are likely to stop if you offer the same thing without DRM, or in their country, or both).
They're freeloaders and will take it for free if they can get it but will grudgingly pay if they have to.
Anti-piracy measures work to turn the last category into sales, but don't help your bottom line for any of the other things. These people are the only ones where piracy hurts sales, but they're a minority (at least according to the academic studies that I've read). The big problem for most companies in these markets is that they regard reducing piracy as a goal, when their aim should be to increase sales. Would you rather sell 1,000 copies and have no pirates, or sell a million copies and have ten million pirated versions in circulation? The music industry finally learned this, and saw a big increase in sales once they allowed Apple and Amazon to sell DRM-free downloads.
You expect someone to be able to write code, but not able to save a text file with a.html extension and double click on it? One of these things is much harder than the other.
The problem is a bit more subtle that that: promotion is usually easier by moving companies than internally. That means that a lot of those junior developers that you train will likely go elsewhere, so you don't benefit from their experience. It gets worse when you apply a little bit of game theory: junior developers take some productivity from senior ones, so a company that employs only senior developers will be more productive overall. This means that the best strategy is to rely on your competitors training people and then hire them once they're experienced. This works well when a minority of companies are doing it, but doesn't when it becomes a majority. It's also difficult to fix, because any company that adjusts its balance of employees towards having more junior devs is going to be at a competitive disadvantage, even if they manage to retain all of the developers that they train.
Fizzbuzz isn't a selection test, it's a deselection test. You don't ask a candidate to implement Fizzbuzz to show you that they're competent, you ask it to show that they're not incompetent. It filters out the people who wrote '10 years C++ development' on their CV but don't actually understand for loops and if statements. Anyone with more than a couple of weeks worth of programming experience should be able to do it.
The problem for people hiring is that a lot of people that make it to interview can't - and if you can't implement Fizzbuzz then you're not going to be able to write any nontrivial software.
How will you ever understand why some things are more efficient than others, why division is so fucking slow, why floating point is useless, etc. if you were never taught about the underlying hardware?
I've read a lot of bad code written by people who didn't understand these things, but I've read a lot more bad code by people who focussed obsessively on these aspects and ignored the fact that they'd microoptimised the hell out of an O(n^2) algorithm when a naive implementation of an O(n log(n)) would have been far faster on their data.
In my experience, it's better to get people to design good algorithms first. It's easier to then teach them about low-level data representations, cache hierarchies, communication latencies, and so on than it is to persuade someone who has learned a bunch of microoptimisation techniques to step back and improve their algorithms.
One of my colleagues likes to tell a story about an intern who decided that the Perl code that they were using was too slow and rewrote it in C, only to find that it was an order of magnitude slower. The compute was faster, but the standard Perl libraries do very good I/O buffering and prefetching and even with that it was already I/O limited. Making the compute step faster didn't speed anything up, because compute wasn't the bottleneck. The C version could process a single record in about a tenth the time that the Perl version could, but was still slower overall because the intern had focussed on optimising the compute step and not the I/O.
Slashdot Mirror
Physicists often have no idea how malware actually works. Arthur C. Clarke's 3001 had a plot line that involved throwing a logic bomb at the monolith to break it and described a vault on the moon where samples of the most dangerous malware were contained for future study. It made no sense. All malware is similar to biological viruses in one respect: it is highly specific to the host organism and the host organism adapts via intelligent design, not evolution. Some of the most successful malware spreads with the aid of human interaction, because it's much harder to patch the users than the system.
The problem for an alien trying to write malware is that they would also need examples of our technology to study to find the vulnerabilities. Imagine trying to write macOS malware if you have only a Windows machine (and not even a Mac VM). You might be able to guess some similarities from the way that system calls work on x86, but it would be really hard and you'd probably need a lot of tries before you got something that even vaguely worked (and with no feedback until you got one that worked then you'd be sending out a load of code before you got anything working). This example is a bit easier, because you might try targeting something like WebAssembly or JavaScript to explore the target system. Aliens wouldn't have this option. If they needed human intervention, then they'd need to understand human psychology, which is about as difficult to learn remotely as human technology.
There's also the problem of latency. If they're sending out signals that we can detect with existing telescopes, then they're limited by the speed of light. If they're trying to do this from home, then at best they're looking at 8-10 year round trip times. One or two attempts gets you from DOS to Windows 7. Trying to develop malware with that kind of moving target is insanely difficult. Alternatively, if they're close enough that the latency isn't an issue then we probably don't have to worry about information attacks: if they are able to sit above our planet and control enough energy to reach here from another star, then 'do what we say or we will drop large rocks on you until you're all dead' would work fine as a threat. Sure, it lacks subtlety, but then it's far less likely to be mistranslated...
Nextcloud is a horrible mess of PHP with a fairly obnoxious license (AGPLv3), but it's currently the best option. They have desktop and mobile clients that work just like DropBox (e.g. auto-upload of photos, automatic syncing) and a bunch of plugins for other useful things (RSS aggregation, notes) and include CalDAV and CardDAV servers so that you can easily share calendars with your family.
The difficulty is that you can fire someone for no reason, but they may be able to sue for wrongful dismissal if there is an underlying reason that you don't tell them.
I had a quick look at Mycroft and it looks as if it needs to phone home to some third-party server. If I were to build such a thing, the primary requirement would be no network connection from the process that did speech recognition - it should trigger other actions in other processes that might connect to the network, but no process should be both network connected and able to access my microphone.
CMU Sphinx makes it easy to write something that listens for phrases and performs actions based on them.
RAM is byte addressable. Or, practically, cache-line addressable. You read and write to DRAM in chunks of 64 bytes on most modern processors. Flash is byte-writeable but only cell-erasable. If you want to erase and overwrite, you have to do so in chunks of the cell size, which is typically a multiple of the exposed block size (4KB on modern machines). It would be possible to design a cache controller that always flushed 8KB chunks back to main memory, but then it would be really slow. That said, you could more easily design a fourth-level cache that worked at a page granularity and used DRAM so you'd flush from DRAM to SSD in some multiple of page granularity. That's more or less what HP's The Machine is doing.
Your co-worker was probably not thinking very clearly. Back then, floppy disks were 360KB and so 10MB was under 30 floppy disks worth of capacity. A few years later, floppy disks were up to 1.44KB and stayed there, while hard disks grew to 500MB or more. At that size, it looks hard to fill. Then CDs came out and could store the equivalent of 450 floppy disks and that seemed a huge amount. A 2GB hard disk could store 3 CDs and still have space!
I bought my first flash SSD in 1994 (I think, maybe 1995). It was for my Psion Series 3, had a capacity of 128KB, and cost £30. It was a single cell, so you could write to it but not erase without erasing the entire disk, so you needed to do a backup and restore to replace all of the data. At about that time, a 1GB hard disk cost around £100-150 (I don't remember exactly what, but I remember being amazed when the price dropped to under 10p/MB a little bit later). Let's say £120, for the sake of argument. That meant that the cost of a hard disk, per GB, was about 8,000 times less than the cost of flash.
It's been a couple of years since I last bought any disks (my last two laptops have had SSDs, but the newer one is now over four years old and has a 1TB SSD). It looks as if 500GB SSDs now cost about £120, which is about the same price as a 5TB hard disk. That's a difference of about a factor of 10 in price - a big jump from a factor of 8,000. I'd expect that gap to close pretty soon.
Perhaps more important is the bottom end. You can get a 120GB SSD for about £30, or a 500GB hard disk for the same price. Note that now we're down to a factor of four difference in price. For a lot of users (e.g. corporate desktops where important files are stored on a server), the difference in utility between 120GB and 500GB capacity isn't that great, but the difference in performance between SSD and hard disk is a lot more noticeable, so it makes sense to go with the SSD.
This is the real problem for hard disk: if enterprise, mobile, and low-end desktops move to SSDs, where do you get the volume to pay for R&D on the next generation?
I'm going to skip answering most of the replies, since they seem to be people insisting on missing the point, but around Storm/Ororo Munroe, think of it as the difference between Storm being a supporting character in the X-Men movies (really) and an Origins movie for Storm, depicting her past growing up in Africa, and finding an identity.
I think this misses bigger problem: the writing for Storm was really bad. She was a completely two-dimensional character, with no development, no story arc. She was just there. I don't mind that being black wasn't portrayed as an important part of her identity, I mind that there were literally no memorable aspects to her identity. The role of the black female X-Man was to stand near the white X-Men and agree with them. She wasn't portrayed as a person with independent agency who was adding a lot to the team, she was portrayed as a cardboard cutout with superpowers.
Contrast this with Blade. He had back story, which led to his complex motivations. He was on a team with an old white dude, but he was the one that set the agenda for what they'd be doing and who led most of the action. The other characters in the film were defined by their relationship to him. Most importantly, he wasn't a character whose identity was defined by his colour (except in the sense that it made him more able to go out in sunlight than the pasty white evil vampires). He was a character who had interesting development and kicked ass, who happened to be black. You could have taken the Blade story line and, with minor tweaks, made him pretty much any ethnicity and it would still have worked (though given that you'd also be ruling out Samuel L. Jackson as well, you'd find it difficult to cast an actor who would pull off the character as well).
If you read science fiction from the '60s, a lot of writers have the same problem with female characters: they can't figure out how to give them personalities, so they make them gender stereotypes plus some special ability. Hollywood still has this problem: they can't write a character for whom gender or race is a contributor to their personality, they either write cardboard cutouts or generic stereotypes plus some superpower.
I expect one to write code but be to dumb to know that he has to save it as HTML to run it in a browser or to develop it in a browser. Sorry, what kind of strange mind does one need to have, to wake up in the morning and think: "I like to learn programming!" and 5 minutes later powers up a web browser?
I expect them to think that because that's what kids think in response to most things related to computers now: and once they've asked their favourite search engine, they'll get a load of links to sites that let you write code within a browser directly. If they don't and they ask a person (did you know that the prompt at the Apple II was something you could program in the first time you saw it, or did you need a person or book to explain it?) then that person can provide them with a template that they can write code in.
Which part of: you switch on an Apple ][ and you end up in a REPL interpreter did you not get?
As I've said elsewhere in this thread, a BASIC REPL is a great way of learning to write 5- to 10-line programs, but the lack of a debugger (or a visual editor) made it painful to write more complex programs. These are both available on any modern system, as a result of having a web browser.
Agreed on Spawn, but I don't see Blade as an antihero. In addition, the X-Men films have all featured Storm as one of the main characters (black and female), though perhaps they don't count because she was part of a team (and, I think, the one with the fewest lines and no character development).
There were two hypotheses regarding this that I remember. The first was that pirated copies make it easier for people to determine that the film is actually crap and so not worth paying money to see: if you know someone who has pirated it and they tell you to avoid it, you might. The second was that a load of people much prefer watching films at home, but will go to the cinema for a hyped thing if that's the only way of seeing it. I don't have much sympathy with either: depending on limited knowledge to sell a crappy product and imposing artificial scarcity on a particular distribution chain are not things that should be encouraged.
Last time I did ARM they could be driven in either little-endian or big-endian mode based on flags in the AIRCR register.
That's there for a specific customer who wants to keep networking code originally written for big-endian MIPS and never ported to a little-endian machine in existence and other people are strongly discouraged from using it. As I recall, you can disable SETEND in EL0 (so you trap and can detect that the user has done it and switch back on interrupt if they have). This isn't an issue for emulated x86 code, because it will be running in little-endian mode on a machine that is intended to run in little-endian mode. I thought that AArch64 had removed SETEND, but I could be mistaken.
So Microsoft isn't going to stop you from changing endianess on the fly. No doubt in coming months we'll be seeing WebASM and Javascript attacks crashing Windows 10 ARM devices because of this.
You'd have to persuade the JIT to generate a SETEND instruction, which sounds difficult.
Huh? The Windows NT kernel was originally brought up on the Intel i860 (RISC processor) and then ported to x86, to make sure that it was portable and didn't include any x86isms outside of the HAL. They've been maintaining ports to other architectures internally since then to ensure that it keeps this property.
If you read Tanenbaum's Modern Operating Systems, you'll see a good comparison of the NT kernel to a couple of UNIX systems and it comes off pretty well in the comparison.
And Intel's claim is that if executing an instruction uses a patented process it doesn't matter if you execute it in hardware or translate the instruction and execute that - you still need a patent license or you will be sued.
There is some awful case law from a MIPS lawsuit that lends some weight to this. MIPS patented a pair of instructions to do unaligned loads and stores more efficiently than doing a shift-and-mask. A competitor created a MIPS-compatible CPU that trapped on these instructions and emulated them in software. MIPS claimed that this violated their patent and, in a shocking lack of judgement, the court agreed with them.
Nope. Microsoft bought Connectix for their VirtualPC for Windows product, which became Microsoft VirtualPC and then was merged into their other virtualisation platforms, but Connectix was better known for VirtualPC for Mac (which had one release after Microsoft bought them and was then killed, largely because IBM's PowerPC 970 didn't include the instructions that made byte swapping cheap): an x86 emulator that ran on PowerPC. It was pretty good for the time and ran a useable GUI on a 1.25GHz PowerPC. It did a bunch of work to detect uses of condition codes and skip generating them if they're not used, which is one of the pain points when emulating x86.
It depends a bit on what those patents cover. You can't patent the idea of a 128-bit vector, so it must be on details of specific instructions. ARM has had a 128-bit vector unit for quite a long time and a lot of SSE instructions map trivially to NEON equivalents. If those instructions are the ones that are covered by the patents, then ARM will already have a cross-licensing agreement in place to cover them.
It will expect everything it sees to have the x86 structure alignment
The structure alignment rules for anything that's not a packed structure are likely to be the same for both. You may have some issues with stack frame layouts, but that's a separate issue.
x86 and x64 code handles misaligned pointers transparently, though occasionally at a enormous performance hit if they span a page boundary. ARM code does not
That isn't true for any ARM core released in the last 10 years, possibly the last 15 years.
However NT kernels are architected so that you can't have page faults when you're running a raised IRQL, because if you're doing that you hold a spinlock
That's far more important: you don't want to be trapping out to an emulator in an interrupt context. You also probably don't want to stick the emulator in the kernel in the first place, because that's a nice big attack surface for malware to play with.
x86-64 would be a nice to have but the idea is to get developers releasing arm64 binaries, not rely on emulation indefinitely.
I suspect that they're hoping, given the slow adoption of Win64, that anything that's been released as a Win64 app is under active development and so easy to get working on ARM. The emulator is intended for legacy things where no one has the source code (or, at least, the people that do have no incentive to support an ARM build).
Loading x86 code into a process that's running native ARM code just isn't going to work
I would be shocked if they weren't doing this, because that's how modern high-performance application emulators work: you compile all of the system libraries as native code and insert shims for communicating between them. ARM and x86 are both little endian, so that difficulty goes away. I'd be surprised if struct layouts were different between Windows/ARM and Windows/x86. Calling conventions need translating when you go to and from emulation, but that's trivial.
That said, I expect that most of the things like the shell are AArch64 binaries, which makes this kind of thing a lot harder.
I'm not sure about software, but a Harvard study a few years ago found a strong correlation between music purchase and music piracy: i.e. the people that pirated the most music also bought the most music.
Anti-piracy measures work to turn the last category into sales, but don't help your bottom line for any of the other things. These people are the only ones where piracy hurts sales, but they're a minority (at least according to the academic studies that I've read). The big problem for most companies in these markets is that they regard reducing piracy as a goal, when their aim should be to increase sales. Would you rather sell 1,000 copies and have no pirates, or sell a million copies and have ten million pirated versions in circulation? The music industry finally learned this, and saw a big increase in sales once they allowed Apple and Amazon to sell DRM-free downloads.
You expect someone to be able to write code, but not able to save a text file with a .html extension and double click on it? One of these things is much harder than the other.
The problem is a bit more subtle that that: promotion is usually easier by moving companies than internally. That means that a lot of those junior developers that you train will likely go elsewhere, so you don't benefit from their experience. It gets worse when you apply a little bit of game theory: junior developers take some productivity from senior ones, so a company that employs only senior developers will be more productive overall. This means that the best strategy is to rely on your competitors training people and then hire them once they're experienced. This works well when a minority of companies are doing it, but doesn't when it becomes a majority. It's also difficult to fix, because any company that adjusts its balance of employees towards having more junior devs is going to be at a competitive disadvantage, even if they manage to retain all of the developers that they train.
Fizzbuzz isn't a selection test, it's a deselection test. You don't ask a candidate to implement Fizzbuzz to show you that they're competent, you ask it to show that they're not incompetent. It filters out the people who wrote '10 years C++ development' on their CV but don't actually understand for loops and if statements. Anyone with more than a couple of weeks worth of programming experience should be able to do it.
The problem for people hiring is that a lot of people that make it to interview can't - and if you can't implement Fizzbuzz then you're not going to be able to write any nontrivial software.
How will you ever understand why some things are more efficient than others, why division is so fucking slow, why floating point is useless, etc. if you were never taught about the underlying hardware?
I've read a lot of bad code written by people who didn't understand these things, but I've read a lot more bad code by people who focussed obsessively on these aspects and ignored the fact that they'd microoptimised the hell out of an O(n^2) algorithm when a naive implementation of an O(n log(n)) would have been far faster on their data.
In my experience, it's better to get people to design good algorithms first. It's easier to then teach them about low-level data representations, cache hierarchies, communication latencies, and so on than it is to persuade someone who has learned a bunch of microoptimisation techniques to step back and improve their algorithms.
One of my colleagues likes to tell a story about an intern who decided that the Perl code that they were using was too slow and rewrote it in C, only to find that it was an order of magnitude slower. The compute was faster, but the standard Perl libraries do very good I/O buffering and prefetching and even with that it was already I/O limited. Making the compute step faster didn't speed anything up, because compute wasn't the bottleneck. The C version could process a single record in about a tenth the time that the Perl version could, but was still slower overall because the intern had focussed on optimising the compute step and not the I/O.