That's the most impressive part of the announcement, if you ask me. Their store page says that they have a "USB-C to USB-A adapter", which is nothing special, but also a "Micro USB-C to USB-A connecting cable".
I'm eager to hear when this new "Micro USB-C" connector will start appearing on Android phones and tablets.
If you think radio jamming should be legal, your issue isn't with the FCC, it's with US law, specifically 47 U.S.C. 333. Complain to Congress.
Despite that these and other jammers would have some beneficial uses, in my opinion it's a very good thing that radio jamming is illegal (with some exceptions for law enforcement and national security). Legalizing radio jamming in any form would cause far more problems than it would solve.
Lithium iron phosphate (LiFePO4) batteries are considerably more stable than lithium polymer and are not prone to thermal runaway.
They have somewhat lower energy density than lithium polymer, which is probably why they're not very common for phones, tablets, and laptops. They were used in the OLPC.
They are also somewhat common in RC cars and planes, in part due to their voltage (3.2V, so four series cells make 12.8V), and in part due to their higher possible discharge current.
TSX was disabled in Broadwell and early Haswell chips due to a bug. Do these new Broadwell-U have the TSX fix?
I have an experimental workload for which TSX would be very helpful, due to a need for atomic reads and writes of unaligned 10-byte data items. As far as I can determine, x86 provides no other way to guarantee atomicity of an unaligned 10-byte read or write.
Maruska seems to have made the first working violet LED. Some people claim that it doesn't qualify as a blue LED, but as far as I know there's no agreed-upon hard distinction between violet and blue. Maruska developed the right materials and process to make it, even if RCA pulled the plug before he had solved all of the problems necessary for commercialization.
The blue LED was invented by Herbert Paul Maruska at RCA in the early 1970s using Mg-doped GaN. A different one, using SiC, was invented at Cree in the late 1980s.
The 100 MHz Quark MCU is 32-bit. The dual-core Atom CPU is very likely 64-bit. There were some early Atom chips that had 64-bit disabled, but none of the recent ones have.
$49 only gets you the Edison module, which is useless by itself. You also need a base board of some kind. The Edison module with the Arduino-compatible base board shown in the photos will set you back $99. Still a pretty good price. 3x more expensive than a Raspberry Pi, but it is a lot more capable.
I'd get more excited about a 64-bit ARM embedded board, but those aren't available yet, other than a $6000 development board from ARM.
Not all of the code on GitHub is open source, but the majority is -- handy, when that means an account is free as in beer, too.
I'm not privy to any details of GitHub's finances or business model, but most likely it's a good thing that there are non-open-source projects using GitHub, because that's probably what's paying for the free open source use. I've recommended to several clients developing proprietary software the use of GitHub rather than running their own in-house repositories, because the interface is easier for them to use and they don't need as much in-house expertise to manage things. Because Git is distributed, they could of course do both, or easily transition away from GitHub later, and that's a selling point.
Somehow I fondly remember VMS running on HP hardware back in the 90s. A local university had a dialup guest account. It was fun. Going back to the DOS prompt after a finished session always made me hurt and long for something better than DOS.
"Somehow" is that you're hallucinating. VMS didn't run on any HP hardware until 2002. Prior to that it only ran on DEC and Compaq hardware.
nearly 30% of Americans either aren't digitally literate or don't trust the Internet
For that to be true, over 70% of Americans must be BOTH digitally literate AND trust the Internet, which is impossible since anyone who trusts the Internet is not digitally literate.
... and if I'd lost any files to this fiasco, I would henceforth absolutely REFUSE to use any computers that were accessible to SCCM, and I'd be trying to convince all of my colleagues to do the same.
They're adding "slow lanes", and moving services that don't pay up into the slow lanes.
The whole thing is nothing but greed. The ISPs at both ends are already being paid for the bandwidth, but the ISP at the consumer end wants to be paid for it twice, once by the consumer and once by Netflix.
Would you argue that if a Microsoft (or other vendor) SSL implementation was used by most of the world's web servers, this would have been less likely to happen? As far as I know, there's no reason to think that any other implementation, open or closed, would be any more immune to such problems. There is little or no evidence that closed source software is generally more reliable, or that substantial effort is made to audit it.
If you're arguing that it's bad that such a high percentage of the world's web servers use the same software, I might agree, but that is completely orthogonal to whether that software is open or closed.
That OpenSSL is open source is irrelevant. This bug could just as easily have happened in closed source software. Using closed source software does not give any higher confidence in the quality of the code; many studies (e.g., 2012 Coverity Scan Open Source Report) show generally comparable code quality, with some open source projects scoring substantially better than average.
Heartbleed is a perfect example of why software should be written in "safe" languages, which can protect against buffer overruns, rather than unsafe languages like C and C++.
Of course, the problem is that if you try to distribute open source software written in a safe language, everyone bitches and whines about how they don't have a compiler for that language, and how run time checking slows the software down by 10%. Personally I'd rather have more reliable software that ran 10% slower, than less reliable software that ran faster. It's also crazy to turn off the run-time checks "after the software is debugged", as if the debugging process ever succeeded in finding all the bugs. As C.A.R. Hoare famously observed in 1973, "What would we think of a sailing enthusiast who wears his lifejacket when training on dry land, but takes it off as soon as he goes to sea?"
The "with enough eyes" argument, and "if programmers were just more careful" arguments don't justify continued widespread use of unsafe languages. Granted, safe languages don't eliminate all bugs, but they eliminate or negate the exploit value of huge classes of bugs that are not just theoretical, but are being exploited all the time.
I keep hoping that after enough vulnerabilities based on buffer overruns, bad pointer arithmetic, etc. are reported, and cost people real money, that things will change, but if Heartbleed doesn't make a good enough case for that, I despair of it ever happening.
Given the low entry barrier as compared to traditional higher education systems, the surprise isn't the failure rate, but the success rate. Given the low cost per student of providing the course, even at a 1% success rate I expect that the cost per successful student is much better than the traditional systems, though I don't actually have numbers to back that up.
There are several algorithms using the binary number system, including left-to-right binary exponentiation, in Pingala's Chanda-sutra, before 200 BCE. Knuth's _The Art of Computer Programming, Volume 2: Seminumerical Algorithms_ cites B. Datta and A.N. Singh's 1935 _History of Hindu Mathematics 1_.
Also al-Kashi described the right-to-left binary exponentiation algorithm in 1427 CE.
Slashdot Mirror
That's the most impressive part of the announcement, if you ask me. Their store page says that they have a "USB-C to USB-A adapter", which is nothing special, but also a "Micro USB-C to USB-A connecting cable".
I'm eager to hear when this new "Micro USB-C" connector will start appearing on Android phones and tablets.
If you think radio jamming should be legal, your issue isn't with the FCC, it's with US law, specifically 47 U.S.C. 333. Complain to Congress.
Despite that these and other jammers would have some beneficial uses, in my opinion it's a very good thing that radio jamming is illegal (with some exceptions for law enforcement and national security). Legalizing radio jamming in any form would cause far more problems than it would solve.
Lithium iron phosphate (LiFePO4) batteries are considerably more stable than lithium polymer and are not prone to thermal runaway.
They have somewhat lower energy density than lithium polymer, which is probably why they're not very common for phones, tablets, and laptops. They were used in the OLPC.
They are also somewhat common in RC cars and planes, in part due to their voltage (3.2V, so four series cells make 12.8V), and in part due to their higher possible discharge current.
with their Fifth Generation Computer Systems initiative. They demonstrated that just throwing money at the problem doesn't solve it.
We need strong encryption for use by law-abiding citizens, and weak encryption for use by criminals.
TSX was disabled in Broadwell and early Haswell chips due to a bug. Do these new Broadwell-U have the TSX fix?
I have an experimental workload for which TSX would be very helpful, due to a need for atomic reads and writes of unaligned 10-byte data items. As far as I can determine, x86 provides no other way to guarantee atomicity of an unaligned 10-byte read or write.
Wrong. We've produced "...machines that exhibit the agency and awareness of..." a worm: http://www.smithsonianmag.com/...
Perhaps. IEEE Spectrum credits Maruska, as do several other histories of the subject.
http://spectrum.ieee.org/tech-...
Maruska seems to have made the first working violet LED. Some people claim that it doesn't qualify as a blue LED, but as far as I know there's no agreed-upon hard distinction between violet and blue. Maruska developed the right materials and process to make it, even if RCA pulled the plug before he had solved all of the problems necessary for commercialization.
The blue LED was invented by Herbert Paul Maruska at RCA in the early 1970s using Mg-doped GaN. A different one, using SiC, was invented at Cree in the late 1980s.
Yes, but good luck actually buying the A1100 reference board today. It's easy to offer a lower price on something you're not actually selling.
The 100 MHz Quark MCU is 32-bit. The dual-core Atom CPU is very likely 64-bit. There were some early Atom chips that had 64-bit disabled, but none of the recent ones have.
$49 only gets you the Edison module, which is useless by itself. You also need a base board of some kind. The Edison module with the Arduino-compatible base board shown in the photos will set you back $99. Still a pretty good price. 3x more expensive than a Raspberry Pi, but it is a lot more capable.
I'd get more excited about a 64-bit ARM embedded board, but those aren't available yet, other than a $6000 development board from ARM.
I'm not privy to any details of GitHub's finances or business model, but most likely it's a good thing that there are non-open-source projects using GitHub, because that's probably what's paying for the free open source use. I've recommended to several clients developing proprietary software the use of GitHub rather than running their own in-house repositories, because the interface is easier for them to use and they don't need as much in-house expertise to manage things. Because Git is distributed, they could of course do both, or easily transition away from GitHub later, and that's a selling point.
Somehow I fondly remember VMS running on HP hardware back in the 90s. A local university had a dialup guest account. It was fun. Going back to the DOS prompt after a finished session always made me hurt and long for something better than DOS.
"Somehow" is that you're hallucinating. VMS didn't run on any HP hardware until 2002. Prior to that it only ran on DEC and Compaq hardware.
Maybe even two, in case one gets broken!
For that to be true, over 70% of Americans must be BOTH digitally literate AND trust the Internet, which is impossible since anyone who trusts the Internet is not digitally literate.
Really? Ugh. I thought most modern file systems were consciously designed to avoid that sort of problem.
... and if I'd lost any files to this fiasco, I would henceforth absolutely REFUSE to use any computers that were accessible to SCCM, and I'd be trying to convince all of my colleagues to do the same.
They're adding "slow lanes", and moving services that don't pay up into the slow lanes.
The whole thing is nothing but greed. The ISPs at both ends are already being paid for the bandwidth, but the ISP at the consumer end wants to be paid for it twice, once by the consumer and once by Netflix.
Would you argue that if a Microsoft (or other vendor) SSL implementation was used by most of the world's web servers, this would have been less likely to happen? As far as I know, there's no reason to think that any other implementation, open or closed, would be any more immune to such problems. There is little or no evidence that closed source software is generally more reliable, or that substantial effort is made to audit it.
If you're arguing that it's bad that such a high percentage of the world's web servers use the same software, I might agree, but that is completely orthogonal to whether that software is open or closed.
That OpenSSL is open source is irrelevant. This bug could just as easily have happened in closed source software. Using closed source software does not give any higher confidence in the quality of the code; many studies (e.g., 2012 Coverity Scan Open Source Report) show generally comparable code quality, with some open source projects scoring substantially better than average.
Heartbleed is a perfect example of why software should be written in "safe" languages, which can protect against buffer overruns, rather than unsafe languages like C and C++.
Of course, the problem is that if you try to distribute open source software written in a safe language, everyone bitches and whines about how they don't have a compiler for that language, and how run time checking slows the software down by 10%. Personally I'd rather have more reliable software that ran 10% slower, than less reliable software that ran faster. It's also crazy to turn off the run-time checks "after the software is debugged", as if the debugging process ever succeeded in finding all the bugs. As C.A.R. Hoare famously observed in 1973, "What would we think of a sailing enthusiast who wears his lifejacket when training on dry land, but takes it off as soon as he goes to sea?"
The "with enough eyes" argument, and "if programmers were just more careful" arguments don't justify continued widespread use of unsafe languages. Granted, safe languages don't eliminate all bugs, but they eliminate or negate the exploit value of huge classes of bugs that are not just theoretical, but are being exploited all the time.
I keep hoping that after enough vulnerabilities based on buffer overruns, bad pointer arithmetic, etc. are reported, and cost people real money, that things will change, but if Heartbleed doesn't make a good enough case for that, I despair of it ever happening.
Given the low entry barrier as compared to traditional higher education systems, the surprise isn't the failure rate, but the success rate. Given the low cost per student of providing the course, even at a 1% success rate I expect that the cost per successful student is much better than the traditional systems, though I don't actually have numbers to back that up.
There's an existence proof that it can be done in four years, if someone is willing to devote sufficient resources to it.
There are several algorithms using the binary number system, including left-to-right binary exponentiation, in Pingala's Chanda-sutra, before 200 BCE. Knuth's _The Art of Computer Programming, Volume 2: Seminumerical Algorithms_ cites B. Datta and A.N. Singh's 1935 _History of Hindu Mathematics 1_. Also al-Kashi described the right-to-left binary exponentiation algorithm in 1427 CE.