366 karma · joined March 14, 2012
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.
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.
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]
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).
I actually use OVH on some older Kimsufi plans. I'm kinda disappointed actually with these new plans as they got rid of the Core i5/i7 processors which were a bargain for the amount of CPU power you got for the money.
I think I read somewhere that they are upgrading the ESNet backbone to be 100Gbit/s and GEANT's[3] to be 1000 Gbit/s, so I wouldn't immediately write off University/academic networking as automatically inferior to Google's.
Honestly it's hard to tell without knowing any of the details of how much capacity Google is provisioning in Kansas City (and how much contention there is). How much backbone fiber is laid to KS/MO - it doesn't seem to be where existing big-scale connectivity is (unlike say, DC Metro area where a ton of datacenters are located or London/Paris/Amsterdam).
[1] http://www.es.net/ [2] http://www.internet2.edu/ [3] http://www.geant.net/pages/home.aspx
The datasets I run on tend to be several terabytes and all the clusters that I use utilize various distributed filesystems (eg. Lustre [1] or Dcache [2] or Xrootd [3]) to store these files across local storage on all the nodes of the cluster.
I think for big datasets some kind of support for these distributed filesystems will be necessary as most private (scientific) computing clusters use them. The complication is of course that to use these filesystems, one needs to build support for each access protocol into a python module (off the top of my head I'm not sure if they exist yet; perhaps they do). While most of these filesystems do offer standard posix 'mounting', this is usually not recommended for performance reasons.
Perhaps I'm outside of the intended use case anyway. To a certain extent this problem is solved for my field of research (of course nothing ever works all the time heh), as all LHC/OSG Computing Grid centers run the same Scientific Linux distribution with the theory being that any code that works on one should work on another.
But this sounds great for teaching classes and labs! I look forward to using it.
[1] http://wiki.lustre.org/index.php/Main_Page [2] http://www.dcache.org/ [3] http://xrootd.slac.stanford.edu/
Most universities tend to have their own computing cluster, which will make storing the (potentially large) datasets easier, and furthermore use of the CPU time is free!
Javascript ploting for the next set of graphs I need to produce for my research though is something I'm actually pondering about. It has the ability to be interactive which can be really helpful.