They don't need to be thrusting directly at the asteroid. Think 3 or more at angles, so they cancel each others' sideways thrust and the overall thrust misses the asteroid, whilst providing net 'away' thrust. Yes, this reduces efficiency.
Perhaps their mission involved pinpointing items of interest. This might be performed through a combination of range/bearing from current location, and that current location. If you want accuracy GPS is likely the way to go.
I'm TOTALLY speculating here, I've no idea what they were up to or the tech. they'd have been using.
This is why although my bank has a security token thing (it's actually a small Chip & PIN terminal requiring you have the card and know the PIN) it only ever requires this be used when you set up a new payee and the first time you send money to that payee. So outside of a bank customer setting up a new payee anyway and the returned codes being intercepted to set up a different payee quickly enough the best a trojan can do is see your account statements, transfer money between your own accounts and pay money to people you already expect to pay. Yes, this means they can fuck with you, but they can't usefully (to them) steal your money.
Oh, and now I think about it they couldn't usefully do the MITM either, as the input is partially based on the receiving account number or somesuch. So unless they bad guys have an account that matches sufficiently closely the authorisation codes are going to be useless to them.
They have big fat warnings up about how the thing will never be asked for simply for logging in (not that I expect that would stop some stupid people falling to a MITM attack).
TRIM is not really needed. In fact, it can be a liability performance-wise since it isn't a NCQ-capable command. All you really need to do is partition a fresh drive a bit smaller than its rated capacity and you get 95% of the benefit of TRIM without having to deal with it. If you have 120G SSD then create a 110G partition. Congratulations, you now have 95% of what TRIM would get you. It's funny how the rabble keeps screaming the TRIM mantra but it isn't that spectacular a feature.
So the SSD firmware knows about partitioning schemes and will make use of the 'unused' space as virtual blocks for the space you are using ?
The ssd is already a good value for the function of the boot drive - the place where you host the OS, applications and games. There is no need to approach terabyte territory to hold all this stuff.
Have you seen the size of modern game installs ? My Steam install (where most of my games are these days) is 99.2GiB (with individual games like Borderlands over 7GiB, and that's without DLC), and a current WoW install is ~25 GiB (I've still not fully patched up and the new streaming patcher says 1GiB to go with 23.4GiB already used... and it took over 35GiB to apply the 4.0.1 patch).
I'll agree that you don't need 'near terabyte' for games currently unless you buy every new release going. However most SSDs I found on a quick check at www.aria.co.uk were around 120GB for something not stupidly priced, and even those are still around £1.20/GB. A 160GB 7200rpm HDD from there is around 17.5p/GB. 120GB is not enough for me. Before upgrade to Win7 and a 1TB disk I was using a 120GB partition and I had to keep backing up games to my server so I could install new ones.
Until low enough cost/GB SSDs reach around the 500GB level of capacity I don't think they're a replacement for anything beyond a casual gamer.
ISP A Natting all their customers to 10.10.1.0/24 and ISP B Natting all their customers to 10.10.1.0/24, nobody from ISP A will be able to talk to ISB B unless they create an explicit bridge between themselves.
Errr, how do you figure that ?
ISP A client on 10.10.1.1 gets NAT'd to, let's say 184.108.40.206
ISP B client on 10.10.1.1 gets NAT'd to, let's say 220.127.116.11
Where's the problem ? Each NAT'd client is only going to see the already-NAT'd IP of the other.
But I agree NAT should not be considered a solution to this at all. It's a horrible hack to get around not being able to just give every ISP customer a big-enough IPv4 sub-net of their own. The MAC-based IPv6 addresses (or if you prefer the 'private' addresses, but they won't buy a home user much given they're still identified by a
Yes, you need to purchase each expansion up to and including the one you want to play. Buy WotLK now and get up to 80 so you're at least vaguely in place to start on Cataclysm when it's released. You even have time to get some semi-decent gear before the launch.
Yes, you can also still play all the vanilla content and all the TBC content. Some things may have been retuned a bit, and of course you may have no luck finding a raid for TBC content, but it's all still there (yes, this will change somewhat with respect to vanilla once Cataclysm launches, given how all the old world is changing... but you'll still be able to play the new versions of it with only a vanilla account).
If you know how to drive git you could try applying these:
- commit eefdca043e8391dcd719711716492063030b55ac:
x86-64, compat: Retruncate rax after ia32 syscall entry tracing
- commit 36d001c70d8a0144ac1d038f6876c484849a74de:
x86-64, compat: Test %rax for the syscall number, not %eax
there is a workaround of disabling 32bit binaries (I'd paste a link if Google Chrome dev channel would let me... for some reason I can only paste into
There's also a separate issue that also gives local root, fixed by:
- commit c41d68a513c71e35a14f66d71782d27a79a81ea6:
compat: Make compat_alloc_user_space() incorporate the access_ok()
I'm running a kernel base don 18.104.22.168 but with all 3 of those commits applied (note the last one tries to modify an arch/tile/ file which doesn't exist in 22.214.171.124, just ignore that) and can confirm that neither exploit works.
Hmmm, I guess we cross our fingers that they'll release a formal specification for all the bits that count so others can reimplement it if they choose?
I have no opinion language-wise for this really, but running on a basic LAMP stack, at least with the A being Apache is a must . I could swallow the megabytes of Ruby gems if needs be, but only if sufficient versions are available in Debian stable. As a sysadmin I do not need any extra headache of trying to keep lots of tiny little packages up to date myself (disclaimer, never touched/adminned Ruby so far... for all I know it has some nice way of doing this...).
*checks the git repository quickly* Ah yes, Debian packaging for Diaspora itself would be nice too.