Usually, "epoxy" around the edges of a BGA chip is neither an anti-hacking attempt nor a light-proofing attempt. It's called underfill, and its chief purpose is to increase mechanical strength and make the bond more durable than tiny bare solder balls would be on their own.
Yes they are. Most multimedia processing is parallelizable, and thus benefits greatly from SIMD instructions - for example, just about every CPU-based video codec ever. If you want an actual example, I wrote a high-performance edge detection algorithm for laser tracing, with its convolution cores written in optimized in SSE2 assembly, and am hoping to write a NEON version. It'll never run reasonably on the original Raspberry Pi because it's too underpowered to do it without SIMD (I didn't even bother writing a plain C version of the cores, because honestly any platforms without SSE2 or NEON are going to be too slow to use anyway).
Obviously you can use SIMD instructions for a lot more, but multimedia is the obvious example. And as I mentioned, the Pi makes up for it for standard codecs only with its GPU blob decoder, but that doesn't help you with anything that isn't video decoding (e.g. filtering).
ESP8266 only became a "thing" last year, so the community is still growing. But the manufacturer is cooperating and is releasing open SDKs, and the hobbyist community is enthusiastic about it. I personally intend to use a bunch of them to automate things around my apartment, so I guess I'll find out just how good/bad it is.
That's for developing on the ESP8266 core itself - if you just want to use the default firmware, plug it into your existing microcontroller platform (e.g. Arduino) and you get wireless connectivity and a TCP/IP stack (running on the module) with some trivial AT commands. Not as cheap since you're still using a separate core as the main app host, but still a really cheap way to add WiFi to something.
There's a difference between established industrial designs where there is an argument for maintaining compatibility and an existing codebase, and hobbyists which can quite happily move up the chain and are always looking for cool new stuff in other respects. Even in product development, some companies go out of their way to use ridiculously outdated, expensive chips. That usually only flies when it's for non-consumer applications where they can afford to throw more money at a chip vendor to keep making outdated chips at outdated prices (which sometimes even rise); for consumer products the competition will undercut you by using newer, cheaper chips if you don't. For hobbyists, it actually pays off to upgrade - you get better toolchains (no need to deal with all the ROM/RAM/pointer type shenanigans of AVRs on ARM), better debuggability, etc. Of course, it doesn't mean you should jump onto any random chip - the toolchains and ecosystems vary wildly in quality - but it's a shame that so many people just stick with the old instead of trying something new.
There's nothing wrong with the Tiny series - little 6- and 8-pin chips are still the market where AVR/PIC make perfect sense, and I'll be the first to admit that I've used a PIC12F629 as a dual frequency generator in a project. But as a flexible platform for hobbyists, I'd much rather have a Cortex-M3 over an ATmega. Back when I was using PICs more often, my approach was to, every few years, re-evaluate my personal selection of PICs. I'd go through Microchip's (extensive) part database, look at the prices, and see if anything caught my eye, then order some samples. My 8-pin of choice used to be 12F508, then 12F629. For 18-pin I went from 16F84 to 16F88. 28-pin, 16F876 to 18F2520 and 18F2550 for USB. 40-pin, 16F877 to 18F4520 to 18F4550 for USB. I tried dsPIC at one point but didn't like it; by then ARM was picking up steam and it didn't make any sense. I haven't really looked at their line-up in a while, since I've mostly moved on to other chips for interesting stuff and stick to my old PICs for small quick/dirty hacks since I have a bunch in my drawers to get rid of, but you get the idea. It never made any sense to me to get stuck with one particular obsolete part or range.
Yup, all the other aliexpress pages I was looking at for the same phone said MTK6517, and I didn't notice that the one that I chose was different (I was just going for the lowest price, though the difference was a few bucks). Turned out to be the more accurate one it seems, since it matches the actual device that I have.
A7 is actually decent. It's low-end (as far as ARMv7 application processors go) but reasonably modern (late 2011, which isn't too bad). Nobody's asking for a bleeding-edge CPU in something like the Pi, but a 2002 vintage core wouldn't have made any sense.
TFA used to claim that it was still ARM11. They just edited it a few minutes ago. I stand transitively corrected.
I actually tried to look up any official announcements to corroborate the fact that it was still ARM11 before posting my first comment (because it just felt so dumb), but found none, no mentions of the new chip on Broadcom's site, nothing. I guess they trusted El Reg with the scoop and they screwed it up.
Whoops, you're right. Other pages claimed it was an MT6517, but I just checked/proc/cpuinfo. Still, A7 is still a modern core, 9 years newer than ARM11.
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 3
If you want to control a few motors and lights with network connectivity, get some ESP8266 modules - those are WiFi modules with a user-programmable 80MHz 32-bit CPU that you can buy for $5. Throw in a Cortex-M0 as a slave device to control your I/O (which can be as cheap as $1 in single quantities - yes, you can get a 32-bit CPU for $1 these days). That is what 2015 state-of-the-art silicon gets you to fit the task. A Raspberry Pi with a WiFi dongle is an order of magnitude more expensive and overpowered (and yet underpowered relative to what it claims to be, which is a Linux platform).
You're confusing low-end with outdated. An ARM Cortex-M3 or M4 board would be a low-end board suitable for tasks such as motor control, while being reasonably modern, and cheaper than the Raspberry Pi. An ARM Cortex-A5 or higher would be modern and suitable for running Linux. ARM11 isn't low-end, it's high-end and outdated.
Raspberry Pi suffers from exactly the same problem as the Arduino: both are based on an ancient, woefully outdated platform. Just because performance is "good enough" for whatever your idea of "good enough" is, doesn't mean it makes any sense whatsoever to stick to cores that are 10 years old or older. Moving up to moder modern designs give you more bang for the same buck, or less buck for the same bang. In the silicon industry it just makes no sense whatsoever to lag behind 3 generations for something like this. Newer designs are built in newer process nodes, scale to higher frequencies, and cost less to manufacture for the same performance. Being at the bleeding edge of silicon is expensive, but drop down a generation or so (relative to whatever field you're interested in) and that's the price/performance sweet spot. Using older stuff just doesn't make sense.
This keeps happening over and over and over again. When I started embedded programming, back when the PIC16C84 was released (the first microcontroller to feature EEPROM program memory, soon followed by the PIC16F84 Flash version), it stirred up a hobbyist revolution. No longer did you need expensive EPROM burners, UV erasers, and expensive UV-windowed chips with an erase cycle measured in minutes! And yet 5 years later people were still using the same damn PIC16F84, with its sole timer and just about no other features, when you could buy a PIC16F88 for 2/3 the price and get three timers, built-in analog-to-digital conversion, serial port/UART, SPI/SSP, PWM, analog comparator, built-in 8MHz oscillator, more RAM and Flash,... Why? Because PIC16F84 was popular and people were scared to use anything else, even if it is almost a drop-in replacement.
Then the Arduino happened, and even more people people joined what became called the maker movement. And us longtime PIC users rolled our eyes because we'd been doing it for years and we didn't need no steenking breakout boards for a trivial 8-bit chip, but hey, C compilers for PICs sucked, and AVR was a better architecture anyway, and so Arduino deservedly became popular. But then the silliness started to set in again: ARM came up with Cortex-M3 and Cortex-M0, and you could buy a 32-bit chip running at 4x the clock rate for the same price as the AVR in the Arduino, and yet even today people keep using AVR-based Arduinos when the microcontroller world has moved on. People are even sticking FPGA shields on an Arduino, which is like sticking a GTX970 on a Pentium MMX. You could implement the entire AVR inside that FPGA and run it faster than the real one sitting underneath. Why this madness? Because Arduino is popular and people are scared to move on.
And now with Raspberry Pi it's the same thing all over again. When the Pi came out it almost had a good excuse, because, even though its CPU was obsolete, and Broadcom's idea of making a powerful GPU chip and sticking an old CPU "on the side" was dumb, let's face it, nobody was building Linux-capable SBCs at that price point. But that's no longer the case, you can buy much more capable boards for the same $35 today. Why on earth would they release an updated model with an updated chip in 2015 that still uses the same damn architecture that is 12 years out of date? It just makes no sense, the only reason I can come up with is internal politics at Broadcom (trying to sell off outdated chips/designs for cheap, resistance from their GPU division to having a more powerful CPU in there, or something like that).
Phones come with a touchscreen, speakers, microphones, WiFi, Bluetooth, GSM, and an accelerometer, which also cost money. Probably more money than a few connectors on a board.
Well, the Chinese have managed to design a phone with a screen, dual radios, WiFi, Bluetooth, FM radio, and a dual core Cortex-A9 CPU that can be effectively sold for $40 or so (if you buy it in China, not online). If the Chinese can build in a CPU core that's two generations newer into a product with support for 3 radio standards and a screen that sells for $5 or so more than the Pi, why is Broadcom struggling with an outdated 12-year-old core on a product with no wireless?
You can buy a dual core Cortex-A9 Android phone in China for about $40, give or take. And that comes with a screen. Sorry, SoCs are dirt cheap these days and the price point isn't an excuse to ship a 12-year-old core (seriously, ARM11 came out in late 2002).
Why are they still shipping the same CPU core that was in the iPhone 2G? ARM is at least 3 generations ahead already. ARM11 doesn't have NEON (proper SIMD) instructions, so it's crap for multimedia processing (sure, they make it up for the usual codecs with their GPU core, but that doesn't help if you want to write your own code).
Seriously, when the Pi first came out one of my first complaints was that the CPU core was woefully outdated and I already owned several boards with much more recent ARM cores, and several years later they still haven't upgraded it? WTF? What sense does this make? Does Broadcom not have a license for more modern ARM cores? Are the licensing fees too high to ship it in a low-cost product? (Answer: no, plenty of Chinese SoC vendors are doing it). What's the issue?
Twitter measures tweets in characters, not in bytes. Japanese is not 2x denser than English in bytes, but it's 2x denser than English in characters, and that's what Twitter cares about.
Try writing a few tweets (or tweet-sized snippets) in English and in Japanese sometime, see for yourself.
140 characters isn't enough... in English. You should see the novels that Japanese people post on Twitter. Japanese is about 2x denser per character than English, so you can fit in a lot more stuff. I was amazed when I was able to compose an elaborate explanation for someone in Japanese and it still fit in one tweet (I'm learning the language).
SDKs are useful to investigate and develop homebrew exploits (they provide information on the system architecture), but they are not useful for actually developing homebrew unless you want to end up with a situation like the Xbox 1 (the original) where all homebrew (except for Linux) was basically illegal because compiling it meant using the SDK and the resulting binaries were not legally redistributable. As a counterexample, the Wii has a fully open source homebrew SDK (though some bits have a questionable history and are arguably non-cleanroom reverse-engineered SDK code from games, but that's a much finer point than outright using the official SDK).
Given what I've heard of the Xbox One security architecture, it's going to be a tough nut to crack, SDK or not.
Moving faster causes time to slow down (special relativity), but so does beeing in a deeper gravitational well (general relativity). As you move away from the Earth, both effects have opposite (but not equal) magnitude. I'm too lazy to do the math right now, but here's a walkthrough (for the case of GPS satellites, but the same equations hold; you just need to know the distance from Earth's center to Death Valley and to Mount Everest, and work out their linear velocity from that).
Um, no, x86 CPUs are nothing like ARM and I'm not aware of any commercial x86 CPU with an ARM backend. Yes, modern x86 cores use a RISC-ish microcode backend with an x86 decoder frontend, but that doesn't say anything in favor of ARM. All it means is that the industry has collectively agreed that CISC as a microarchitecture is a stupid idea - not necessarily as an instruction set.
I'm not a fan of x86 myself, and I think it's a stupid design with a vast amount of baggage causing a significant power/performance impact when designing an x86 CPU (that Intel can get away with because they're a generation or two ahead of everyone else in silicon tech), but then again ARM isn't the pinnacle of RISC either (though I do think it's better than x86).
Me, I'll take whatever microarch gets the best performance per watt at whatever TDP is relevant. If Intel can pull that off with x86-64, by all means. If ARM AArch64 ends up ahead, awesome. If both are about equal, I'll take whatever's more practical based on other factors.
And since this is a camera passthrough, not an optical overlay, that's a glaring implementation flaw. Properly aligning the head tracking framerate, camera framerate, and rendering would let them render the virtual objects in lockstep with the physical ones (at least at speeds where motion blur isn't a significant issue; you can fake that by minimizing motion blur in the real image by using a short shutter time on the cameras).
So, they're locking out things that can brick the card (flash ROM/fuses, screw up thermal sensors) and apparently a hint of OS security (the Falcons that respond to userspace commands can no longer access physical memory, only virtual memory). The latter sounds somewhat bizarre, considering the firmware should be fully under the control of the driver, not userspace (I guess/hope?), but not unreasonable. Maybe there are software security reasons for this.
Nouveau is free to continue using its own free blobs or to switch to nvidia's. If they start adding restrictions that actively cripple useful features or are DRM nonsense, then I would start complaining, but so far it sounds like an attempt at protecting the hardware while maintaining manufacturing flexibility for nvidia. This isn't much different from devices which are fused at the factory with thermal parameters and with some units disabled; the only difference is that here firmware is involved.
NV seem to be turning friendlier towards nouveau, so I'd give them the benefit of the doubt. If they wanted to be evil, they would've just required signed firmware for the card to function at all. The fact that they're bothering to have non-secure modes and are only locking out very specific features suggests they're actively trying to play nicely with open source software.
Not 2^16 (Unicode already has way over 2^16 codepoints assigned). The maximum Unicode codepoint value is 1114111, which is somewhat over 2^20 (and happens to be the highest codepoint encodable in UTF-16).
Now, it could be that their battery runs at a higher voltage (and thus not really 2Ah, but they're using that figure as a 3.7V li-ion equivalent capabity), or that there is a power converter built into the battery pack (unlikely for a prototype, though). Still, even for a 37V battery (vs. 3.7V for a normal Li-Ion cell), we're talking 24A. That cord didn't look like 24A cord, and I highly doubt they were using a voltage higher than 37V to charge (especially not with exposed banana jacks like that).
I call the demo highly dubious if not an outright fake/mock.
Sorry for the threadjack, but this is yet another case of horrible security reporting.
From watching the video, what it seems happened here was that eBay chose phpBB for their community forum, but did not integrate its authentication system directly with eBay's on the server side. Instead, the site was set-up as a standalone system, and whoever implemented the integration had the bright idea of hardcoding the forum password for everyone as username+123456, and then just having the eBay login page issue a hidden POST request behind the scenes to authenticate users to the community forum section.
Thus, this allows anyone to trivially impersonate anyone else on the forum. It shouldn't have anything to do with the rest of the site, though. Nor does this have anything to do with initial passwords, salts, or any of the other terms that have been thrown around.
A case of absolutely retarded login integration for the community site, but not something that would allow people to take over others' main eBay account. What this says about the people running eBay is another matter entirely...
Slashdot Mirror
Usually, "epoxy" around the edges of a BGA chip is neither an anti-hacking attempt nor a light-proofing attempt. It's called underfill, and its chief purpose is to increase mechanical strength and make the bond more durable than tiny bare solder balls would be on their own.
Yes they are. Most multimedia processing is parallelizable, and thus benefits greatly from SIMD instructions - for example, just about every CPU-based video codec ever. If you want an actual example, I wrote a high-performance edge detection algorithm for laser tracing, with its convolution cores written in optimized in SSE2 assembly, and am hoping to write a NEON version. It'll never run reasonably on the original Raspberry Pi because it's too underpowered to do it without SIMD (I didn't even bother writing a plain C version of the cores, because honestly any platforms without SSE2 or NEON are going to be too slow to use anyway).
Obviously you can use SIMD instructions for a lot more, but multimedia is the obvious example. And as I mentioned, the Pi makes up for it for standard codecs only with its GPU blob decoder, but that doesn't help you with anything that isn't video decoding (e.g. filtering).
ESP8266 only became a "thing" last year, so the community is still growing. But the manufacturer is cooperating and is releasing open SDKs, and the hobbyist community is enthusiastic about it. I personally intend to use a bunch of them to automate things around my apartment, so I guess I'll find out just how good/bad it is.
That's for developing on the ESP8266 core itself - if you just want to use the default firmware, plug it into your existing microcontroller platform (e.g. Arduino) and you get wireless connectivity and a TCP/IP stack (running on the module) with some trivial AT commands. Not as cheap since you're still using a separate core as the main app host, but still a really cheap way to add WiFi to something.
There's a difference between established industrial designs where there is an argument for maintaining compatibility and an existing codebase, and hobbyists which can quite happily move up the chain and are always looking for cool new stuff in other respects. Even in product development, some companies go out of their way to use ridiculously outdated, expensive chips. That usually only flies when it's for non-consumer applications where they can afford to throw more money at a chip vendor to keep making outdated chips at outdated prices (which sometimes even rise); for consumer products the competition will undercut you by using newer, cheaper chips if you don't. For hobbyists, it actually pays off to upgrade - you get better toolchains (no need to deal with all the ROM/RAM/pointer type shenanigans of AVRs on ARM), better debuggability, etc. Of course, it doesn't mean you should jump onto any random chip - the toolchains and ecosystems vary wildly in quality - but it's a shame that so many people just stick with the old instead of trying something new.
There's nothing wrong with the Tiny series - little 6- and 8-pin chips are still the market where AVR/PIC make perfect sense, and I'll be the first to admit that I've used a PIC12F629 as a dual frequency generator in a project. But as a flexible platform for hobbyists, I'd much rather have a Cortex-M3 over an ATmega. Back when I was using PICs more often, my approach was to, every few years, re-evaluate my personal selection of PICs. I'd go through Microchip's (extensive) part database, look at the prices, and see if anything caught my eye, then order some samples. My 8-pin of choice used to be 12F508, then 12F629. For 18-pin I went from 16F84 to 16F88. 28-pin, 16F876 to 18F2520 and 18F2550 for USB. 40-pin, 16F877 to 18F4520 to 18F4550 for USB. I tried dsPIC at one point but didn't like it; by then ARM was picking up steam and it didn't make any sense. I haven't really looked at their line-up in a while, since I've mostly moved on to other chips for interesting stuff and stick to my old PICs for small quick/dirty hacks since I have a bunch in my drawers to get rid of, but you get the idea. It never made any sense to me to get stuck with one particular obsolete part or range.
Yup, all the other aliexpress pages I was looking at for the same phone said MTK6517, and I didn't notice that the one that I chose was different (I was just going for the lowest price, though the difference was a few bucks). Turned out to be the more accurate one it seems, since it matches the actual device that I have.
A7 is actually decent. It's low-end (as far as ARMv7 application processors go) but reasonably modern (late 2011, which isn't too bad). Nobody's asking for a bleeding-edge CPU in something like the Pi, but a 2002 vintage core wouldn't have made any sense.
TFA used to claim that it was still ARM11. They just edited it a few minutes ago. I stand transitively corrected.
I actually tried to look up any official announcements to corroborate the fact that it was still ARM11 before posting my first comment (because it just felt so dumb), but found none, no mentions of the new chip on Broadcom's site, nothing. I guess they trusted El Reg with the scoop and they screwed it up.
It seems they just edited the article. It used to claim it was still ARM11.
Too bad Slashdot doesn't allow editing comments... oh well. I guess my first first post on /. will forever be a record of El Reg's poor reporting.
Whoops, you're right. Other pages claimed it was an MT6517, but I just checked /proc/cpuinfo. Still, A7 is still a modern core, 9 years newer than ARM11.
$ cat /proc/cpuinfo
Processor : ARMv7 Processor rev 3 (v7l)
processor : 0
BogoMIPS : 2589.52
processor : 1
BogoMIPS : 2589.52
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 3
Hardware : MT6572
(0xc07 means Cortex-A7)
If you want to control a few motors and lights with network connectivity, get some ESP8266 modules - those are WiFi modules with a user-programmable 80MHz 32-bit CPU that you can buy for $5. Throw in a Cortex-M0 as a slave device to control your I/O (which can be as cheap as $1 in single quantities - yes, you can get a 32-bit CPU for $1 these days). That is what 2015 state-of-the-art silicon gets you to fit the task. A Raspberry Pi with a WiFi dongle is an order of magnitude more expensive and overpowered (and yet underpowered relative to what it claims to be, which is a Linux platform).
You're confusing low-end with outdated. An ARM Cortex-M3 or M4 board would be a low-end board suitable for tasks such as motor control, while being reasonably modern, and cheaper than the Raspberry Pi. An ARM Cortex-A5 or higher would be modern and suitable for running Linux. ARM11 isn't low-end, it's high-end and outdated.
Raspberry Pi suffers from exactly the same problem as the Arduino: both are based on an ancient, woefully outdated platform. Just because performance is "good enough" for whatever your idea of "good enough" is, doesn't mean it makes any sense whatsoever to stick to cores that are 10 years old or older. Moving up to moder modern designs give you more bang for the same buck, or less buck for the same bang. In the silicon industry it just makes no sense whatsoever to lag behind 3 generations for something like this. Newer designs are built in newer process nodes, scale to higher frequencies, and cost less to manufacture for the same performance. Being at the bleeding edge of silicon is expensive, but drop down a generation or so (relative to whatever field you're interested in) and that's the price/performance sweet spot. Using older stuff just doesn't make sense.
This keeps happening over and over and over again. When I started embedded programming, back when the PIC16C84 was released (the first microcontroller to feature EEPROM program memory, soon followed by the PIC16F84 Flash version), it stirred up a hobbyist revolution. No longer did you need expensive EPROM burners, UV erasers, and expensive UV-windowed chips with an erase cycle measured in minutes! And yet 5 years later people were still using the same damn PIC16F84, with its sole timer and just about no other features, when you could buy a PIC16F88 for 2/3 the price and get three timers, built-in analog-to-digital conversion, serial port/UART, SPI/SSP, PWM, analog comparator, built-in 8MHz oscillator, more RAM and Flash, ... Why? Because PIC16F84 was popular and people were scared to use anything else, even if it is almost a drop-in replacement.
Then the Arduino happened, and even more people people joined what became called the maker movement. And us longtime PIC users rolled our eyes because we'd been doing it for years and we didn't need no steenking breakout boards for a trivial 8-bit chip, but hey, C compilers for PICs sucked, and AVR was a better architecture anyway, and so Arduino deservedly became popular. But then the silliness started to set in again: ARM came up with Cortex-M3 and Cortex-M0, and you could buy a 32-bit chip running at 4x the clock rate for the same price as the AVR in the Arduino, and yet even today people keep using AVR-based Arduinos when the microcontroller world has moved on. People are even sticking FPGA shields on an Arduino, which is like sticking a GTX970 on a Pentium MMX. You could implement the entire AVR inside that FPGA and run it faster than the real one sitting underneath. Why this madness? Because Arduino is popular and people are scared to move on.
And now with Raspberry Pi it's the same thing all over again. When the Pi came out it almost had a good excuse, because, even though its CPU was obsolete, and Broadcom's idea of making a powerful GPU chip and sticking an old CPU "on the side" was dumb, let's face it, nobody was building Linux-capable SBCs at that price point. But that's no longer the case, you can buy much more capable boards for the same $35 today. Why on earth would they release an updated model with an updated chip in 2015 that still uses the same damn architecture that is 12 years out of date? It just makes no sense, the only reason I can come up with is internal politics at Broadcom (trying to sell off outdated chips/designs for cheap, resistance from their GPU division to having a more powerful CPU in there, or something like that).
Phones come with a touchscreen, speakers, microphones, WiFi, Bluetooth, GSM, and an accelerometer, which also cost money. Probably more money than a few connectors on a board.
Android has an NDK to develop native apps that target the CPU instruction set directly. Unreal Engine for Android isn't written in Java.
Well, the Chinese have managed to design a phone with a screen, dual radios, WiFi, Bluetooth, FM radio, and a dual core Cortex-A9 CPU that can be effectively sold for $40 or so (if you buy it in China, not online). If the Chinese can build in a CPU core that's two generations newer into a product with support for 3 radio standards and a screen that sells for $5 or so more than the Pi, why is Broadcom struggling with an outdated 12-year-old core on a product with no wireless?
You can buy a dual core Cortex-A9 Android phone in China for about $40, give or take. And that comes with a screen. Sorry, SoCs are dirt cheap these days and the price point isn't an excuse to ship a 12-year-old core (seriously, ARM11 came out in late 2002).
Why are they still shipping the same CPU core that was in the iPhone 2G? ARM is at least 3 generations ahead already. ARM11 doesn't have NEON (proper SIMD) instructions, so it's crap for multimedia processing (sure, they make it up for the usual codecs with their GPU core, but that doesn't help if you want to write your own code).
Seriously, when the Pi first came out one of my first complaints was that the CPU core was woefully outdated and I already owned several boards with much more recent ARM cores, and several years later they still haven't upgraded it? WTF? What sense does this make? Does Broadcom not have a license for more modern ARM cores? Are the licensing fees too high to ship it in a low-cost product? (Answer: no, plenty of Chinese SoC vendors are doing it). What's the issue?
Twitter measures tweets in characters, not in bytes. Japanese is not 2x denser than English in bytes, but it's 2x denser than English in characters, and that's what Twitter cares about.
Try writing a few tweets (or tweet-sized snippets) in English and in Japanese sometime, see for yourself.
140 characters isn't enough ... in English. You should see the novels that Japanese people post on Twitter. Japanese is about 2x denser per character than English, so you can fit in a lot more stuff. I was amazed when I was able to compose an elaborate explanation for someone in Japanese and it still fit in one tweet (I'm learning the language).
SDKs are useful to investigate and develop homebrew exploits (they provide information on the system architecture), but they are not useful for actually developing homebrew unless you want to end up with a situation like the Xbox 1 (the original) where all homebrew (except for Linux) was basically illegal because compiling it meant using the SDK and the resulting binaries were not legally redistributable. As a counterexample, the Wii has a fully open source homebrew SDK (though some bits have a questionable history and are arguably non-cleanroom reverse-engineered SDK code from games, but that's a much finer point than outright using the official SDK).
Given what I've heard of the Xbox One security architecture, it's going to be a tough nut to crack, SDK or not.
Moving faster causes time to slow down (special relativity), but so does beeing in a deeper gravitational well (general relativity). As you move away from the Earth, both effects have opposite (but not equal) magnitude. I'm too lazy to do the math right now, but here's a walkthrough (for the case of GPS satellites, but the same equations hold; you just need to know the distance from Earth's center to Death Valley and to Mount Everest, and work out their linear velocity from that).
Um, no, x86 CPUs are nothing like ARM and I'm not aware of any commercial x86 CPU with an ARM backend. Yes, modern x86 cores use a RISC-ish microcode backend with an x86 decoder frontend, but that doesn't say anything in favor of ARM. All it means is that the industry has collectively agreed that CISC as a microarchitecture is a stupid idea - not necessarily as an instruction set.
I'm not a fan of x86 myself, and I think it's a stupid design with a vast amount of baggage causing a significant power/performance impact when designing an x86 CPU (that Intel can get away with because they're a generation or two ahead of everyone else in silicon tech), but then again ARM isn't the pinnacle of RISC either (though I do think it's better than x86).
Me, I'll take whatever microarch gets the best performance per watt at whatever TDP is relevant. If Intel can pull that off with x86-64, by all means. If ARM AArch64 ends up ahead, awesome. If both are about equal, I'll take whatever's more practical based on other factors.
And since this is a camera passthrough, not an optical overlay, that's a glaring implementation flaw. Properly aligning the head tracking framerate, camera framerate, and rendering would let them render the virtual objects in lockstep with the physical ones (at least at speeds where motion blur isn't a significant issue; you can fake that by minimizing motion blur in the real image by using a short shutter time on the cameras).
So, they're locking out things that can brick the card (flash ROM/fuses, screw up thermal sensors) and apparently a hint of OS security (the Falcons that respond to userspace commands can no longer access physical memory, only virtual memory). The latter sounds somewhat bizarre, considering the firmware should be fully under the control of the driver, not userspace (I guess/hope?), but not unreasonable. Maybe there are software security reasons for this.
Nouveau is free to continue using its own free blobs or to switch to nvidia's. If they start adding restrictions that actively cripple useful features or are DRM nonsense, then I would start complaining, but so far it sounds like an attempt at protecting the hardware while maintaining manufacturing flexibility for nvidia. This isn't much different from devices which are fused at the factory with thermal parameters and with some units disabled; the only difference is that here firmware is involved.
NV seem to be turning friendlier towards nouveau, so I'd give them the benefit of the doubt. If they wanted to be evil, they would've just required signed firmware for the card to function at all. The fact that they're bothering to have non-secure modes and are only locking out very specific features suggests they're actively trying to play nicely with open source software.
Not 2^16 (Unicode already has way over 2^16 codepoints assigned). The maximum Unicode codepoint value is 1114111, which is somewhat over 2^20 (and happens to be the highest codepoint encodable in UTF-16).
It's 2Ah, so 240A.
Now, it could be that their battery runs at a higher voltage (and thus not really 2Ah, but they're using that figure as a 3.7V li-ion equivalent capabity), or that there is a power converter built into the battery pack (unlikely for a prototype, though). Still, even for a 37V battery (vs. 3.7V for a normal Li-Ion cell), we're talking 24A. That cord didn't look like 24A cord, and I highly doubt they were using a voltage higher than 37V to charge (especially not with exposed banana jacks like that).
I call the demo highly dubious if not an outright fake/mock.
Sorry for the threadjack, but this is yet another case of horrible security reporting.
From watching the video, what it seems happened here was that eBay chose phpBB for their community forum, but did not integrate its authentication system directly with eBay's on the server side. Instead, the site was set-up as a standalone system, and whoever implemented the integration had the bright idea of hardcoding the forum password for everyone as username+123456, and then just having the eBay login page issue a hidden POST request behind the scenes to authenticate users to the community forum section.
Thus, this allows anyone to trivially impersonate anyone else on the forum. It shouldn't have anything to do with the rest of the site, though. Nor does this have anything to do with initial passwords, salts, or any of the other terms that have been thrown around.
A case of absolutely retarded login integration for the community site, but not something that would allow people to take over others' main eBay account. What this says about the people running eBay is another matter entirely...