C++17 is pretty much my go-to language these days, but this is just plain wrong:
These days we use smart pointers, which have almost no overhead, and easily avoid memory leaks and memory management
The C++ standard library provides two kinds of smart pointers (ignoring weak ones for now): std::unique_ptr and std::shared_ptr. The former doesn't have 'almost no overhead', it has exactly no overhead, because the entire implementation is optimised away. The latter; however, can have significant overhead. C++ relies on deterministic destruction and so none of the techniques that are normally used to optimise reference counting can be used: as soon as the last std::shared_ptr to an object is destroyed, the object must be destroyed. This means that every copy of a shared_ptr is an atomic increment and every destruction is an atomic decrement. If the object is not shared between threads, then this is very cheap, but if it is (even if the object itself is immutable) then each pointer copy and each pointer destruction can have around a 300-cycle cost (plus the cost of the branch in the destroy case). This can add up quite quickly. In contrast, a language with a tracking collector can make most pointer manipulations as cheap as bare pointers. In terms of throughput, tracing GCs scale a lot better to multiple cores than this kind of atomic reference counting, though they trade some worst-case latency for this (which can be a problem in distributed systems).
That's not really a fair comparison. The C specification defines a language and a very small standard library. The Java specification defines a language and a huge standard library. For anything where Java is an appropriate choice, you're not going to be writing C and relying on just the C standard library, you're going to be using some third-party toolkit that, like the Java standard library, abstracts away a lot of platform independence.
Even then, I'd disagree. Java is good for portability if you're using one of the common platforms, but the further you get from that, the more patchy it becomes. Try running Java on OpenBSD / MIPS (actually, try running Java on any OS on 64-bit MIPS - the only implementation that mostly works is JamVM, and it's a simple interpreter that doesn't support the latest version of Java) and you'll find that the portability isn't quite as good as you might think.
Java is portable to any platform that the JVM and standard library have been ported, but the same is true of most languages: they'll run on any platform where the compiler and the libraries that you're using have been ported. The difference with Java is that it tends to be an all-or-nothing proposition. You aren't allowed to ship partial implementations of Java (the patent grant on the various bits of Java only extends to fully conforming implementations) and so you're unlikely to find a subset of Java that does everything (or almost everything) your program needs working on a platform, whereas you often will with other languages.
Some JAVA code might run slightly as fast as C but definetly is never bare metal
You might look at Java Card. It's a fairly restrictive subset of Java, but it is one of the most widely deployed instances of any language ever. For example, it's present in all SIM cards, many door-access cards, and so on. A number of Java Card implementations have the bytecode decoder implemented in hardware and so run the Java directly.
The only thing I was trying to point out was that Apple was involved in the earliest days of ARM history.
There's a difference between 'involved at the start' and 'involved since the start'. I don't contest that Apple was involved at the beginning, but they then largely did nothing with ARM other than buy some chips until about ten years ago, during which time ARM grew from being a tiny niche architecture primarily used in desktops from a British company that never managed to break into international markets to the most widespread ISA in deployment.
There aren't a whole lot of companies with ARM Architecture Licenses, period, and please tell me exactly what most of them, including Intel, have even been doing with theirs?
I'll admit that 'a lot' may have been an exaggeration in a market with about a dozen players in total, but for the record:
Intel has been mostly sitting on theirs, but they were quite active with the StrongARM line for a bit (for a while they had two architecture licenses through different acquisitions, this one from Digital) and the follow-on XScale line designed in house. These were the highest performance ARM cores on the market for several years. Intel pulled back from the ARM market a while ago, though they keep their ARM architecture license and use a surprising number of ARM cores in various places (for example, Intel NICs have Intel-desigend ARM cores in them).
Qualcomm is an architecture partner and the Snapdragon series does pretty well and their acquisition of the mobile Radeon line from AMD lets them pair them with some very solid GPU cores. I think they got their architecture license around 2003/4 (it was in negotiation for a while before that), a few years before Apple got theirs.
Marvell got the other architecture license that Intel had, when Intel sold it off in 2006, around the time Apple became an architecture licensee. They've produced ARM cores implementing the ARMv5, ARMv6 and ARMv7-A architectures (Apple's oldest public core is v7-A, I think that the later iPods may have been in-house v6 designs, but I'm not 100% sure as I don't really interact with that business unit much. Apple's first iPhone core was basically an ARM core with some very minor layout tweaks).
The newer architecture licensees are mostly in less-traditional markets or implementations:
nVidia probably makes the most interesting ARM cores. Their Project Denver processors were designed without knowing until very late in the process whether they'd be x86 or ARM - nVidia was negotiating with both Intel and ARM for a license and eventually the negotiations with Intel fell through. Project Denver is based on the ideas nVidia acquired from Transmeta, with a healthy dose of GPU-inspired design thrown in. There's a simple in-order ARM core that collects profiling data and then a VLIW processor with quite an interesting design (the pipelines are offset from each other, so each stage can feed the next one). ARM instruction sequences are JIT compiled for the VLIW core and executed at much higher speed once hot code paths have been identified. This can give very impressive performance on certain workloads.
Cavium has been replacing their 64-bit MIPS lines with ARMv8 for a few years. Their customers are primarily networking vendors (Cisco, Juniper, and friends) and they deal in very high core and thread counts, with lower per-thread performance. We have a few of their systems - 48 cores per socket, two socket, and they're quite nice (though Cavium really doesn't seem to understand atomics that well).
Advanced Micro and AMD both have ARM cores targeted at the traditional server space, but they're both fairly new to the market (earlier AMD chips used ARM-designed cores).
Samsung has not had an architecture license for long, but they're starting to replace ARM-licensed cores with their own in-house designs. I've not seen any in the wild yet, so I don't know how they perform.
All of those were dropped from the Nazi platform in the mid '30s, before they came to power, when they started actively courting industrialists and the middle classes. The Nazis were founded as a nationalist party with just enough socialism to attract the working class away from communism (their expressed intention was to oppose communism). The completely abandoned any left-wing principles to achieve power.
And my mother used her original iPhone until her carrier essentially forced her to upgrade to stay compatible with their services. Does that mean iPhones all last almost a decade
Was the iPhone getting security updates for that time? The last release of iOS to work on the original iPhone was iPhone OS 3.1.3. It stopped getting security updates in 2012. The original iPhone was released in 2007, so that's a maximum of five years. If she was using it for a decade then she was using it with known, remotely exploitable, security vulnerabilities for almost half of that time. That's a very odd definition of 'last'.
Wow, that's a very superficial article. The article states: 'ARM is founded as a spin-off from Acorn and Apple, after the two companies started collaborating on the ARM processor as part of the development of Apple's new Newton computer system.' Apple wanted to use ARM chips, but didn't want to buy them from Acorn, because Acorn's core product was a direct competitor for the Mac. They insisted that ARM be spun off and provided a lot of the initial capital, but it wasn't just a joint venture, the third partner was VLSI Technology, who don't seem to be mentioned at all. Apple had very little input into the designs, they just bought the cores.
After Steve Jobs returned and killed the Newton, most of the people with ARM experience left Apple. Apple didn't start re-hiring people with this kind of expertise until they decided to stop licensing PortalPlayer SoCs for the iPod and move the design in-house. There are a lot of companies that have been ARM architecture licensees for a lot longer than Apple (including Intel) and there are quite a few that have been actively designing ARM chips for longer.
It's not just Tsarist Russia. Stalin was responsible for killing more Jews than Hitler (though you'd have to be quite the victim of 1950s US propaganda to regard Stalin as left wing).
Except for the largest antisemitic group in history, the Nazis who were decidedly right wing.
If you believe this, then you really have a very shallow grasp of history. Persecuting Jews was a popular pastime in Europe for a long time before the Nazis came along. Read The Merchant of Venice sometime to get a feel for how Jews were perceived in Shakespeare's time. Even the term Pogrom predate the Nazis by a good 40-50 years. The two largest groups that have actively persecuted Jews are Catholics and Muslims. Nazis don't even beat Russians in terms of the number of people doing the persecuting or the number of Jews killed.
I've noticed that a lot of web sites now cause my browser to ask me if I trust them to run WebGL code for no obvious reason (I don't, because I've worked on GPU drivers, and there's no way I'd trust them with potentially malicious code, even if it has had some token WebGL verification). JavaScript is fairly slow, but WebGL and WebCL let JavaScript run shader code on your GPU.
Most cryptocurrency mining is probabilistic: you only win on average by having the most compute, each step involves trying a possible solution and hopefully getting lucky. If you try enough solutions in parallel, you'll probably find the correct one before anyone else. Even if each person only gives you 30 seconds of GPU time, that's still a lot if you can infect a few million people.
I seem to recall a browser-based game a few years ago that used this exact business model: as you play the game, it mined bitcoin in the background on your GPU, which paid for the game.
Just the app switching button on Android alone makes it 10x faster to do stuff than on iOS.
Double tap the home button on an iOS device and you'll get a view that is very similar to the Android one (i.e. the one both Android and iOS copied from WebOS).
You can double tap it to switch back and forth between two apps, which is great for note taking, comparing or copy/pasting translations
I've never done that, but it sounds useful. Though for that use case, the ability of iOS to display two apps side by side may be even more useful.
Two reasons. The first is that click-through terms of service may or may not be binding depending on what a court decides. If the court decides that a reasonable human would not understand particular terms, they can strike down individual clauses or the entire thing. Second, because the Facebook tracks people who have not agreed to the terms of service and therefore have no business relationship with the company.
Hell for that matter apple compiles its apps on llvm, guess what android compiles its apps on nowadays... llvm
Nope. The initial versions of ART used LLVM, but the Google folk couldn't get the resource requirements down enough to run on the phone (no idea why they don't do the compilation on the app store and cache the results, rather than warming the planet), so they moved to a completely different infrastructure. Modern ART has two compilers (that they're trying really hard to unify). There's a JIT that runs when you first start an app. This collects profiling information, but doesn't do much optimisation initially. It will then generate optimised code for some of the hot paths. The profiling information is recorded and overnight (or at any period when the phone is plugged in but not used) the AOT compiler starts in the background and will generate optimised binaries. Unfortunately, the AOT compiler doesn't allow on-stack replacement and so the JIT can occasionally give better code for hot loops (it can perform speculative optimisations that are correct 99.9% of the time and then deoptimise in the case where they're incorrect, whereas the AOT compiler has to do the slower optimisation that's correct 100% of the time).
I think there's also an interpreter for fast start, but I lose track (the ART team keeps changing their mind about whether an interpreter is a good idea).
They're made in the same fabs, but they're not the same cores. Apple designs their own cores (they're an ARM architecture licensee, which means that they're allowed to build chips however they want as long as they pass ARM's architecture conformance tests). Their CPU design team was originally bought from PA-Semi, who designed low-power, high-performance PowerPC chips, and has been growing steadily for the last decade. Apple doesn't license these cores to anyone else.
There are degrees of protection. This particular attack isn't too bad, because you know that the police are inspecting your phone and if you live in a country with the rule of law then this must follow an recorded evidence chain (and, in fact, a plod showing you the phone to unlock it would probably violate that chain and give you grounds for a mistrial). It's much worse when the police can plug a USB dongle into your phone and dump all of your data for later analysis, because they don't need to notify you, they can just go fishing at any point where they have brief access to the phone and later appear with a warrant and follow procedure claiming an anonymous tipoff. This was the state of all Android phones until fairly recently.
That's debatable. An unified country or Ireland that is independent from England or Britain is a very new invention. Wales and Scotland (and even Cornwall) have more claim to having had a country first than Ireland. The first serious attempt to unify Ireland, somewhat ironically, was led by the same Norman invaders that had previously conquered England (which hadn't been a country for very long at that point either). Many of the early instances of country formation in Europe resulted from different smaller kingdoms being conquered by the same invaders.
Antisemitism has historically been linked to anti-banker and anti-capitalist sentiments. Christians and Muslims are prohibited by their respective religious texts from engaging in usury and for a lot of the last few hundred years this meant that the only people who made money by lending money (and, therefore, the only people that you could get a loan from) were Jews. This was inshrined in law in a lot of Europe: Christians and Muslims were prohibited not just by their faith, but by the legal system, from charging interest.
It's no accident that the enemy of the Party in Nineteen Eighty-Four had a Jewish name: Jews were seen as the enemies of socialism (and the Party, like the USSR, still claimed to be socialist in spite of having few traits in common with socialism).
You don't have to list it. Facebook tracks your browsing across almost any site with 'like' buttons, any links that you follow from Facebook, and so on. It's pretty easy to infer that prejudices from the news sources that someone frequents.
1) FTP uploads are easier to support than HTTP uploads HTTP uploads require CGI scripts to handle, and if configured wrongly, can lead to security issues (see FCC website w.r.t. comment system)
Nope, HTTP supports several verbs including PUT and POST. PUT doesn't require any scripting and can be configured in most servers to allow uploads based on the current authentication (which can be a client-side SSL certificate, a password, or a couple of other things).
2) FTP supports TLS -it's called FTPS (not to be confused with SFTP - the former uses FTP and initiates a TLS session, the latter uses SSH). Modern FTP clients and servers support STARTTLS as a command to initiate TLS, and they do it before the USER/PASS commands so the connection is encrypted from the get-go. Note that you need to use passive mode while doing this as most NAT gateways spy on FTP sessions to set up dynamic mappings, and TLS doesn't allow them to do it.
Needing to support passive mode isn't too much of a problem, because active mode is pretty broken with a lot of NATs anyway. Unfortunately, the STARTTLS mode is trivial to attack with downgrade attacks and most FTP clients don't complain. In contrast, HTTPS will simply fail if you don't have a valid certificate.
3) HTTP doesn't allow for easy downloading of multiple files other than picking and saving one at a time.
HTTP has much less protocol overhead than FTP and so requiring a new connection to download each file is not a problem, but you are correct that HTTP lacks a mechanism for listing files. Fortunately, WebDAV extends HTTP to provide this (plus the ability to remotely copy and move files, get metadata and lock them) and all major operating systems support it out of the box. Windows and macOS can mount WebDAV directories directly from their graphical file browser, Linux / *BSD have FUSE implementations, at which point you can list and copy / move your files using whatever your preferred method for accessing the local filesystem is (including the command line and via scripts, if you're that-way inclined).
FTP can be done using TLS and there is also SSH-FTP. FTPS is no more or less secure than HTTPS.
FTP over TLS is a pain, because you still end up needing multiple connections and the protocol is a nightmare. It's also implemented in a variety of different and incompatible ways by different people and so there's basically no good way of supporting it. SFTP is an entirely different protocol that shares some initials with FTP but is otherwise unrelated.
Have you ever downloaded large files over HTTP? It's not built for it, you practically need a download manager because the browsers will just choke or won't be able to continue unfinished downloads and there are hacks that make it work but many configurations aren't set up right to continue partial downloads.
I don't think I've downloaded anything over about 50GB via HTTP, but I've had no problems doing so. The protocol supports range requests and both command-line tools and vaguely modern (last 10-15 years) web browsers will happily use that to resume interrupted downloads. Oh, and the range-based part of the protocol also means that you can easily download parts of the file in parallel if you're on a high-bandwidth, high-latency connection and TCP is fighting you.
Your entire comment here makes no sense, because you're saying that it's possible to write a client for HTTP (a download manager) that does everything that you want and therefore the protocol is bad.
Spoken like someone who has never looked at the FTP protocol or the code in a client or server. HTTP is far simpler to implement than FTP and, unlike FTP, is also trivial to add TLS support to, easier to scale up with CDNs, and so on. FTP hasn't been the right tool for any job for well over a decade.
Meanwhile, NeXTSTEP and derivatives (including OS X and GNUstep) have supported 'open {file}' to open it in your preferred graphical application ('open {directory}' to open a directory in the graphical file manager) since 1988.
'd like to see more "generative" systems that generate static HTML from a CMS and uploaded automatically and periodically via a one-way FTP connection
This is what Jekyll does and it's supported by GitHub pages. It's very easy to set up so that a post-push git hook regenerates the site and sets the permissions so that the web server process can read it but can't write anything in that directory. The down side is that you don't get any dynamic content (comments and so on). I've never been quite motivated enough to write a comment system that stores everything in an append-only log and has write access to precisely that one file, so if it's compromised you can always just roll back to the last pre-compromised state.
It took a couple of hours to migrate from the stock Android to LineageOS (doing the same thing for my partner's phone was much faster once I'd done it once). Beyond that, the updates are pretty much automatic - I get a notification that one is available, I tap to install it, I do something else for a few minutes for it to finish.
In the UK, the Consumer Rights Act (which largely just does what the EU requires) states that the device warranty is largely irrelevant and that the device must continue to work for the expected lifetime of such a device or it can be returned to the seller for a full refund. If Apple wants to argue that 1 year is the expected lifetime of an iPhone, then that's fine, but they'd better expect all of their competitors to put that in their adverts.
Slashdot Mirror
These days we use smart pointers, which have almost no overhead, and easily avoid memory leaks and memory management
The C++ standard library provides two kinds of smart pointers (ignoring weak ones for now): std::unique_ptr and std::shared_ptr. The former doesn't have 'almost no overhead', it has exactly no overhead, because the entire implementation is optimised away. The latter; however, can have significant overhead. C++ relies on deterministic destruction and so none of the techniques that are normally used to optimise reference counting can be used: as soon as the last std::shared_ptr to an object is destroyed, the object must be destroyed. This means that every copy of a shared_ptr is an atomic increment and every destruction is an atomic decrement. If the object is not shared between threads, then this is very cheap, but if it is (even if the object itself is immutable) then each pointer copy and each pointer destruction can have around a 300-cycle cost (plus the cost of the branch in the destroy case). This can add up quite quickly. In contrast, a language with a tracking collector can make most pointer manipulations as cheap as bare pointers. In terms of throughput, tracing GCs scale a lot better to multiple cores than this kind of atomic reference counting, though they trade some worst-case latency for this (which can be a problem in distributed systems).
Java beats C hands down in portability.
That's not really a fair comparison. The C specification defines a language and a very small standard library. The Java specification defines a language and a huge standard library. For anything where Java is an appropriate choice, you're not going to be writing C and relying on just the C standard library, you're going to be using some third-party toolkit that, like the Java standard library, abstracts away a lot of platform independence.
Even then, I'd disagree. Java is good for portability if you're using one of the common platforms, but the further you get from that, the more patchy it becomes. Try running Java on OpenBSD / MIPS (actually, try running Java on any OS on 64-bit MIPS - the only implementation that mostly works is JamVM, and it's a simple interpreter that doesn't support the latest version of Java) and you'll find that the portability isn't quite as good as you might think.
Java is portable to any platform that the JVM and standard library have been ported, but the same is true of most languages: they'll run on any platform where the compiler and the libraries that you're using have been ported. The difference with Java is that it tends to be an all-or-nothing proposition. You aren't allowed to ship partial implementations of Java (the patent grant on the various bits of Java only extends to fully conforming implementations) and so you're unlikely to find a subset of Java that does everything (or almost everything) your program needs working on a platform, whereas you often will with other languages.
Some JAVA code might run slightly as fast as C but definetly is never bare metal
You might look at Java Card. It's a fairly restrictive subset of Java, but it is one of the most widely deployed instances of any language ever. For example, it's present in all SIM cards, many door-access cards, and so on. A number of Java Card implementations have the bytecode decoder implemented in hardware and so run the Java directly.
The only thing I was trying to point out was that Apple was involved in the earliest days of ARM history.
There's a difference between 'involved at the start' and 'involved since the start'. I don't contest that Apple was involved at the beginning, but they then largely did nothing with ARM other than buy some chips until about ten years ago, during which time ARM grew from being a tiny niche architecture primarily used in desktops from a British company that never managed to break into international markets to the most widespread ISA in deployment.
There aren't a whole lot of companies with ARM Architecture Licenses, period, and please tell me exactly what most of them, including Intel, have even been doing with theirs?
I'll admit that 'a lot' may have been an exaggeration in a market with about a dozen players in total, but for the record: Intel has been mostly sitting on theirs, but they were quite active with the StrongARM line for a bit (for a while they had two architecture licenses through different acquisitions, this one from Digital) and the follow-on XScale line designed in house. These were the highest performance ARM cores on the market for several years. Intel pulled back from the ARM market a while ago, though they keep their ARM architecture license and use a surprising number of ARM cores in various places (for example, Intel NICs have Intel-desigend ARM cores in them).
Qualcomm is an architecture partner and the Snapdragon series does pretty well and their acquisition of the mobile Radeon line from AMD lets them pair them with some very solid GPU cores. I think they got their architecture license around 2003/4 (it was in negotiation for a while before that), a few years before Apple got theirs.
Marvell got the other architecture license that Intel had, when Intel sold it off in 2006, around the time Apple became an architecture licensee. They've produced ARM cores implementing the ARMv5, ARMv6 and ARMv7-A architectures (Apple's oldest public core is v7-A, I think that the later iPods may have been in-house v6 designs, but I'm not 100% sure as I don't really interact with that business unit much. Apple's first iPhone core was basically an ARM core with some very minor layout tweaks).
The newer architecture licensees are mostly in less-traditional markets or implementations:
nVidia probably makes the most interesting ARM cores. Their Project Denver processors were designed without knowing until very late in the process whether they'd be x86 or ARM - nVidia was negotiating with both Intel and ARM for a license and eventually the negotiations with Intel fell through. Project Denver is based on the ideas nVidia acquired from Transmeta, with a healthy dose of GPU-inspired design thrown in. There's a simple in-order ARM core that collects profiling data and then a VLIW processor with quite an interesting design (the pipelines are offset from each other, so each stage can feed the next one). ARM instruction sequences are JIT compiled for the VLIW core and executed at much higher speed once hot code paths have been identified. This can give very impressive performance on certain workloads.
Cavium has been replacing their 64-bit MIPS lines with ARMv8 for a few years. Their customers are primarily networking vendors (Cisco, Juniper, and friends) and they deal in very high core and thread counts, with lower per-thread performance. We have a few of their systems - 48 cores per socket, two socket, and they're quite nice (though Cavium really doesn't seem to understand atomics that well).
Advanced Micro and AMD both have ARM cores targeted at the traditional server space, but they're both fairly new to the market (earlier AMD chips used ARM-designed cores).
Samsung has not had an architecture license for long, but they're starting to replace ARM-licensed cores with their own in-house designs. I've not seen any in the wild yet, so I don't know how they perform.
All of those were dropped from the Nazi platform in the mid '30s, before they came to power, when they started actively courting industrialists and the middle classes. The Nazis were founded as a nationalist party with just enough socialism to attract the working class away from communism (their expressed intention was to oppose communism). The completely abandoned any left-wing principles to achieve power.
And my mother used her original iPhone until her carrier essentially forced her to upgrade to stay compatible with their services. Does that mean iPhones all last almost a decade
Was the iPhone getting security updates for that time? The last release of iOS to work on the original iPhone was iPhone OS 3.1.3. It stopped getting security updates in 2012. The original iPhone was released in 2007, so that's a maximum of five years. If she was using it for a decade then she was using it with known, remotely exploitable, security vulnerabilities for almost half of that time. That's a very odd definition of 'last'.
Wow, that's a very superficial article. The article states: 'ARM is founded as a spin-off from Acorn and Apple, after the two companies started collaborating on the ARM processor as part of the development of Apple's new Newton computer system.' Apple wanted to use ARM chips, but didn't want to buy them from Acorn, because Acorn's core product was a direct competitor for the Mac. They insisted that ARM be spun off and provided a lot of the initial capital, but it wasn't just a joint venture, the third partner was VLSI Technology, who don't seem to be mentioned at all. Apple had very little input into the designs, they just bought the cores.
After Steve Jobs returned and killed the Newton, most of the people with ARM experience left Apple. Apple didn't start re-hiring people with this kind of expertise until they decided to stop licensing PortalPlayer SoCs for the iPod and move the design in-house. There are a lot of companies that have been ARM architecture licensees for a lot longer than Apple (including Intel) and there are quite a few that have been actively designing ARM chips for longer.
It's not just Tsarist Russia. Stalin was responsible for killing more Jews than Hitler (though you'd have to be quite the victim of 1950s US propaganda to regard Stalin as left wing).
Except for the largest antisemitic group in history, the Nazis who were decidedly right wing.
If you believe this, then you really have a very shallow grasp of history. Persecuting Jews was a popular pastime in Europe for a long time before the Nazis came along. Read The Merchant of Venice sometime to get a feel for how Jews were perceived in Shakespeare's time. Even the term Pogrom predate the Nazis by a good 40-50 years. The two largest groups that have actively persecuted Jews are Catholics and Muslims. Nazis don't even beat Russians in terms of the number of people doing the persecuting or the number of Jews killed.
I've noticed that a lot of web sites now cause my browser to ask me if I trust them to run WebGL code for no obvious reason (I don't, because I've worked on GPU drivers, and there's no way I'd trust them with potentially malicious code, even if it has had some token WebGL verification). JavaScript is fairly slow, but WebGL and WebCL let JavaScript run shader code on your GPU.
Most cryptocurrency mining is probabilistic: you only win on average by having the most compute, each step involves trying a possible solution and hopefully getting lucky. If you try enough solutions in parallel, you'll probably find the correct one before anyone else. Even if each person only gives you 30 seconds of GPU time, that's still a lot if you can infect a few million people.
I seem to recall a browser-based game a few years ago that used this exact business model: as you play the game, it mined bitcoin in the background on your GPU, which paid for the game.
Just the app switching button on Android alone makes it 10x faster to do stuff than on iOS.
Double tap the home button on an iOS device and you'll get a view that is very similar to the Android one (i.e. the one both Android and iOS copied from WebOS).
You can double tap it to switch back and forth between two apps, which is great for note taking, comparing or copy/pasting translations
I've never done that, but it sounds useful. Though for that use case, the ability of iOS to display two apps side by side may be even more useful.
Two reasons. The first is that click-through terms of service may or may not be binding depending on what a court decides. If the court decides that a reasonable human would not understand particular terms, they can strike down individual clauses or the entire thing. Second, because the Facebook tracks people who have not agreed to the terms of service and therefore have no business relationship with the company.
Hell for that matter apple compiles its apps on llvm, guess what android compiles its apps on nowadays... llvm
Nope. The initial versions of ART used LLVM, but the Google folk couldn't get the resource requirements down enough to run on the phone (no idea why they don't do the compilation on the app store and cache the results, rather than warming the planet), so they moved to a completely different infrastructure. Modern ART has two compilers (that they're trying really hard to unify). There's a JIT that runs when you first start an app. This collects profiling information, but doesn't do much optimisation initially. It will then generate optimised code for some of the hot paths. The profiling information is recorded and overnight (or at any period when the phone is plugged in but not used) the AOT compiler starts in the background and will generate optimised binaries. Unfortunately, the AOT compiler doesn't allow on-stack replacement and so the JIT can occasionally give better code for hot loops (it can perform speculative optimisations that are correct 99.9% of the time and then deoptimise in the case where they're incorrect, whereas the AOT compiler has to do the slower optimisation that's correct 100% of the time).
I think there's also an interpreter for fast start, but I lose track (the ART team keeps changing their mind about whether an interpreter is a good idea).
They're made in the same fabs, but they're not the same cores. Apple designs their own cores (they're an ARM architecture licensee, which means that they're allowed to build chips however they want as long as they pass ARM's architecture conformance tests). Their CPU design team was originally bought from PA-Semi, who designed low-power, high-performance PowerPC chips, and has been growing steadily for the last decade. Apple doesn't license these cores to anyone else.
There are degrees of protection. This particular attack isn't too bad, because you know that the police are inspecting your phone and if you live in a country with the rule of law then this must follow an recorded evidence chain (and, in fact, a plod showing you the phone to unlock it would probably violate that chain and give you grounds for a mistrial). It's much worse when the police can plug a USB dongle into your phone and dump all of your data for later analysis, because they don't need to notify you, they can just go fishing at any point where they have brief access to the phone and later appear with a warrant and follow procedure claiming an anonymous tipoff. This was the state of all Android phones until fairly recently.
That's debatable. An unified country or Ireland that is independent from England or Britain is a very new invention. Wales and Scotland (and even Cornwall) have more claim to having had a country first than Ireland. The first serious attempt to unify Ireland, somewhat ironically, was led by the same Norman invaders that had previously conquered England (which hadn't been a country for very long at that point either). Many of the early instances of country formation in Europe resulted from different smaller kingdoms being conquered by the same invaders.
Antisemitism has historically been linked to anti-banker and anti-capitalist sentiments. Christians and Muslims are prohibited by their respective religious texts from engaging in usury and for a lot of the last few hundred years this meant that the only people who made money by lending money (and, therefore, the only people that you could get a loan from) were Jews. This was inshrined in law in a lot of Europe: Christians and Muslims were prohibited not just by their faith, but by the legal system, from charging interest.
It's no accident that the enemy of the Party in Nineteen Eighty-Four had a Jewish name: Jews were seen as the enemies of socialism (and the Party, like the USSR, still claimed to be socialist in spite of having few traits in common with socialism).
You don't have to list it. Facebook tracks your browsing across almost any site with 'like' buttons, any links that you follow from Facebook, and so on. It's pretty easy to infer that prejudices from the news sources that someone frequents.
1) FTP uploads are easier to support than HTTP uploads HTTP uploads require CGI scripts to handle, and if configured wrongly, can lead to security issues (see FCC website w.r.t. comment system)
Nope, HTTP supports several verbs including PUT and POST. PUT doesn't require any scripting and can be configured in most servers to allow uploads based on the current authentication (which can be a client-side SSL certificate, a password, or a couple of other things).
2) FTP supports TLS -it's called FTPS (not to be confused with SFTP - the former uses FTP and initiates a TLS session, the latter uses SSH). Modern FTP clients and servers support STARTTLS as a command to initiate TLS, and they do it before the USER/PASS commands so the connection is encrypted from the get-go. Note that you need to use passive mode while doing this as most NAT gateways spy on FTP sessions to set up dynamic mappings, and TLS doesn't allow them to do it.
Needing to support passive mode isn't too much of a problem, because active mode is pretty broken with a lot of NATs anyway. Unfortunately, the STARTTLS mode is trivial to attack with downgrade attacks and most FTP clients don't complain. In contrast, HTTPS will simply fail if you don't have a valid certificate.
3) HTTP doesn't allow for easy downloading of multiple files other than picking and saving one at a time.
HTTP has much less protocol overhead than FTP and so requiring a new connection to download each file is not a problem, but you are correct that HTTP lacks a mechanism for listing files. Fortunately, WebDAV extends HTTP to provide this (plus the ability to remotely copy and move files, get metadata and lock them) and all major operating systems support it out of the box. Windows and macOS can mount WebDAV directories directly from their graphical file browser, Linux / *BSD have FUSE implementations, at which point you can list and copy / move your files using whatever your preferred method for accessing the local filesystem is (including the command line and via scripts, if you're that-way inclined).
FTP can be done using TLS and there is also SSH-FTP. FTPS is no more or less secure than HTTPS.
FTP over TLS is a pain, because you still end up needing multiple connections and the protocol is a nightmare. It's also implemented in a variety of different and incompatible ways by different people and so there's basically no good way of supporting it. SFTP is an entirely different protocol that shares some initials with FTP but is otherwise unrelated.
Have you ever downloaded large files over HTTP? It's not built for it, you practically need a download manager because the browsers will just choke or won't be able to continue unfinished downloads and there are hacks that make it work but many configurations aren't set up right to continue partial downloads.
I don't think I've downloaded anything over about 50GB via HTTP, but I've had no problems doing so. The protocol supports range requests and both command-line tools and vaguely modern (last 10-15 years) web browsers will happily use that to resume interrupted downloads. Oh, and the range-based part of the protocol also means that you can easily download parts of the file in parallel if you're on a high-bandwidth, high-latency connection and TCP is fighting you.
Your entire comment here makes no sense, because you're saying that it's possible to write a client for HTTP (a download manager) that does everything that you want and therefore the protocol is bad.
Yes, FTP isn't secure by itself, but it's simple.
Spoken like someone who has never looked at the FTP protocol or the code in a client or server. HTTP is far simpler to implement than FTP and, unlike FTP, is also trivial to add TLS support to, easier to scale up with CDNs, and so on. FTP hasn't been the right tool for any job for well over a decade.
Meanwhile, NeXTSTEP and derivatives (including OS X and GNUstep) have supported 'open {file}' to open it in your preferred graphical application ('open {directory}' to open a directory in the graphical file manager) since 1988.
'd like to see more "generative" systems that generate static HTML from a CMS and uploaded automatically and periodically via a one-way FTP connection
This is what Jekyll does and it's supported by GitHub pages. It's very easy to set up so that a post-push git hook regenerates the site and sets the permissions so that the web server process can read it but can't write anything in that directory. The down side is that you don't get any dynamic content (comments and so on). I've never been quite motivated enough to write a comment system that stores everything in an append-only log and has write access to precisely that one file, so if it's compromised you can always just roll back to the last pre-compromised state.
It took a couple of hours to migrate from the stock Android to LineageOS (doing the same thing for my partner's phone was much faster once I'd done it once). Beyond that, the updates are pretty much automatic - I get a notification that one is available, I tap to install it, I do something else for a few minutes for it to finish.
In the UK, the Consumer Rights Act (which largely just does what the EU requires) states that the device warranty is largely irrelevant and that the device must continue to work for the expected lifetime of such a device or it can be returned to the seller for a full refund. If Apple wants to argue that 1 year is the expected lifetime of an iPhone, then that's fine, but they'd better expect all of their competitors to put that in their adverts.