mileswu

More info at: https://blogs.msdn.microsoft.com/tzink/2016/05/19/why-does-m...

I'm not sure if there are any alternatives that work any better over long distance. I suppose CERN also has CVMFS [1], which is a read-only caching filesystem that retrieves the files from upstream via HTTP. This works much better, but it is read-only so only satisfies certain use cases.

[1] http://cernvm.cern.ch/portal/filesystem

Unlike classical key distribution, these guarantees derive from fundamental physics laws as opposed to, say, RSA that can be broken given enough computing power/time, and so are unbreakable.

Unfortunately there can be flaws in actual implementations of the BB84 scheme, such as side-channel attacks. E91 [1] (a newer scheme) addresses these flaws and prevents these attacks.

[1] http://journals.aps.org/prl/abstract/10.1103/PhysRevLett.67....

I've been tempted to try it, but can't really think why I'd need it.

[1] http://rowanj.github.io/gitx/ [2] http://jonas.nitro.dk/tig/

There are Python bindings to ROOT (pyROOT) but I've found Python in my experience to be a bit too slow when handling the large (10TB+) datasets.

As an aside, it's interesting how ROOT attempts to provide C++ with some basic reflection[2] and saving of C++ objects to dis. Unfortunately it doesn't necessarily do a very good job of it, but perhaps things will change with ROOT6 as it transitions to being based on clang, as opposed to in-house C interpreter.

[1] http://root.cern.ch/ [2] http://root.cern.ch/drupal/content/reflex

It was submitted to HN (https://news.ycombinator.com/item?id=7715881) by another user, but probably never got traction because the title of the article is very vague.

[1] http://jonas.nitro.dk/tig/ [2] http://rowanj.github.io/gitx/

Because we have so much data (of the order of 25+ PB of raw data per year; it actually balloons to much more than this due to copies in many slightly different formats) and so many users (several thousand physicists on LHC experiments) that's why we have hundreds of GRID sites across the world. The scheduler sends your jobs to sites where the data is located. The output can then be transferred back via various academic/research internet networks.

HEP also tends to invent many of its own 'large-scale computing' solutions. For example most sites tend to use Condor[1] as the batch system, dcache[2] as the distributed storage system, XRootD[3] as the file access protocol, GridFTP[4] as the file transfer protocol. I know there are some sites that use Lustre but it's pretty uncommon.

[1] http://research.cs.wisc.edu/htcondor/ [2] http://www.dcache.org/ [3] http://xrootd.slac.stanford.edu/ [4] http://www.globus.org/toolkit/docs/latest-stable/gridftp/

Well if you can't trust any hardware, how can the author trust any off-the-shelf computer and CPU to generate the private key even if he is using Linux+GPG? For all he could know the CPU could contain a backdoor that performs the necessary arithmetic and operations incorrectly (in the process making the key weaker).

He is also trusting his CPU to do the session encryption correctly (even with his external smartcard). Perhaps the CPU could leak information about the session key to another processes, allowing people to decrypt your communications?

Now I trust my CPU and hardware, especially because we have little alternatives. Perhaps it would be better to use an external smartcard to generate the private key too, because the physical hardware is orders of magnitude less complicated than a CPU/computer, so you could verify the hardware contains no backdoors by examining the physical circuits using a microscope (I presume this would still be very hard to do but millions of times simpler than that for a modern CPU).

These are just two examples that I came up with off the top of my head, but there are countless more. The advantage of VLC is that it's simple and just works out of the box for 95% of stuff, but MPC/Directshow gives you far more flexibility as you can construct a very custom filter chain (eg. using different decoders and renderers).

[1] http://forum.doom9.org/showthread.php?t=146228 [2] https://code.google.com/p/xy-vsfilter/

- Description talks about outrunning cops to deliver illegal goods, but there are no cops in the game

- AI opponents never move

- No collision detection

- Infinite speed in reverse gear

- Sometimes says you've won before you even left the start line

- The fifth (out of 5) map doesn't load and crashes the game

- A patch to fix the fifth map just turns it into the first map but mirrored (so I guess they couldn't work out how to fix it)

Weirdly somehow I think tens of thousands of copies of this were sold. I pity the people who wasted money on this.

[1] https://www.namecheap.com/ssl-certificates/comodo.aspx

[1] https://en.wikipedia.org/wiki/Pizza_theorem

I'm not sure why anyone would give money to a friend via Liberty Reserve, just because a friend requests some via an instant message. The average person has probably never heard of Liberty Reserve either. Before sending any money of any kind, wouldn't one ask the friend what's wrong whereupon it would become obvious it's not them?

Maybe I'm just deeply skeptical and distrusting and the rest of the world is more optimistic.

"For all of the above reasons, we require a license if you want to use the reddit brand in anything you do, both for free and for profit."[1]

[1] http://www.reddit.com/wiki/licensing

What really makes me convinced it is an experimental error is that CMS does not see the same mass discrepancy. If both independent experiments saw the same discrepancy then this would truly be really interesting new physics.

Disclaimer: I am on ATLAS myself, though not associated with the Higgs groups. I can only comment on public results due to much information being confidential.

This is very different to what the article is talking about, since it encrypts your passwords, but the article talks about hashing which is one-way.

[1] http://help.agilebits.com/1Password3/agile_keychain_design.h...

Not sure why he would have thought this would be possible. This would be an extremely hard problem given the latency involved between different nodes.

Then he came across VCL, or Virtual Open Cluster... “It did just what I wanted, not with an entire OS per se, but with an entire OpenCL application. and that’s good enough for me.”

A similar (but far older) system is MPI[1], which enables parallel computation across many compute nodes for your code by providing message passing. It's kind of a pain to use in my limited experience since you have to adapt your code (it seems like VCL is transparent for OpenCL programs), but it does work. No need for OpenCL, tho of course you could always use OpenCL + MPI. A common thing I see is MPI+OpenMP (for parallel cpu computation).

[1] https://en.wikipedia.org/wiki/Message_Passing_Interface