I work on software for augmented reality and distributed systems. That background is not directly applicable to quantum physics, but I like to think that I am highly trained at spotting logical errors.
742 karma · joined December 22, 2014
Of course, but it is less than one. Hence the measurement underestimates the proper time interval.
The Larmor clock doesn’t measure a proper time as in spacetime distance between two events. Instead it measures the rotation of a dipole in an electromagnetic field.
The experimenters apply a combination of an electrostatic field (the barrier) and a magnetic field (the timer driving Larmor precession). In the frame of reference of the spinning particle, this is exhibited as a sum of two electrostatic fields. The barrier is a locally uniform repulsive electrostatic field, while the the timer is a radially varying axial electrostatic field. The particle is a dipole, tilted from the timer axis by the precession angle. When the particle tunnels through the barrier, it also tunnels through the timer field, without precessing over the tunneled distance just as the particle is not exhibiting repulsion from the barrier over the same distance.
This is experimentally verifiable as the amount of missed precession has a lower bound proportional to the sine of the angle between the magnetic field and the barrier.
* CVE-2019-11500 : Critical Dovecot and Pigeonhole vulnerability (https://www.openwall.com/lists/oss-security/2019/08/28/3)
I still run my own mail server, but I hate having to keep up with these security vulnerabilities which can come up at the most inconvenient time.
They certainly have angular momentum, it just depends on the choice of origin. If you pick an origin along the peak ray of the plane wave, there will be no twist around that point. Just like with a particle traveling in free space.
In this specific case, it's unclear whether the bug has direct security implications. The broken SHA-1 is used on some user-controlled data that gets XORed onto the server's decryption of a user-specified payload before being passed into an RC4 key schedule. It's certainly plausible that this might produce a server-assisted privacy compromise of other users' sessions.
See the changes relative to the original draft here: https://www.internet-strafrecht.com/wp-content/plugins/downl...
A few highlights:
- Instead of "providing an internet-based service", the crime is now "facilitating access to an internet-based service".
- It is no longer a requirement that access to the service be restricted.
- The law now applies to all crimes, rather than just the specific crimes that were listed before.
Diff can be found here: https://www.internet-strafrecht.com/wp-content/plugins/downl...
Diff from the initial proposal: https://www.internet-strafrecht.com/wp-content/plugins/downl...
This claim will require some evidence. In my experience, it's extremely common for novice engineers to trade orders of magnitude in build time overhead chasing negligible runtime performance improvements.
Sure, incremental linkers exist [1], but all of them tend to do O(n) work on every invocation. Source control software, even developed explicitly to scale [2], behaves the same way. Makefiles as well; Tup [3] tries to solve this, in vain since the linking step is still holding everything up. There is so much inherent inability to scale built into our tools. So on big projects everything grinds to a halt as you cannot buy enough developers and hardware to keep up with O(n^2) forever.
[1] MSVC cl, GNU gold
[2] git: http://lkml.iu.edu/hypermail/linux/kernel/0504.0/2022.html
[3] tup: http://gittup.org/tup/manual.html