You can buy a YubiKey to do this today without any finicking with a Raspberry Pi. There are a few modes depending on the devices you buy. First is what you say -- it can emulate a keyboard, and input a password for you whenever you press a button on the device. It can also perform HOTP/TOTP authentication, and some of them can act as a legitimate security token that integrates with your platform's crypto.
I think the point is that important figures could have several "dummy" lasers present at all times to fool the bullet into going elsewhere. It would act similar to any other frequency jammer.
Stack Overflow reputation indicates that you're a 1337 documentation writer, not necessarily that you know how to program.
SO reputation indicates a number of things -- that you can understand and dissect problems and code from others, that you have intimate knowledge of the platforms you're answering about, that you can code reasonably well, and that you can communicate well.
Basically, someone with a high rep is very likely to be enthusiastic, knowledgable, and great to work with. Does this mean Jon Skeet can out-code an elite like John Carmack? No. Does it mean he's a good coder? Probably. One of the "top" programmers? Not enough data.
This whole article is a bit of a bonkers idea. What makes a good dev? Is it the ability to work quickly, elegantly, and robustly? Being able to pull innovative algorithms out of thin air? Is it the ability to hack together important, complicated projects even if the code itself is a mess? How about less direct things, like overall contribution to the dev community and enthusiasm for helping other people grow?
Non-competes are BS. But requiring employees to not reveal confidential information, poach clients, etc. for their new competing bosses seems like a reasonable and ethical thing to ask. It sounds like Amazon believes he may have crossed this line, beyond simply working for a competitor.
I own a HDHomeRun, and it was a bitch to set up because even Comcast customer support had never heard of it (at one point, they told me to call TiVo!)
When was the last time you did this?
I've had a HDHomeRun Prime for about three years now, and have never had an issue with Comcast's CableCard activation line. The other side of the call is seated by a weird androgynously-voiced Indian following a script, but I've never been on the phone more than about 5 minutes before my card was working.
I have no idea if Google's language is one that I'd want to use, but I do know that Javascript is by no means a good choice to develop large-scale web apps with. Unfortunately, it's currently the only choice we've got. Given that the ecosystem is far more open to change lately, it seems like as good a time as any to replace it.
I think the best way we could handle it is to create a standard high-level bytecode and package format. Then any number of languages could be translated to it easily and efficiently.
I'm hardly counting ARM out. I doubt Intel will ever try to apply themselves to all the areas ARM is in. For phones and tablets, though? There is no doubt that ARM will have some very serious competition in the near.
I realize we like to root for the underdog here, but realistically, Intel's got a leg up in the long run.
ARM has already had its 15 minutes, just like AMD's Athlon did.
There's a good possibility that Intel will wipe the floor with all the ARM offerings. Maybe not with this generation of CPUs, maybe not the one following it, but they've got the best fab in the world and extremely smart people using it.
They've been actively focusing on increasing power efficiency for a number of years now, so I have no doubt they'll be able to bring strong competition.
It's time for the principal vendors to rebuild the list of assumptions of what gpus can and should be doing, design an api around that, and build hardware specific drivers accordingly.
For the most part, they've done that. In OpenGL 3.0, all the fixed-function stuff was deprecated. In 3.1, it was removed. That was a long, long time ago.
In recent times, while AMD introduced the Mantle API and Microsoft announces vague plans for DX12, both with goals of reducing CPU overhead as much as possible, OpenGL already has significant low-overhead support.
Why don't we ever read about more useful metrics, such as the amount of (floating-point) operations per second per $ of a given CPU?
Because most people don't care about these things anymore. Take this from TFS:
Haswell may have delivered impressive gains in mobile, but it failed to impress on the desktop where it was only slightly faster than the chip it replaced.
In reality, Haswell had double the FLOPs thanks to the new FMA instructions, near double the integer throughput thanks to AVX2, and a significant boost to multithreaded code thanks to TSX.
In practice, people saw maybe a 10% speedup in what they actually do. A flops/$ metric would significantly inflate the actual value people would see from these CPUs.
The thing is, these measurements are either synthetic (who has code consisting of nothing but FMA?), hard and uncommon to use (Integer SIMD is rare and AVX2 has a confusing idea of "lanes" that splits some 256-bit ops into two 128-bit ones), or not on all CPUs (TSX is disabled on their unlocked K line for some reason).
In x86, for instance, the majority of instructions affect global flag registers. You can have two instructions that operate on entirely different memory locations and GP registers, but when you swap them the flags will end up set differently.
You'll find very few instruction pairs that you can do this to without some ability to perform local analysis of the code.
I thought it was roughly comparable to AVC baseline, though I admit not AVC main.
You're right, I'm not sure why I said ASP. The difference in quality between AVC Baseline and High is still pretty immense though -- lack of proper B-frames is pretty significant just by itself
Do you disagree with Google's course of action? If so, what should Google have done instead to keep webmasters from having to pay royalties on the videos they show to users of desktop computers and Android mobile devices?
As someone who loves technology, I'd have loved to see us come to some understanding with MPEG LA to just license their stuff for all HTML5 use. VP8 is going to result in either a lot more bandwidth usage (at YouTube levels, quite an impressive lot more) or a lot less quality.
As someone who loves freedom and creativity, I'm happy that we have anything and I'm thankful for Google doing whatever undisclosed thing they did to release VP8 from patent shackles. I do disagree very much with their methods of stirring up so much support with flat out lies -- if they hadn't gone through with licensing it, there'd have been a lot of wasted work and potentially even people in legal trouble for using the format. It was very shady.
One worry I have is that the internet will become a bit like American broadcast TV. We're still sending the hugely inefficient MPEG2 over the air. A sort of "moving standard" agreement with MPEG LA would be pretty awesome -- do we want to still be using VP9 as anything but a legacy-supported format in ten years? twenty? The moment we want to jump on a new codec, or say we just continue to develop VP9 into VP10, It's all but guaranteed some of the next-gen techniques will already have been patented.
I've developed Windows drivers before and can say that while yes, it is just plain C or a subset of C++, the APIs are entirely new and come with various curveballs user-mode devs will not have ever dealt with like keeping track of what IRQ level you're at.
A simple driver is... well, fairly simple. Once you try to do anything interesting though, there's a lot to learn before you can be useful. I'm curious if Linux is any different.
VP8 is a royalty-free video codec whose rate/distortion performance is in the same league as the royalty-bearing MPEG-4 AVC.
VP8 is not in the same league as AVC. Technologically it is largely a subset of AVC with quality somewhere between ASP and AVC. It is royalty-free now, but it wasn't always. When Google announced VP8 as a grand royalty-free codec, it was actually very obviously encumbered by patents that Google had no rights to and unfortunately thus offered literally no benefits.
It was only a year ago that Google and MPEG LA settled the issue, with Google getting a full license to those patents and the ability to sub-license to anyone they want.
What you have is Google very targetedly marketing VP8 to web devs as a Free/Open/Next-Gen to have them jump on a bandwagon to "splinter the internet". It was only thanks to Google's mammoth weight being able to negotiate with MPEG LA that all the traction it gained wasn't for naught.
It's really hard to believe Cisco did not know about this. They were either cooperating (even if just by turning a blind eye) or incredibly incompetent. As you say, it will indeed be very difficult for them to gain anyone's trust.
It would probably take them all but 5 minutes to have one of their Chinese employees dump the firmware and compare the checksums to known vanilla sources. I can't believe a large company wouldn't have this as part of their regular process.
For the price they share, they should not break during normal use within a year.
Check out Beyerdynamic's Pro line. They look good and are built like a tank. The Beyerdynamic DT770 Pro are around $150-200, comfortable for long use, have an excellent sound signature, good isolation, and can pump out an enormous, gorgeously detailed bass if your music asks them for it.
I assume they'll not be making this extra content Open Source, and perhaps have official servers which any old compiler will not be able to connect to.
The greater benefit here is that there will be a very public log of what it takes to make an AAA title. A super in-depth tutorial for all those devs who might want to license it.
Unlike other languages where you use what comes with your IDE, with C/C++ you are encouraged to find and use reusable libraries.
Encouraged is a funny word, seeing as there's no other choice... but that's beside the point.
Having to dig out multiple libraries to make any non-trivial project is a pain. Having to worry about TinyXML's lack of standards compliance and proneness to buffer overruns (in an older version at least, not sure if it's still there), gsoap's godawful API, wrapping libpng's setjmp/longjmp error handling in exceptions, wrapping libcurl with RAII objects, or XYZ's exception safety, etc.
There's something nice to be said about having a very cohesive set of libraries by default. Same level of quality, same familiar style, same level of documentation, same integration with the rest of the library and language. C++ getting these things would not force you to use them, it would simply let devs bootstrap their apps a lot quicker, and far more robustly.
The C++ standard library is probably the highest quality standard library of any language I've seen.
It is documented down to an very low level. I can't count the number of time I've been using some.NET library only to find out that it has some undocumented requirement, quirk, or wildly unexpected time complexity. You never get things like that in the C++ standard library -- assuming you've read the documentation thoroughly, you should never be surprised.
The standard library takes full advantage of the language, and it's as lean as ever with the "don't pay for what you don't use" mantra generally remaining in full effect.
A downside? I may be able to develop something that uses a tenth the RAM and half the CPU in C++, but despite the strengths mentioned above, it's going to take me at least twice as long and I'm going to need to juggle a number of inconsistent 3rd party libraries -- no doubt some of them being plain C so I'll need to make some RAII wrappers, etc. -- it remains incredibly low-level.
Boost picks up some of the slack, but C++ really needs more of the things commonly used today. Things like HTTP, XML, web services, SQL, configuration, and cryptography should be built in, but they're only just now looking at a simple sockets library. This is a huge weakness. C++ is used in a lot of low-level situations so I don't know if these should be part of the standard library proper, but at the minimum an additional "framework" standard that implements high-level stuff for the more common unconstrained users would be immensely useful.
The language itself is very strong, and C++14 cements even more useful things into it. The only things I wish they'd add is LINQ and async functionality similar to C#.
If Theo had a more constructive outlook, this would go a lot different and we'd all benefit.
Instead of screaming vitriol at someone's app architecture inadvertently defeating his platform-specific feature, he should be asking why they felt the need to go with that architecture (hint: it was a perfectly reasonable need), and perhaps if he can do something to make integrating his security feature easier for that type of architecture.
Like you say, freelists are an extremely common design choice when performance is critical. This security feature could be hugely beneficial to many apps that use them (like, say, Apache HTTPd). Instead you've got the too-common case of an unbending programmer mad at someone for having needs other than his own.
Otherwise known as "the only sane way to simulate exceptions in C". Seriously. Read up on how "goto" is used in low-level code bases such as OS kernels, instead of citing some vague memory of a 1960s paper without understanding its criticisms.
People who don't use goto for error handling in C more often than not either have incorrect error handling or way too much error-prone duplication of resource cleanup code. It makes sense to very strictly warn newbies away from goto, much in the same sense that you warn them from multithreading. You don't want them used as a universal hammer for every nail in the code. At some point though, people need to jump off the bandwagon and learn to respect, not fear, these things that actually have some very compelling uses.
Unless a programmer is working for a very large company, there's a good chance they're in pretty direct contact with their users.
Throwing someone into contact with users doesn't help someone become good at UX. Just look at the multitude of Open Source projects -- most of them interact directly with users and still end up with pretty atrocious UX that is designed based on the programmer's workflow and how easy it is to implement.
You did something wrong. You need to do step A, B, C, and you skipped over B!
Every time I hear this from a developer, I cringe. Good UX is a choice. You can train in it, but until you really alter your mindset towards user interaction and embrace it, your projects will suffer. It's so easy, too:
A user is having difficulty performing X. Is there something I can change to ensure they land on an optimal path next time?
Slashdot Mirror
Meanwhile, the bank will take anything.
Really? I'm so used to "6-8 characters, no symbols, etc.". You'd think these things would be regulated.
You can buy a YubiKey to do this today without any finicking with a Raspberry Pi. There are a few modes depending on the devices you buy. First is what you say -- it can emulate a keyboard, and input a password for you whenever you press a button on the device. It can also perform HOTP/TOTP authentication, and some of them can act as a legitimate security token that integrates with your platform's crypto.
I think the point is that important figures could have several "dummy" lasers present at all times to fool the bullet into going elsewhere. It would act similar to any other frequency jammer.
Stack Overflow reputation indicates that you're a 1337 documentation writer, not necessarily that you know how to program.
SO reputation indicates a number of things -- that you can understand and dissect problems and code from others, that you have intimate knowledge of the platforms you're answering about, that you can code reasonably well, and that you can communicate well.
Basically, someone with a high rep is very likely to be enthusiastic, knowledgable, and great to work with. Does this mean Jon Skeet can out-code an elite like John Carmack? No. Does it mean he's a good coder? Probably. One of the "top" programmers? Not enough data.
This whole article is a bit of a bonkers idea. What makes a good dev? Is it the ability to work quickly, elegantly, and robustly? Being able to pull innovative algorithms out of thin air? Is it the ability to hack together important, complicated projects even if the code itself is a mess? How about less direct things, like overall contribution to the dev community and enthusiasm for helping other people grow?
Non-competes are BS. But requiring employees to not reveal confidential information, poach clients, etc. for their new competing bosses seems like a reasonable and ethical thing to ask. It sounds like Amazon believes he may have crossed this line, beyond simply working for a competitor.
I own a HDHomeRun, and it was a bitch to set up because even Comcast customer support had never heard of it (at one point, they told me to call TiVo!)
When was the last time you did this?
I've had a HDHomeRun Prime for about three years now, and have never had an issue with Comcast's CableCard activation line. The other side of the call is seated by a weird androgynously-voiced Indian following a script, but I've never been on the phone more than about 5 minutes before my card was working.
But some say he is less hands-on in developing products than his predecessor.
The best leaders will see their own shortcomings and delegate to trusted experts to pick up their slack. Perhaps this is Cook's strategy.
I have no idea if Google's language is one that I'd want to use, but I do know that Javascript is by no means a good choice to develop large-scale web apps with. Unfortunately, it's currently the only choice we've got. Given that the ecosystem is far more open to change lately, it seems like as good a time as any to replace it.
I think the best way we could handle it is to create a standard high-level bytecode and package format. Then any number of languages could be translated to it easily and efficiently.
Instead of rational articles with headlines something like:
Insecure government process allows trivial unauthorized access to road infrastructure
We get ones focusing on how a game may have encouraged people to hack into the stuff. I don't think it'll ever end.
I'm hardly counting ARM out. I doubt Intel will ever try to apply themselves to all the areas ARM is in. For phones and tablets, though? There is no doubt that ARM will have some very serious competition in the near.
I realize we like to root for the underdog here, but realistically, Intel's got a leg up in the long run.
ARM has already had its 15 minutes, just like AMD's Athlon did.
There's a good possibility that Intel will wipe the floor with all the ARM offerings. Maybe not with this generation of CPUs, maybe not the one following it, but they've got the best fab in the world and extremely smart people using it.
They've been actively focusing on increasing power efficiency for a number of years now, so I have no doubt they'll be able to bring strong competition.
It's time for the principal vendors to rebuild the list of assumptions of what gpus can and should be doing, design an api around that, and build hardware specific drivers accordingly.
For the most part, they've done that. In OpenGL 3.0, all the fixed-function stuff was deprecated. In 3.1, it was removed. That was a long, long time ago.
In recent times, while AMD introduced the Mantle API and Microsoft announces vague plans for DX12, both with goals of reducing CPU overhead as much as possible, OpenGL already has significant low-overhead support.
Why don't we ever read about more useful metrics, such as the amount of (floating-point) operations per second per $ of a given CPU?
Because most people don't care about these things anymore. Take this from TFS:
Haswell may have delivered impressive gains in mobile, but it failed to impress on the desktop where it was only slightly faster than the chip it replaced.
In reality, Haswell had double the FLOPs thanks to the new FMA instructions, near double the integer throughput thanks to AVX2, and a significant boost to multithreaded code thanks to TSX.
In practice, people saw maybe a 10% speedup in what they actually do. A flops/$ metric would significantly inflate the actual value people would see from these CPUs.
The thing is, these measurements are either synthetic (who has code consisting of nothing but FMA?), hard and uncommon to use (Integer SIMD is rare and AVX2 has a confusing idea of "lanes" that splits some 256-bit ops into two 128-bit ones), or not on all CPUs (TSX is disabled on their unlocked K line for some reason).
That's a nice idea, but it won't work everywhere.
In x86, for instance, the majority of instructions affect global flag registers. You can have two instructions that operate on entirely different memory locations and GP registers, but when you swap them the flags will end up set differently.
You'll find very few instruction pairs that you can do this to without some ability to perform local analysis of the code.
I thought it was roughly comparable to AVC baseline, though I admit not AVC main.
You're right, I'm not sure why I said ASP. The difference in quality between AVC Baseline and High is still pretty immense though -- lack of proper B-frames is pretty significant just by itself
Do you disagree with Google's course of action? If so, what should Google have done instead to keep webmasters from having to pay royalties on the videos they show to users of desktop computers and Android mobile devices?
As someone who loves technology, I'd have loved to see us come to some understanding with MPEG LA to just license their stuff for all HTML5 use. VP8 is going to result in either a lot more bandwidth usage (at YouTube levels, quite an impressive lot more) or a lot less quality.
As someone who loves freedom and creativity, I'm happy that we have anything and I'm thankful for Google doing whatever undisclosed thing they did to release VP8 from patent shackles. I do disagree very much with their methods of stirring up so much support with flat out lies -- if they hadn't gone through with licensing it, there'd have been a lot of wasted work and potentially even people in legal trouble for using the format. It was very shady.
One worry I have is that the internet will become a bit like American broadcast TV. We're still sending the hugely inefficient MPEG2 over the air. A sort of "moving standard" agreement with MPEG LA would be pretty awesome -- do we want to still be using VP9 as anything but a legacy-supported format in ten years? twenty? The moment we want to jump on a new codec, or say we just continue to develop VP9 into VP10, It's all but guaranteed some of the next-gen techniques will already have been patented.
I've developed Windows drivers before and can say that while yes, it is just plain C or a subset of C++, the APIs are entirely new and come with various curveballs user-mode devs will not have ever dealt with like keeping track of what IRQ level you're at.
A simple driver is... well, fairly simple. Once you try to do anything interesting though, there's a lot to learn before you can be useful. I'm curious if Linux is any different.
VP8 is a royalty-free video codec whose rate/distortion performance is in the same league as the royalty-bearing MPEG-4 AVC.
VP8 is not in the same league as AVC. Technologically it is largely a subset of AVC with quality somewhere between ASP and AVC. It is royalty-free now, but it wasn't always. When Google announced VP8 as a grand royalty-free codec, it was actually very obviously encumbered by patents that Google had no rights to and unfortunately thus offered literally no benefits.
It was only a year ago that Google and MPEG LA settled the issue, with Google getting a full license to those patents and the ability to sub-license to anyone they want.
What you have is Google very targetedly marketing VP8 to web devs as a Free/Open/Next-Gen to have them jump on a bandwagon to "splinter the internet". It was only thanks to Google's mammoth weight being able to negotiate with MPEG LA that all the traction it gained wasn't for naught.
It's really hard to believe Cisco did not know about this. They were either cooperating (even if just by turning a blind eye) or incredibly incompetent. As you say, it will indeed be very difficult for them to gain anyone's trust.
It would probably take them all but 5 minutes to have one of their Chinese employees dump the firmware and compare the checksums to known vanilla sources. I can't believe a large company wouldn't have this as part of their regular process.
For the price they share, they should not break during normal use within a year.
Check out Beyerdynamic's Pro line. They look good and are built like a tank. The Beyerdynamic DT770 Pro are around $150-200, comfortable for long use, have an excellent sound signature, good isolation, and can pump out an enormous, gorgeously detailed bass if your music asks them for it.
I assume they'll not be making this extra content Open Source, and perhaps have official servers which any old compiler will not be able to connect to.
The greater benefit here is that there will be a very public log of what it takes to make an AAA title. A super in-depth tutorial for all those devs who might want to license it.
Unlike other languages where you use what comes with your IDE, with C/C++ you are encouraged to find and use reusable libraries.
Encouraged is a funny word, seeing as there's no other choice... but that's beside the point.
Having to dig out multiple libraries to make any non-trivial project is a pain. Having to worry about TinyXML's lack of standards compliance and proneness to buffer overruns (in an older version at least, not sure if it's still there), gsoap's godawful API, wrapping libpng's setjmp/longjmp error handling in exceptions, wrapping libcurl with RAII objects, or XYZ's exception safety, etc.
There's something nice to be said about having a very cohesive set of libraries by default. Same level of quality, same familiar style, same level of documentation, same integration with the rest of the library and language. C++ getting these things would not force you to use them, it would simply let devs bootstrap their apps a lot quicker, and far more robustly.
The C++ standard library is probably the highest quality standard library of any language I've seen.
It is documented down to an very low level. I can't count the number of time I've been using some .NET library only to find out that it has some undocumented requirement, quirk, or wildly unexpected time complexity. You never get things like that in the C++ standard library -- assuming you've read the documentation thoroughly, you should never be surprised.
The standard library takes full advantage of the language, and it's as lean as ever with the "don't pay for what you don't use" mantra generally remaining in full effect.
A downside? I may be able to develop something that uses a tenth the RAM and half the CPU in C++, but despite the strengths mentioned above, it's going to take me at least twice as long and I'm going to need to juggle a number of inconsistent 3rd party libraries -- no doubt some of them being plain C so I'll need to make some RAII wrappers, etc. -- it remains incredibly low-level.
Boost picks up some of the slack, but C++ really needs more of the things commonly used today. Things like HTTP, XML, web services, SQL, configuration, and cryptography should be built in, but they're only just now looking at a simple sockets library. This is a huge weakness. C++ is used in a lot of low-level situations so I don't know if these should be part of the standard library proper, but at the minimum an additional "framework" standard that implements high-level stuff for the more common unconstrained users would be immensely useful.
The language itself is very strong, and C++14 cements even more useful things into it. The only things I wish they'd add is LINQ and async functionality similar to C#.
If Theo had a more constructive outlook, this would go a lot different and we'd all benefit.
Instead of screaming vitriol at someone's app architecture inadvertently defeating his platform-specific feature, he should be asking why they felt the need to go with that architecture (hint: it was a perfectly reasonable need), and perhaps if he can do something to make integrating his security feature easier for that type of architecture.
Like you say, freelists are an extremely common design choice when performance is critical. This security feature could be hugely beneficial to many apps that use them (like, say, Apache HTTPd). Instead you've got the too-common case of an unbending programmer mad at someone for having needs other than his own.
Otherwise known as "the only sane way to simulate exceptions in C". Seriously. Read up on how "goto" is used in low-level code bases such as OS kernels, instead of citing some vague memory of a 1960s paper without understanding its criticisms.
People who don't use goto for error handling in C more often than not either have incorrect error handling or way too much error-prone duplication of resource cleanup code. It makes sense to very strictly warn newbies away from goto, much in the same sense that you warn them from multithreading. You don't want them used as a universal hammer for every nail in the code. At some point though, people need to jump off the bandwagon and learn to respect, not fear, these things that actually have some very compelling uses.
Unless a programmer is working for a very large company, there's a good chance they're in pretty direct contact with their users.
Throwing someone into contact with users doesn't help someone become good at UX. Just look at the multitude of Open Source projects -- most of them interact directly with users and still end up with pretty atrocious UX that is designed based on the programmer's workflow and how easy it is to implement.
You did something wrong. You need to do step A, B, C, and you skipped over B!
Every time I hear this from a developer, I cringe. Good UX is a choice. You can train in it, but until you really alter your mindset towards user interaction and embrace it, your projects will suffer. It's so easy, too:
A user is having difficulty performing X. Is there something I can change to ensure they land on an optimal path next time?