Forwarding email with outlook.com/Office365/Microsoft Exchange also breaks DMARC. Exchange Server sometimes modifies the headers of emails when forwarding them, invalidating the DKIM signature, so then a DMARC policy rejects the forwarded email. Apparently Microsoft have a fix in the pipeline for this, but it's been taking ages.
CERN still uses AFS extensively for all users' files. I believe they use a forked version of OpenAFS. My experience with it at CERN has been okay. It's been fine to use locally, but transatlantic over the Internet can be very slow (it does work eventually though).
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.
Quantum Key distribution is different from classical ones in that it allows Alice and Bob to detect Eve. This is because a measurement in Quantum mechanics disturbs the state. In particular for BB84, a measurement by Eve in the wrong basis destroys the correlation of Alice and Bob in the correct basis.
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.
Author here. Been working on this on and off for about 3 years now as a side project and it's my first 'large-ish' OSX app. Would love comments or suggestions! Thanks.
Just an off-the-top-of-my-head idea: Could you give people a bookmarklet or an extension that they can run when they are on their order history page that exports all the Amazon product IDs?
This is very similar to another product that you can buy today https://www.adafruit.com/products/1652. It's basically an iPad 3/4 retina display that connects via DisplayPort. The main differences seem to be that the Kickstarter one will run off USB power (instead of 9V) and attaches to your laptop screen.
I've been tempted to try it, but can't really think why I'd need it.
I used to use it just for the ability to individually stage chunks/lines, because I find "git add -p" incredibly hard to use. Now I tend to use GitX-dev for OSX [1] to do that instead, because I find it more powerful than Github for Mac. There's also a ncurses-based interface for git called tig [2] which can also do the chunk staging, but I only use it when I don't have a GUI.
For high-energy experimental physics (HEP or particle physics), most tend to use a CERN developed C++ framework called ROOT[1]. It's not overly pleasant, but it gets the job done.
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.
There's also a ncurses-based interface for git called tig[1]. I find it a bit easier to stage chunks/lines than git add -p as it's interactive. When I'm not on a command line, gitx-dev for OSX [2] also makes it very easy too.
At least on the experimental LHC side, we process/analyse each event independently from every other event, so it's an embarrassingly parallel workload. All we do is split our input dataset up into N files, run N jobs, combine the N outputs.
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.
If they can make a 20" 4K display and put it in a tablet, then why can't they just mount it in a desktop display and I'd be interested in buying it (though whether I have the money is a completely different question). I'm sure it would be easier to manufacture if they didn't care about weight/power consumption and there might be a bigger market.
> First of all I do not trust any hardware. It’s impossible to verify that the hardware doesn’t have a backdoor and randomness looks random even if tampered with.
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).
There are many rendering filters and pipelines available for DirectShow (and therefore MPC-HC) that VLC does not have. For example MadVR[1] improves upscaling and display rendering quality dramatically and xy-VSFilter can render subtitles many times faster than libass which is used in VLC.
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).
I get my SSL certificates from Namecheap[1]. Here the cheapest ones are $9/yr (they are the same certificates as the OP's cheapest ones) and they're I suppose a well-known domain registrar.
There is also the Pizza Theorem[1] which says that even if you don't cut the pizza through the middle but so long as the slices are of equal angles, you can divide it equally by area by choosing alternating slices.
> In my case the hacker asked to all my contacts with an automatic message for some Liberty Reserve money. Most of them trust me and my account, so they were inclined to accept.
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.
More info at: https://blogs.msdn.microsoft.com/tzink/2016/05/19/why-does-m...