A very interesting research paper

experimental detection of gravitomagnetic London moment. There's been a lot of crank stories about strong artificial gravity on top of rotating exotic stuff (superconductors, superfluids, and so on) but this one seems genuine and it is from ESA. If this is confirmed, this is *awesome*.
Of course, though, even with their experimental controls (a different type of superconductor), this can still be an experimental error. And of course if you have spent months designing a nice measurement device, good for nothing else, your subconscious strongly wants it to find something. Especially when such a finding would result in a Nobel prize. And unfortunately other teams did not yet confirm or deny this - it is unlikely there would be much research interest in this stuff because all the crank gravity research made everyone sensible extremely skeptical.
By the way, if I were to suspect a conspiracy, the evil conspiring parties would have been *funding* crank research in gravity and cold fusion to drown any signals in the noise and to make everyone overly skeptical.

Frame dragging, Mach's principle, and such.

From 'physics central'

If the Earth stood still and the rest of the universe rotated around it instead, would its equator still bulge? According to general relativity and Gravity Probe B, the answer is YES. It doesn’t matter if you are spinning or if the universe is revolving around you. Both situations are equivalent.

Hmmmmmmmm. That's reference to Mach's principle.
I'm no general relativity specialist and whatever I learn about general relativity is in form of textbooks with examples and stuff to solve, so I haven't ever came across the statement that rotation was 'relative' to something in GR before. Sure, people tend to think rotation is relative (not noticing that Earth is spinning), but rotation is demonstrably not relative in same sense in which motion is relative; you can sit in locked room without windows yet still deduce rotation of Earth 'relatively to far away stars' - even though you can't deduce motion of Earth relatively to far away stars, or tell apart uniform downward gravity from acceleration (which you could measure relatively to stars, if you wish). You can go beyond acceleration & rotation and consider Jerk (third derivative), then Jounce, those you can also feel in the locked room without looking at far away stars. Is there some dragging effect as well for higher derivatives, so that analogous statement like 'it does not matter if entire universe's being shaked or subway train you're riding hits a bump' would be true? [I really don't think so]. Does anyone know more about that?

Also, in special relativity (which I do know rather well, unlike general relativity), infinite or just very big universe *cannot* simply rotate at any rate of revolution, chiefly because far away parts would have to move at faster than speed of light to appear to be rotating around you. So, under special relativity it is no wonder what so ever that lack of rotation relatively to far away stars coincides with lack of rotation as determined by gyroscope. Special relativity is quite fine with Mach's principle.

Q: What is less than 3 in <3 smiley?

A: I, where I=x²+(y-|x|)² .


(finding the U as to obtain 3D heart is left as exercise for the reader)

Epicly badass sea animal

PulseAudio and why I do not use it.

[pulseaudio is a new Linux 'sound server']

Firstly, to make it clear, I think that there is nothing really wrong with PulseAudio itself. Some versions even work fine with OpenAL, which means that my game's sound works.

What's not good, however, is distributions enabling it by default, and worst yet, distributions [ubuntu in particular] include much outdated versions of PulseAudio which have more bugs. This, especially the old versions, creates extremely difficult landscape for application developers, open source and commercial alike. Furthermore, introduction of PA on by default violates the "suck less" principle - the principle that after each new update software or the system must such *less* than it sucked before - and if it does not, you'll be losing users. What's even worse is distributions entirely ignoring frequent user complaints about PA.

The most important thing to understand about PulseAudio is that it is NOT a sound driver and is NOT an ALSA replacement. PulseAudio takes in sound from applications, does some stuff on it, and outputs the sound through ALSA. It is a sound server. It adds new features, and inevitably, new bugs.
It so happens that vast majority of software can work with ALSA directly; and it so happens that ALSA includes a lot of features which people expect and need - mixing sound from different applications (even when you do not have hardware mixer), volume control, and so on. The role of PulseAudio is to add new features.

What features? Straight from the PulseAudio developer.

