You forgot the stage light effect. Mysteriously Apple give a free fix/service program for the 13" models but not the 15" models. Kind of sucks if you had a 15" model that started to go bad.
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.
True, and I think Quarterdeck (and Pharlap, Rational, etc.) developed the VCPI specification that allowed those DOS extenders to work cooperatively. Some of the early DOS extenders took over the entire machine and did not allow that.
Around that time DOS programs were still being written to fit within 640KB of memory. However PC's were starting to be shipped with 2, 4 or even 8MB of RAM - memory really was a solution in search of a problem at that point. Windows 3.1 was the primary application for all that memory. But what if you didn't want, or need, to run Windows 3.1? Well that's where DESQview fit in. You could task switch between DOS programs instead using all that sweet memory (but not really, because DOS doesn't multitask, so 4 switchable ttys of DOS programs is a better description)
Vaguely related: there's Firecracker which boots in 125ms on x86 but that's as a VM, so it's an apples to oranges comparison. From what I recall Firecracker powers AWS Lambda so it's an interesting project in that respect too.
Not the OP and I wouldn't say I'm a fan but I've made some peace with it by putting a membrane cover over the top and so far: (a) not one dust related casualty in the past 18 months and (b) it subdues the clackety-clack of the keys into something that's actually quite pleasant.
I expect they correlated logs from several sources, maybe the guy connected via ssh to Apple's servers at the same time his mac accessed software update or something. If he sent all traffic down the VPN it'd show the same IP address at Apple.
Don't do this to the space bar! I used the same trick as the video to fix/clean several keys out and had a pretty good feel for what I was doing.
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.
Only played with it a bit so far but it seems to me that the call and flame charts are now missing any timing information. Unless I've overlooked it you can't actually see how long a function takes to execute - defeats the purpose of instrumented profiling surely!
Actually, Nintendo were releasing 3D games even before the PS1. Starfox was the first poly 3D game from Nintendo and was released in 1992, at least a year, maybe more, before the PS1.
I think it would be a lot more palettable if Nim enforced one of those coding conventions per module, while letting users of that module reference it any way they liked. e.g. my team could exclusively use camelCase and the compiler enforced that in our modules, while the same code could be handed off to some other team that exclusively uses snake_case.
It is not other vendors that you need to be worried about. For example, when joining Khronos (OpenGL, GLES and others) you get royalty free permission to use any technology in Khronos' specifications and you, as a vendor, have to offer your tech to other Khronos members for free. I wasn't involved in the DirectX side of things but I imagine Microsoft operate a similar IP framework. There is no practical way to be a GPU vendor today and hoard your IP.
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.
Sorry, I'm not limiting the discussion to SSL vulnerabilities.
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.
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).
That is true, but I don't think this invalidates my central point that the rational response to heartbleed is to update your contigency plans. The irrational response is to plan the perfect world.
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.
1. I think a lot of people believe Rust will just type-check any old program and tell you when it has faults. So you can start with a bit of Ruby/C/Python, translate it to Rust and presto, all your bugs are exposed for the world to see.
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.