It's not so clear with 3D. It's something of a misnomer to call current displays 2D and this kind of VR interface 3D. Both provide a subset of the dozen or so cues that the human brain uses to turn inputs into a 3D mental model. They both, for example, manage occlusion and distance blurring, but neither manages (yet) to correctly adjust the focal depth of parts of the image that are further away. Motion sickness is caused by disagreements between some of these cues and between the other cues that you use to build your mental model of the world.
VR adjusts the image based on your head position (though latency here can cause problems as the visual signal and the inner ear signal come at different times), but it turns out that humans have a very strong notion of body image, so if they don't correctly track your arm positions and update them in the game then this causes nausea in a lot of people.
Unfortunately for the 3D film and game industry, it's not the case that simply adding more cues reduces the risk of motion sickness. It turns out that a third-person perspective on a 2D display is one of the minima for the percentage of the population to experience motion sickness. Move to first person, and this gets worse, though it's still a tiny percentage (some people can't play FPS games for more than a few minutes without feeling sick). Add a few more visual cues and you get a lot more people feeling sick. There's obviously a minimum when you get all of the cues right, because otherwise people would spend their entire lives experiencing motion sickness, but so far none of the mainstream 3D systems have found another point that's close to the 2D display. If you're going to develop a first-person game, and you can either develop it for a technology that 99% of humans can use without feeling sick, or spending more money to develop it for a technology that 80% can use, which would you do?
It's been almost a decade since I played that sort of game regularly, but even then I found a lot of people who thought the Half Life mod was the original Team Fortress.
The type of "hello world" is const char *, so your compiler should warn that you're dropping the const in an implicit cast (and if you're a sensible person and compile with -Werror, then your compiler will reject the code). You can get the behaviour that you want with:
const char s[] = "hello world";
This will copy the contents of the string literal into a mutable array. If you write this at the global scope, the copy will be done at compile time, so you'll end up with the string in the data section, not the rodata section (if you do it in a variable with automatic storage, you'll get a copy every time the variable comes into scope). Putting constant strings in the rodata section is important for optimisation, because it allows them to be coalesced. If you write "hello world" in two place, then you'll end up with a single string in the rodata section. With some linkers, if you also write "world" somewhere else, then you'll just get two pointers into the same string (this is also one of the reasons that C uses null-terminated strings: you can't do this with Pascal strings, and it saved a useful amount of memory on the PDP-11). Once you're sharing the string, it becomes a really bad idea to allow someone to modify it, because that modification will then become visible in a different bit of code.
That's pretty common for OO languages (or, in fact, any language with a notion of subtyping), where individual classes implement their own comparison operators. In C++ you can overload the comparison operators, but most OO languages that don't do operator overloading just use a named method. If you write a.equals(b), then you'll call the equals method implemented by the class of a. If you write b.equals(a) then you'll call the method implemented by the class of b. One may know about the other, but the converse is not guaranteed. The Objective-C collection classes document certain invariants for inserting objects into sets (or as keys in a dictionary), including that [a isEqual: b] implies [b isEqual: a] (and that [a isEqual: b] implies that [a hash] equals [b hash]), but this is impossible to statically verify in the general case.
Get your code into the SIM firmware and you have just bypassed a lot of security
The rest of your post is correct, but it's more true to say that if you get your code into the SIM firmware then you've bypassed a small amount of quite weak encryption.
Apple hasn't just been talking about this, they've implemented this for a while. Many of their devices take a physical SIM and also contain an eSIM, so you can have the SIM for your home network in their physically, but when you travel abroad you don't need to physically buy a local SIM to use for a week, you just pull up the settings screen and buy a short-term plan from one of a variety of different providers.
Try deleting all of your Google cookies and visiting YouTube. You can't even watch a video until you've clicked through a bunch of T&Cs explaining that you agree to their data collecting and sharing. There's a button at the bottom saying 'I agree' and another saying 'other options', if you click on the second one, then you get to a big page full of text that basically boils down to 'sucks to be you.' If you create a Google account, then you can somewhat restrict what they'll collect to anonimised, but there's a load of research showing that basically any form of anonimised data can be deanonimised by combining it with other data sets (which, by coincidence, Google also collects).
Repair manuals won't help with mobile phones. They're rarely thrown away because of hardware issues. It's far more likely that they will be thrown away because they are no longer getting software updates. In the case of iOS and some Android devices, a locked bootloader prevents third parties from supporting them, in the case of most Android devices there's no financial incentive for longer-term support so no one does. For example, I have an old HTC Desire that still works fine. It's a bit underpowered, but still runs a lot of modern Android apps. Unfortunately, the last CyanogenMod build for it is based on Android 2.3, which includes an old TLS stack that only supports versions of the protocol and cypher suites that are now not supported by servers because of known vulnerabilities. This means that it can't connect to any HTTPS URL, for example. I can install F-Droid on it, but F-Droid can't fetch the repositories over HTTPS. I can side-load applications, and as long as they don't use TLS (or ship their own TLS implementation), they work fine. It probably has several other known vulnerabilities though.
At least with CRTs, replacing them with a modern LCD will cut the power consumption by a huge amount (20-50W, vs 100+W), so there's a good reason for using the newer technology. A 7-year-old Android phone is about as capable as a low-end budget phone now, yet became effectively unusable after about 4 years of life.
The problem is that Facebook T&Cs, as well as granting Facebook an almost unlimited license to anything you upload also includes a clause that you agree to indemnify them against this kind of claim. So, while you might be able to take Facebook to court and win if they took a video your friend uploaded of you and sold it, they would then be able to turn around immediately and sue your friend for whatever amount the court awarded you.
It's not natural to agree to a set of terms and conditions that explicitly grants a third party unlimited commercial rights to anything that you upload, upload some things, and then complain that you no longer have control over those things.
Presumably he read the bit of the Facebook T&Cs that says that you grant them a non-exclusive, sublicensable, transferable, commercial license to anything that you upload, and that you agree to indemnify them against any claims of copyright infringement. They are entirely at liberty to take anything that you upload and sell it and are not required to give you a cut (remember the Starbucks posters with pictures of people who had uploaded Facebook pictures from their shops?). The only surprising part is that Facebook didn't manage to get paid for this.
In my last flat, they installed a camera that watched the bus stop in front of my front door and managed to install it in such a way that it could probably see into the bedroom of a couple of flats in the row. One of my neighbours complained and they took it down immediately.
That sounds like a pretty good thing. Most of our leaders have been guilty of corruption, but it's hard to think of any that have suffered as a result.
Gartner are vigorously trying to shove it up Apple's arse) is that the smartphone market is really the Android market.
That's not really true. From the report, the iOS market is around 22% of the size of the Android market. That's a much higher ratio than the size of the Mac market to the Windows market has ever been. Even that doesn't tell the whole story, because a large part of the Android market is very low-end phones, with razor-thin margins for the manufacturer and very few app sales. This is important to the sort of people reading this kind of report, because they care about what the return on investment will be from supporting a given platform. It doesn't matter that Android completely dominates in the poorer parts of Africa, India, and China to the extent that iOS is a rounding error, it matters what phones the people with money to spend on your product have.
Why do people keep repeating this? People have been living on meat-free diets for centuries and even in the '60s it was shown that a sensible diet will provide the full range of nutrients that humans require.
You need to grow around 40 times as much plant matter to feed a food animal and turn it into meat than you need to produce the equivalent amount of nutritional value directly from plants. That said, part of the reason that we eat ruminants is that they can digest a lot of plant matter that we can't. Some land is suitable for growing grasses but nothing that humans can eat. The most efficient use of this land for providing food is to use it for feed crops (though much of it could also be used for biofuel these days).
Unless he or his employer is willing to pay money to Facebook, and the amount that Facebook or, more likely, third-party resellers charge for this information is very cheap in comparison to the amount that it costs to hire a bad employee. What, you thought 'private' meant that Facebook wouldn't sell it to anyone who asks? You've obviously not read the Facebook privacy policy.
You are entirely correct, even though I absolutely hate how true it is. Most of getting (and much of maintaining) a job is about how much people like you, not about your competence
I disagree. When hiring, you have a limited amount of knowledge to make a decision that can be incredibly costly if you get it wrong (Joel on Software has a good article about the costs of hiring a bad employee vs the costs of hiring no one). A CV is easy to doctor (and unscrupulous recruitment agencies do this a lot). An in-person interview gives very little information for selection (though inability to answer basic technical questions provides good deselection information). If one of your employees has worked with a candidate before and can attest to the fact that they're competent, then that's an incredibly valuable piece of information. This is why your professional network matters: it's not about how much people like you, it's about whether people respect your ability enough to want to work with you again.
The same thing happens on Windows. For example, last year there was an arbitrary code execution vulnerability in the code that Norton Antivirus uses to scan images. For some idiotic reason, they were running this code with kernel privilege. It ran whenever an image file was written to disk, so it could be exploited by simply receiving an email attachment in a spam, which your antivirus would then scan and run the exploit, even if you never opened the file.
IoT devices are, by definition, running a network stack. That brings you into the 32KB of RAM requirement as a minimum. The requirements for JavaScript are pretty small relative to that.
Really? Branch delay slots (with 'unpredictable' behaviour if you put a branch in them), no complex addressing modes, weird instruction names (an unsigned add is the same as a signed add, except one will trap on overflow, because that's obviously what the difference between signed and unsigned means), special $hi and $lo registers because some instructions have an implicit destination. Half-arsed transition from a fixed-design pipeline so that some operations have hardware interlocks but some need some magic (and implementation-dependent) number of NOPs to work. Oh, and my favourite bit of MIPS, the superscalar NOP. When your ISA has a superscalar NOP, that's when you should realise that you've done something badly wrong.
In terms of programming, it's beautifully designed.
If you ever have to write ARM assembly, your head might explode if you think MIPS is beautifully designed.
The extension from 32-bit to 64-bit is pretty seamless.
The 'oh, by the way, if you don't sign-extend into the top 32 bits then you get undefined behaviour for any 32-bit arithmetic operation' thing is seamless? So any code that has to deal with 32-bit values ends up doing a left-shift by zero instruction (which makes the code totally readable - 'Hey, this looks like a nop, can we remove it?' 'no, it looks like a job, but we'll get garbage values if we remove it') at multiple points to enforce this invariant.
Even the MIPS instruction encoding is quite clean and the CPU design makes it easy for vendors to add their own interesting instructions to coprocessor 2. For example, my employer has a bunch of encryption and hashing related instructions added there. ARM does not allow you to add your own custom instructions to ARMv8, for example.
I'm guessing your employer is Cavium? Thank $DEITY that they're starting to produce decent ARMv8 chips and we can kill off support for their MIPS products in a few years. You might see this as a strength of MIPS, but to everyone else it's a massive weakness. Every MIPS vendor takes a version of GCC, hacks it up to support their extensions, and breaks support for other extensions in the meantime. They then can't get their patches upstreamed (the few that even try) and so their customers end up with an unmaintained dead-end fork. Worst ecosystem ever.
One advantage of the MIPS instruction is it very cleanly moved from 32-bits to 64 bits. With ARM that is not the case. AARCH64 is very different than 32-bit ARM.
I think that you and I have very different definitions of clean. MIPS quickly hacked on a 64-bit extension without thinking it through, AArch64 was the result of careful study of the intersection between code sequences that compilers like to generate and instructions that are efficient to implement. For example, a lot of the predication (really useful for assembly programmers, hard to implement in superscalar pipelines, hard to use for compilers) is gone, the user-addressable PC is gone (makes branch-prediction really hard on in-order pipelines) and so is store/load multiple (basically needs microcode). You keep all of the really useful bitfield manipulation instructions (no MIPS equivalent, and oh how I miss them when I have to deal with MIPS, which sadly I do on a regular basis), store and load pairs (including atomics on pairs) and so on.
Oh, and MIPSr6 is not backwards binary compatible with previous versions. All of the branch-likely opcodes were recycled as compact branch (no delay slot), you you need to patch your binaries if you want them to work.
Most of the Android runtime is written in C++, as is most of Apple's Objective-C runtime. Microsoft had a project to turn Singularity into a product (which, sadly, was cancelled before completion) where the implemented their entire.NET runtime and OS in C#. The Jikes RVM is written mostly in Java - specifically, the JIT compiler and garbage collector are both Java. The Squeak Smalltalk VM (and descendants such as Pharo) are written in Smalltalk, with a small core that is statically compiled and the rest then running on this bootstrap subset.
Slashdot Mirror
It's not so clear with 3D. It's something of a misnomer to call current displays 2D and this kind of VR interface 3D. Both provide a subset of the dozen or so cues that the human brain uses to turn inputs into a 3D mental model. They both, for example, manage occlusion and distance blurring, but neither manages (yet) to correctly adjust the focal depth of parts of the image that are further away. Motion sickness is caused by disagreements between some of these cues and between the other cues that you use to build your mental model of the world. VR adjusts the image based on your head position (though latency here can cause problems as the visual signal and the inner ear signal come at different times), but it turns out that humans have a very strong notion of body image, so if they don't correctly track your arm positions and update them in the game then this causes nausea in a lot of people.
Unfortunately for the 3D film and game industry, it's not the case that simply adding more cues reduces the risk of motion sickness. It turns out that a third-person perspective on a 2D display is one of the minima for the percentage of the population to experience motion sickness. Move to first person, and this gets worse, though it's still a tiny percentage (some people can't play FPS games for more than a few minutes without feeling sick). Add a few more visual cues and you get a lot more people feeling sick. There's obviously a minimum when you get all of the cues right, because otherwise people would spend their entire lives experiencing motion sickness, but so far none of the mainstream 3D systems have found another point that's close to the 2D display. If you're going to develop a first-person game, and you can either develop it for a technology that 99% of humans can use without feeling sick, or spending more money to develop it for a technology that 80% can use, which would you do?
It's been almost a decade since I played that sort of game regularly, but even then I found a lot of people who thought the Half Life mod was the original Team Fortress.
This will copy the contents of the string literal into a mutable array. If you write this at the global scope, the copy will be done at compile time, so you'll end up with the string in the data section, not the rodata section (if you do it in a variable with automatic storage, you'll get a copy every time the variable comes into scope). Putting constant strings in the rodata section is important for optimisation, because it allows them to be coalesced. If you write "hello world" in two place, then you'll end up with a single string in the rodata section. With some linkers, if you also write "world" somewhere else, then you'll just get two pointers into the same string (this is also one of the reasons that C uses null-terminated strings: you can't do this with Pascal strings, and it saved a useful amount of memory on the PDP-11). Once you're sharing the string, it becomes a really bad idea to allow someone to modify it, because that modification will then become visible in a different bit of code.
If one developer makes a mistake, it's the fault of the developer. If most developers make the same mistake, it's the fault of the language.
That's pretty common for OO languages (or, in fact, any language with a notion of subtyping), where individual classes implement their own comparison operators. In C++ you can overload the comparison operators, but most OO languages that don't do operator overloading just use a named method. If you write a.equals(b), then you'll call the equals method implemented by the class of a. If you write b.equals(a) then you'll call the method implemented by the class of b. One may know about the other, but the converse is not guaranteed. The Objective-C collection classes document certain invariants for inserting objects into sets (or as keys in a dictionary), including that [a isEqual: b] implies [b isEqual: a] (and that [a isEqual: b] implies that [a hash] equals [b hash]), but this is impossible to statically verify in the general case.
Get your code into the SIM firmware and you have just bypassed a lot of security
The rest of your post is correct, but it's more true to say that if you get your code into the SIM firmware then you've bypassed a small amount of quite weak encryption.
Apple hasn't just been talking about this, they've implemented this for a while. Many of their devices take a physical SIM and also contain an eSIM, so you can have the SIM for your home network in their physically, but when you travel abroad you don't need to physically buy a local SIM to use for a week, you just pull up the settings screen and buy a short-term plan from one of a variety of different providers.
They don't need to go that far. Simply banning Windows 10 from government computers would be a significant dent in Microsoft's sales.
Try deleting all of your Google cookies and visiting YouTube. You can't even watch a video until you've clicked through a bunch of T&Cs explaining that you agree to their data collecting and sharing. There's a button at the bottom saying 'I agree' and another saying 'other options', if you click on the second one, then you get to a big page full of text that basically boils down to 'sucks to be you.' If you create a Google account, then you can somewhat restrict what they'll collect to anonimised, but there's a load of research showing that basically any form of anonimised data can be deanonimised by combining it with other data sets (which, by coincidence, Google also collects).
Repair manuals won't help with mobile phones. They're rarely thrown away because of hardware issues. It's far more likely that they will be thrown away because they are no longer getting software updates. In the case of iOS and some Android devices, a locked bootloader prevents third parties from supporting them, in the case of most Android devices there's no financial incentive for longer-term support so no one does. For example, I have an old HTC Desire that still works fine. It's a bit underpowered, but still runs a lot of modern Android apps. Unfortunately, the last CyanogenMod build for it is based on Android 2.3, which includes an old TLS stack that only supports versions of the protocol and cypher suites that are now not supported by servers because of known vulnerabilities. This means that it can't connect to any HTTPS URL, for example. I can install F-Droid on it, but F-Droid can't fetch the repositories over HTTPS. I can side-load applications, and as long as they don't use TLS (or ship their own TLS implementation), they work fine. It probably has several other known vulnerabilities though.
At least with CRTs, replacing them with a modern LCD will cut the power consumption by a huge amount (20-50W, vs 100+W), so there's a good reason for using the newer technology. A 7-year-old Android phone is about as capable as a low-end budget phone now, yet became effectively unusable after about 4 years of life.
The problem is that Facebook T&Cs, as well as granting Facebook an almost unlimited license to anything you upload also includes a clause that you agree to indemnify them against this kind of claim. So, while you might be able to take Facebook to court and win if they took a video your friend uploaded of you and sold it, they would then be able to turn around immediately and sue your friend for whatever amount the court awarded you.
It's not natural to agree to a set of terms and conditions that explicitly grants a third party unlimited commercial rights to anything that you upload, upload some things, and then complain that you no longer have control over those things.
Presumably he read the bit of the Facebook T&Cs that says that you grant them a non-exclusive, sublicensable, transferable, commercial license to anything that you upload, and that you agree to indemnify them against any claims of copyright infringement. They are entirely at liberty to take anything that you upload and sell it and are not required to give you a cut (remember the Starbucks posters with pictures of people who had uploaded Facebook pictures from their shops?). The only surprising part is that Facebook didn't manage to get paid for this.
In my last flat, they installed a camera that watched the bus stop in front of my front door and managed to install it in such a way that it could probably see into the bedroom of a couple of flats in the row. One of my neighbours complained and they took it down immediately.
That sounds like a pretty good thing. Most of our leaders have been guilty of corruption, but it's hard to think of any that have suffered as a result.
Gartner are vigorously trying to shove it up Apple's arse) is that the smartphone market is really the Android market.
That's not really true. From the report, the iOS market is around 22% of the size of the Android market. That's a much higher ratio than the size of the Mac market to the Windows market has ever been. Even that doesn't tell the whole story, because a large part of the Android market is very low-end phones, with razor-thin margins for the manufacturer and very few app sales. This is important to the sort of people reading this kind of report, because they care about what the return on investment will be from supporting a given platform. It doesn't matter that Android completely dominates in the poorer parts of Africa, India, and China to the extent that iOS is a rounding error, it matters what phones the people with money to spend on your product have.
Why do people keep repeating this? People have been living on meat-free diets for centuries and even in the '60s it was shown that a sensible diet will provide the full range of nutrients that humans require.
You need to grow around 40 times as much plant matter to feed a food animal and turn it into meat than you need to produce the equivalent amount of nutritional value directly from plants. That said, part of the reason that we eat ruminants is that they can digest a lot of plant matter that we can't. Some land is suitable for growing grasses but nothing that humans can eat. The most efficient use of this land for providing food is to use it for feed crops (though much of it could also be used for biofuel these days).
All I can rely on from linked is junk mail.. Mikrosoptht u killed it.
That's been all you could rely on from LinkedIn for a long time before Microsoft bought it.
Unless he or his employer is willing to pay money to Facebook, and the amount that Facebook or, more likely, third-party resellers charge for this information is very cheap in comparison to the amount that it costs to hire a bad employee. What, you thought 'private' meant that Facebook wouldn't sell it to anyone who asks? You've obviously not read the Facebook privacy policy.
You are entirely correct, even though I absolutely hate how true it is. Most of getting (and much of maintaining) a job is about how much people like you, not about your competence
I disagree. When hiring, you have a limited amount of knowledge to make a decision that can be incredibly costly if you get it wrong (Joel on Software has a good article about the costs of hiring a bad employee vs the costs of hiring no one). A CV is easy to doctor (and unscrupulous recruitment agencies do this a lot). An in-person interview gives very little information for selection (though inability to answer basic technical questions provides good deselection information). If one of your employees has worked with a candidate before and can attest to the fact that they're competent, then that's an incredibly valuable piece of information. This is why your professional network matters: it's not about how much people like you, it's about whether people respect your ability enough to want to work with you again.
The same thing happens on Windows. For example, last year there was an arbitrary code execution vulnerability in the code that Norton Antivirus uses to scan images. For some idiotic reason, they were running this code with kernel privilege. It ran whenever an image file was written to disk, so it could be exploited by simply receiving an email attachment in a spam, which your antivirus would then scan and run the exploit, even if you never opened the file.
IoT devices are, by definition, running a network stack. That brings you into the 32KB of RAM requirement as a minimum. The requirements for JavaScript are pretty small relative to that.
I love MIPS assembly.
Really? Branch delay slots (with 'unpredictable' behaviour if you put a branch in them), no complex addressing modes, weird instruction names (an unsigned add is the same as a signed add, except one will trap on overflow, because that's obviously what the difference between signed and unsigned means), special $hi and $lo registers because some instructions have an implicit destination. Half-arsed transition from a fixed-design pipeline so that some operations have hardware interlocks but some need some magic (and implementation-dependent) number of NOPs to work. Oh, and my favourite bit of MIPS, the superscalar NOP. When your ISA has a superscalar NOP, that's when you should realise that you've done something badly wrong.
In terms of programming, it's beautifully designed.
If you ever have to write ARM assembly, your head might explode if you think MIPS is beautifully designed.
The extension from 32-bit to 64-bit is pretty seamless.
The 'oh, by the way, if you don't sign-extend into the top 32 bits then you get undefined behaviour for any 32-bit arithmetic operation' thing is seamless? So any code that has to deal with 32-bit values ends up doing a left-shift by zero instruction (which makes the code totally readable - 'Hey, this looks like a nop, can we remove it?' 'no, it looks like a job, but we'll get garbage values if we remove it') at multiple points to enforce this invariant.
Even the MIPS instruction encoding is quite clean and the CPU design makes it easy for vendors to add their own interesting instructions to coprocessor 2. For example, my employer has a bunch of encryption and hashing related instructions added there. ARM does not allow you to add your own custom instructions to ARMv8, for example.
I'm guessing your employer is Cavium? Thank $DEITY that they're starting to produce decent ARMv8 chips and we can kill off support for their MIPS products in a few years. You might see this as a strength of MIPS, but to everyone else it's a massive weakness. Every MIPS vendor takes a version of GCC, hacks it up to support their extensions, and breaks support for other extensions in the meantime. They then can't get their patches upstreamed (the few that even try) and so their customers end up with an unmaintained dead-end fork. Worst ecosystem ever.
One advantage of the MIPS instruction is it very cleanly moved from 32-bits to 64 bits. With ARM that is not the case. AARCH64 is very different than 32-bit ARM.
I think that you and I have very different definitions of clean. MIPS quickly hacked on a 64-bit extension without thinking it through, AArch64 was the result of careful study of the intersection between code sequences that compilers like to generate and instructions that are efficient to implement. For example, a lot of the predication (really useful for assembly programmers, hard to implement in superscalar pipelines, hard to use for compilers) is gone, the user-addressable PC is gone (makes branch-prediction really hard on in-order pipelines) and so is store/load multiple (basically needs microcode). You keep all of the really useful bitfield manipulation instructions (no MIPS equivalent, and oh how I miss them when I have to deal with MIPS, which sadly I do on a regular basis), store and load pairs (including atomics on pairs) and so on.
Oh, and MIPSr6 is not backwards binary compatible with previous versions. All of the branch-likely opcodes were recycled as compact branch (no delay slot), you you need to patch your binaries if you want them to work.
Most of the Android runtime is written in C++, as is most of Apple's Objective-C runtime. Microsoft had a project to turn Singularity into a product (which, sadly, was cancelled before completion) where the implemented their entire .NET runtime and OS in C#. The Jikes RVM is written mostly in Java - specifically, the JIT compiler and garbage collector are both Java. The Squeak Smalltalk VM (and descendants such as Pharo) are written in Smalltalk, with a small core that is statically compiled and the rest then running on this bootstrap subset.