• There's so much more a good audio system needs to provide than just the most basic mixing functionality. Per-application volumes, moving streams between devices during playback, positional event sounds (i.e. click on the left side of the screen, have the sound event come out through the left speakers), secure session-switching support, monitoring of sound playback levels, rescuing playback streams to other audio devices on hot unplug, automatic hotplug configuration, automatic up/downmixing stereo/surround, high-quality resampling, network transparency, sound effects, simultaneous output to multiple sound devices are all features PA provides right now, and what you don't get without it. It also provides the infrastructure for upcoming features like volume-follows-focus, automatic attenuation of music on signal on VoIP stream, UPnP media renderer support, Apple RAOP support, mixing/volume adjustments with dynamic range compression, adaptive volume of event sounds based on the volume of music streams, jack sensing, switching between stereo/surround/spdif during runtime, ...
• And even for the most basic mixing functionality plain ALSA/dmix is not really everlasting happiness. Due to the way it works all clients are forced to use the same buffering metrics all the time, that means all clients are limited in their wakeup/latency settings. You will burn more CPU than necessary this way, keep the risk of drop-outs unnecessarily high and still not be able to make clients with low-latency requirements happy. 'Glitch-Free' PulseAudio fixes all this. Quite frankly I believe that 'glitch-free' PulseAudio is the single most important killer feature that should be enough to convince everyone why PulseAudio is the right thing to do. Maybe people actually don't know that they want this. But they absolutely do, especially the embedded people -- if used properly it is a must for power-saving during audio playback. It's a pity that how awesome this feature is you cannot directly see from the user interface.^[1]
• PulseAudio provides compatibility with a lot of sound systems/APIs that bare ALSA or bare OSS don't provide.
• And last but not least, I love breaking Jeffrey's audio. It's just soo much fun, you really have to try it! ;-)

That's the things which PA aspires to make work. It's all amazing - AFAIK many of those features are not supported by the Windows or OS X. Well, that is all great, but you can imagine what sort of complexity PA needs with such a feature list.

I'm a simple man. All I want is to play music while I'm working, I want sound in flash, I do not like if some applications do not work, and I want sound in games (which use OpenAL). I need reliability. Complexity is the enemy of reliability, and the perfect is the enemy of the good.

I do not care about per application volume sliders (guess what, my application has two volume sliders, for SFX and music), I do not care about moving sound streams between devices during playback, I DEFINITELY do not give a damn about positional event sounds (more than that, I would not mind if event sounds even quitted working, except for: time alarm sound, and new mail sound), I do not care about multiple sessions playing sound through different devices, and so on and so forth. I'm pretty sure that a typical user has even simpler interests. The primary thing he needs is lack of regressions - everything that worked back when he decided to switch to Linux must still work - else he will switch back (!).

As developer, what I want is a stable API. A mature software which does not change much any more in each release, and which is not so buggy. Unfortunately, software maintenance is boring, and open source software is maintained by bright people whom do not like boring tasks. Open source developers want challenges. They want to do epic stuff that no other system does. They prefer rewrites over maintenance, they prefer large sets of very challenging features (often, features that almost nobody asks for) over basic set implemented to high reliability, and so on. They underestimate importance of reliability for people, and overestimate importance of new cool things (and keep doing that no matter how much are they flamed). Linux environment has a long history of frequent, major, breaking rewrites of important subsystems - far more frequent than on either Windows or OS X - frequent to the point that subsystems get rewritten before previous incarnation is polished and mature enough.

SSL certificates - a case of daylight racketeering.

The dirty little 'secret' of the Internet is that in most networks all the computers on same LAN with you receive same data as you do, ignoring 'your' data by gentleman's agreement. [Unless computer is running 'packet sniffing' software that does not abide by this agreement] It is very easy for third party to listen to your Internet communications; far easier than to hack a computer between you and (for instance) your email server to launch a 'man in the middle' attack, standing between you and web service. Every login form and every webmail interface can cheaply and easily be encrypted using SSL, closing at least this gaping security hole.

Unfortunately what happened in practice is that some large businesses - certificate authorities - managed to subvert just about every browser (including Firefox) as to display extremely scary warnings on sites which want to just use the encryption without paying hefty yearly sums of money for supposed verification and authentication - while displaying no scary warnings on far less safe sites which use no encryption what so ever.
This bizarre browser behaviour of warning more scarily about safer sites has been done under guise of pushing better security practices. While in theory better security would be a laudable goal, in practice, what is being done is more of a negative campaign against acceptable security, preventing use of any encryption on many sites you and me visit every day.

