Well since you are clearly a network security expert, please tell us how to secure a network against being taken out be a DDoS attack. Then post your IP, we'll see how you fair. Remember, you are the asshole and deserve Legal Penalties with Scary Caps if you can't stop it.
Here's a hint: There is no security against a DDoS attack. That's why assholes like Lizard Squad use them.
If the idea is to import the best of the best, well then the pay needs to be for that. You can't say you are after the best anything and then offer even average wages. The best can command high pay.
Now if that's not the idea, that's fair too, but stop trying to bullshit us about it. None of this "We only want the best but we want to bay substandard wages!" crap.
The same could be said for flying car science.
I'm 3D printing my flying car right now. It's just the printer is going to take thirty years to finish printing.
The artificial scarcity of money is the chief factor holding us back from a post-scarcity society. We don't have a production capacity problem.
Cool. Since we have unlimited production capacity, I want my own Death Star in five minutes. Thanks.
If NASA had used a 3D scanner to scan in an existing wrench, instead of designing a new one, then they could claim, in some rudimentary way, to have deployed the first instance of a star-trek style transporter.
Only if they destroyed the original wrench after they 'transported' it.
For the first time in nine years I got to see my youngest daughter on Christmas; this is the first Christmas in nine years she didn't have to work. Great Christmas present!
And the second to last pre-publication copies came Christmas eve eve. I finished going through it this morning, and the book itself is ready. What wasn't was the cover; I fixed it and ordered another copy, so Mars, Ho! should be online in a couple of weeks.
The base iPad Mini 2 lists at $299 and was as low as $229 during recent sales; the N1 is launching at $249.
And there are Commodore 64s on ebay for $50. This thing is clearly crazy overpriced.
But they can only do that if I've had my phone on since 2003.
What? It will happen automatically when I turn it back on? *sigh*
They just don't need the same kind of RAM as systems. Remember this is RAM, not the flash storage. That they have 32 and 64gb of.
As a practical matter all but a very few ARM processors are 32-bit and so can't address all that much memory anyhow without some kind of paging.
All drivers on OS X are already required to tell the operating system ahead of time that a device is about to DMA to memory. That's how that VT-d is able to configure the IOMMU hardware to allow those devices to access RAM without worrying about 64-bit address spaces. So the OS already knows precisely which pages of physical RAM should be accessible by PCIe devices using DMA. If other pages of RAM are accessible, that's a bug.
Similarly, making the Thunderbolt controller's IOMMU mappings be driven by that part of the kernel should not break any drivers at all, by definition, because PCIe devices shouldn't be issuing DMA requests except at driver-preapproved locations. So AFAIK, the only way such a fix could break any device would be if that device was trying to do something really dangerous, like reprogramming one of the PCI bus bridges, or reflashing the computer's EFI firmware....
I mean, I suppose that some drivers might be inadvertently configuring a mapping for a page of memory that also contains executable code or class instances (with function pointers), in which case fully fixing this would also require Apple to modify the IOMemoryDescriptor class to ensure that the DMA-enabled pages are whole pages owned by the descriptor, but that should still be pretty minor, and should result in only a modest amount of wired kernel memory bloat.
In the worst case, such a change might require a CPU-driven copy-on-prepare and/or copy-on-complete to work around drivers that provide their own virtual addresses for a memory descriptor that aren't page-aligned, which would cause a big performance hit for those few drivers, but I'd expect most driver developers to quickly fix those design mistakes to eliminate the performance hit. (And that's assuming this isn't done already—for some reason, I thought those buffers had to be page aligned or you'd get a panic, but I'm not seeing anything about it in the docs, so I might be remembering wrong.)
That seems more likely, but, when I was writing DMA code years ago, we put the buffers in non-cached RAM (and there were only written to from a driver in the kernel). Maybe explicit cache flushes are faster these days.
Ouch! Seriously bad. Worse than the Pentium FPU bug (and that's bad). What good is a computer if you can't rely on the data being committed back to disk because of corruption mid-flight in RAM?!
It apparently only happens if you read the same bytes from RAM 139,000 times in 64 milliseconds. If your program is doing that, you probably have a lot more to worry about than disk corruption.
If this was actually happening in the real world, computers would probably be crashing every few minutes.
No. These are standard instructions that many apps require to function correctly when using multiple threads.
Can you explain when you'd need to flush the cache when using multiple threads? You'd have to flush the cache back to RAM (isn't that a privileged instruction?), invalidate it, then read the data back from RAM. That's surely insanely slow compared to just using the CPU's internal cache coherency mechanisms?
This gives you a way to affect RAM outside of a sandbox.
Only if the sandbox lets you repeatedly access memory and flush the cache between accesses, and you happen to know where your data is in physical RAM.
Heesa left een Jar Jar?
PURGE COMPLETE.
