eatfish
At this point that's more noise than signal. Not ideal for you but I can see the problem. For whatever reason you met the bar for requiring more validation. If they had let you in then another N'000 fake accounts would have also passed the automated system. Someone else would be posting here, Reddit or Twitter explaining how Facebook had let in some bot and was posting fake and untruthful stories, on the internet no less.
However, the touchbar...still a pointless gimick.
However the stress/weak points on the spacebar are quite different and you're more likely, as I did, to lift the entire butterfly mechanism out. You will not get this back in again. It's $700 to get the thing fixed at Apple but you can buy replacement keys for $100 per shot online.
Yes, instrumentation adds overhead. The absolute numbers cannot be used to determine peak performance but that's never the intention when profiling code.
Instrumentation rarely modifies the execution profile to the point that the numbers are 'worthless' or 'random'. My rule of thumb is that self times near the leaves of the callgraph are more accurate than self times further up the graph but having some indication of timing is important.
Furthermore with something like the call chart in AS3 you are often looking for outliers that you can't see when looking at an aggregated view of the profile. A function that has an average of 1000us might be running alternately at 500us and 1500us and you want to see that. It may indicate an unknown performance bottleneck, maybe a call to OpenGL is causing a GPU sync for some reason. It's rare that the instrumentation overhead would dominate major effects like that. Having a number available is important for this as you may be comparing invocations/looking at different parts of the graph at different zoom levels etc. Having a number available is the only solution.
Furthermore, where do you think the instrumented profiler is getting numbers from in the aggregated views? Answer: exactly the same place that the callchart gets it's numbers from. In essence you are saying all instrumented profilers are inaccurate and reporting bogus numbers, demonstrably untrue.
Patent trolls though. A different story. In 5 years we were sued twice (that I know of) by trolls. On both occasions the trolls had some trivial enhancement to a well known technique. I imagine they are operating a mud slinging operation where eventually something sticks. Once it does then either (1) the cost of licensing this 'new' tech is priced less than legal costs or (2) the troll is looking for testimony from some respected entity that the tech is innovative which gives them validation to go after the next biggest vendor up the chain.
A remote code exploit is as bad as a memory leak.
I posted these two: CVE-2013-1493 and CVE-2013-0809 in another reply. These 2 were memorable to me just because visiting a page (or a compromised page) would allow the exploit to proceed without any password/prompt/warning.
Maybe you could tell me why this one doesn't count though? http://technet.microsoft.com/en-us/security/bulletin/ms10-06...
This is just the first I found. Sorry I'm not being awkward, I just don't work with CLR/Silverlight. What in your mind prevents this remote execution exploit from being serious? CVE denote it as a 9.3 and Microsoft claim it allows remote execution on a server too (under some circumstances).
After 20 years of Java we still don't have our perfect VM. It still sees critical security vulnerabilities. I don't think I'm picking on Java unfairly here. Java is a well written code base, it has plenty of unit tests, a proper code review process, a sound architecture. Pretty much all of these have been put forward as ideas that would 'cure' the OpenSSL project. Yet it doesn't seem to be a perfect cure. At some point no matter what your language, VM, OS is you are going to experience something similar.
In practice Rust's type checker accepts only a _very_ small subset of correct programs. I've been in a position to write some decent sized Rust code recently and it takes a shift in your mindset to start writing decent Rust code.
Even now there are patterns I'm unsure how to model in Rust. Arena allocation is a good example because it was partly the cause of Heartbleed too. Arena allocation in rust seems to require unsafe pointers and unsafe code blocks. You can look at Rust's standard library and see this.
2. The point being that the Rust language exposes unsafe code blocks and pointers. At some point you're going to hit those blocks (if nothing else in 3rd party code) and you're back to square one: You need to trust unsafe code that it is correct. It doesn't matter if that code is a VM or unsafe code.
*edited for some legibility.
The thing that really sets heartbleed apart is not the details of the bug, it's the scale of the 'infection'. OpenSSL is a core dependency of so many distributions and of so many pieces of software.
I think we could argue for lots of different solutions (diversity of implementations, safe languages, more tests) and all of them might be good in one way or another but none of them are a silver bullet for any possible bug either.
I think the take away is that you need to in a position to upgrade any part of your software stack at a moment's notice not just the obvious top-level (e.g. Rails/Django/Jetty).
For the most part I failed to see that I -needed- unsafe code in some situations. Instead I was trying (failing) to annotate my code to ridiculous levels with lifetimes. It was really frustrating.
I don't think the current docs do a great job of putting unsafe in a suitable perspective. It's somewhat downplayed IMO.
Still, I've learned now and it's been pretty pleasant after that.
FWIW I've been doing c++ for maybe 18 years, writing device drivers, game engines, compiler development. I thought rust was made for me but it's been tough, much more so than any other language except maybe SML!
When the first iPhones were introduced it had the first affordable data plan I'd ever seen in the UK. I think o2 we're asking around £50/month for some tiny data plan on my Nokia N95, on top of the contract cost(there was no data bundles). The iPhone was £35 month on contract, phone and unlimited data.
Here's an article from Stanford law school: 'Are universities the new patent trolls?' http://papers.ssrn.com/sol3/papers.cfm?abstract_id=980776
Universities often (and unfairly IMHO) claim rights on graduate research precisely to monetize and act as patent gatekeepers.
I think this means the hashed passwords. Microsoft have had several vulnerabilities in this area. Just entering a password to browse a server caused Windows (prior to Vista) to store the LM hash. An LM hash can be reversed in a matter of seconds.