There is a zillion uses where we do not need certificate authority but do need encryption. Router, internet camera, internet printer, and other internet appilance's web interfaces, on the devices which you freaking bought yourself, you need ain't no certificate authority here, the key can be printed on the box.
All those small web services like free webmail, blogs, etc. which are presently unencrypted would still benefit from encryption. All sorts of small sites. A lot of login forms. Literally any site if you don't feel good about government taps into the network (especially those done by foreign government, see echelon).

Even something as critical as my bank would also do better without certificate authority, and indeed, with a different, simpler protocol. Many banks (my bank, for instance) give users password generator devices or cards, as well as initial constant password (in the envelope). In person.
In a more sane universe, that device's passwords would have been used for crypto, at login ensuring both that you are yourself and that bank's page is genuine. The password IS a shared secret after all. There's SRP protocol which is good for just that kind of thing. With SRP both ends of connection must know the password; and when you login using SRP you are not revealing the password in any way (login could only work if both sides know password).

In reality, however... SSL and your browser does not require server to know your password, but instead requires servers owner to do various paperwork and to pay money to "Certificate Authority" whose key is "trusted" by browser (i.e. included in the browser install). Asymmetrical cryptography indeed. Bank pays to Certificate Authority who pays to browser developers whom don't and won't implement SRP protocol.

The way how SSL does logins goes contrary to basic expectations of users. Users expect that the password they enter would be used somehow to encrypt the communication, making communications secure against any third party who does not know the password. After all that's how ciphers work. It is very difficult to explain to users how SSL works, and not so much because users are stupid but because SSL is stupid. It makes no sense to use some devilishly clever math of assymetric-crypto and PKI stuff for password protected login, where even ciphering using secret password as key would've provided better authentication both ways [but would require long passwords because attacker can try a lot of passwords offline on the intercepted data. SRP protocol solves that problem, preventing offline guessing].

The 'protection' certificate authorities can offer to the end user is clearly inadequate - man in the middle can simply use plain http without SSL for connection to the user; according to various studies (like this) about 90% of users do not pay attention to minor aberrations such as http instead of https and absence of the tiny yellow padlock icon, even if told in advance that some samples will be fake. The real percentage for unsuspecting users would be even higher. (On top of that, the indicator totally sucks and its immediately obvious that whoever came up with the indicator has no clue what so ever. Up to 9% males are colorblind with inability to tell apart green, yellow, and red, and this alone is enough for phishing to be commercially viable. Imagine you're colorblind, you learn that white is non-secure and redyellowgreen is good, then you run into suspected bad site. And it's looking more similar to good than to non-secure). Worse yet, phisher can easily obtain digital certificate under false credentials; the most dramatic examples include random dude obtaining VeriSign code signing certificate in Microsoft's name - not a same thing but funny nonetheless. While absence of yellow padlock implies absence of security, presence of padlock means nothing; training users to think "padlock = secure" would only make phishing more effective. Hackers do obtain digital certificates just fine.

For better arguments from a real security expert, read this excellent paper by Bruce Schneier.

To summarize: More secure login technology, SRP protocol*, does exist, and is already implemented as library. Instead of supporting it, browser developers* play a silly game of making biggish corporations pay hefty sums yearly to display their address bar in green, making everyone else pay smaller sum yearly for blue, and making those whom are really cheap do a funny dance every 30 days to re-validate their 'free' certificate. Heck even CA's marketing slogans ("No More Abandoned Carts" for example) focus on the notion that if you don't pay money to get yourself green address bar, you're losing customers.
[* browser developers are ultimately in control of certificate business, deciding which certificate authorities are kosher]

(* for grammar nazis: P in SRP stands for password, so it's alright to say 'SRP protocol' but not 'SRP password')

[edit: correction. Evidently, there is one or two SSL authorities which are now trusted by most browsers, which gives away free (as in free beer) certificates, requiring you to do a funny dance every 30 days to re-validate it or something. Its kind of uncertain where this whole thing is heading - will those certificates eventually show scary warnings as well? Will they start charging money for freebeer certificates?]