Hacker Newsnew | comments | show | ask | jobs | submit | login

Another fun ice fact is that hot water freezes faster than cold water: http://math.ucr.edu/home/baez/physics/General/hot_water.html


in some poorly-understood conditions

This factoid gets trotted about without ever noting the (tiny) magnitude of the effect, it just plants a (false) idea in the readers mind that you can get ice faster by microwaving water first.


If you look at the source of that page, you'll see:

  <link type="application/atom+xml" rel="alternate" href="/feeds/p/dcef3/gitchanges/basic">
which refers to an Atom feed for the project's commits.

Same for Github projects, e.g. at https://github.com/petdance/ack2 you will find:

  <link href="https://github.com/petdance/ack2/commits/dev.atom" rel="alternate" title="Recent Commits to ack2:dev" type="application/atom+xml" />


Great! Thanks for the info, and sorry for the dump question without doing any research myself first - that idea occurred to me but I've never had the time to investigate into it :P


For what it's worth, they do allow credit roll-over now (up to some limit).

Still, I'm annoyed at the DRM, I can't listen to what I want where I want, and there are alternative DRM-free alternatives, so I'm also seriously considering cancelling my account. Glad to hear they still let you access your previous purchases (it was my main worry).


Right. It is questionable why self-signed certificates trigger scary warnings in browsers when totally unencrypted connections do not.

I think the whole UI aspect of web transport security needs re-thinking.


It's pretty simple: An unvalidated/unauthenticated certificate looks like a MITM. Requesting an HTTPS resource indicates you want a secured connection. If the certificate is not trusted, then you don't have a secure connection.

The criteria is not self-signed, it's trusted/authenticated or not. Most self-signed certs are not trusted, and solving that solves the CA problem. But if a self-signed cert is trusted then browsers happily display the secure UI without any errors.


Anecdotal I know, but interestingly I also received one last week. I've had the account since Spotify was in private beta and this has happened only once before that I recall.


Two clearly unbiased and factual analyses there :)

It would take quite some time to sit down and address all the points gathered on the PSYC page. That page has been around a long time, and used to be a lot more aggressive than it reads now. At one point it even contained a quote from a mailing list post of mine, snipped to remove just the right amount of context. I'm glad to see they've cleaned it up a bit, to at least make it appear somewhat more objective, even if they still think it's objective to make technical statements like "XMPP isn't proper XML".

One of its main points is of performance and scalability. Well I'm afraid that horse bolted - for nearly a decade Google have been successfully running (one of?) the world's largest IM services using XMPP.

Regarding your second link, well, that seems to be set on comparing XMPP to IRC:

> A protocol that, despite an immense range of features, can easily be typed by a human on a telnet prompt, in real time.

Making a protocol that could be typed over telnet obviously wasn't the goal of XMPP. For what it did set out to do - create an open standard IM protocol to give normal people a path to freedom from the old IM silos that were around 10 years ago - I'd say it has been pretty successful. Maybe not as successful as one might have hoped, those silos are still around, but for political and commercial reasons rather than technical ones.


http://xmpp.org/extensions/xep-0322.html (originating from the IoT community, where XMPP is commonly, and successfully, used on embedded devices like you describe).

Just please don't mention ASN.1 again :)


OTR only protects the text content of your messages. It doesn't protect the metadata, or many of the other features XMPP provides from status to file transfers and voice/video calls.


For media calls there is ZRTP.


I'm not an expert in this field, but as far as I know ZRTP trust is bootstrapped from the signalling channel (in this case your XMPP connection). So a MITM there could also MITM your voice/video.

And again, your metadata and signalling would still be exposed without encryption - along with your IP addresses (ICE candidates), etc.


Funnily enough, that's exactly what they did do, back in 2008 :)

Originally Android included an XMPP API that applications could use to connect to Google and other XMPP services. This got replaced by a Google Talk-specific API at the same time they switched to a proprietary protocol.

E.g. http://blog.kosmokaryote.org/2008/02/google-cannot-be-my-cha...


Naive implementations of XMPP on mobile can indeed get quite power hungry, but it doesn't have to be that way. Thankfully I've seen quite a bit of interest lately from mobile clients who wish to improve on this - all the resources are out there.

Some links:

- http://xmpp.org/extensions/xep-0286.html

- http://xmpp.org/extensions/xep-0273.html

- http://xmpp.org/extensions/xep-0198.html

XEP-0198 is currently gaining adoption quite nicely for example, it allows for reliable streams (resume them without message loss or the need to re-sync everything if you get disconnected).



Applications are open for YC Summer 2015

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact