As I mention in a previous comment, if you are using the TOR hidden service (3g2upl4pq6kufc4m.onion/) the redirect goes over a TOR exit node without https. Ideally it should use the hidden service so no exit node is involved, or at the least use HTTPS.
One thing that would be nice to fix in the new interface:
If I use the DDG TOR hidden service, 3g2upl4pq6kufc4m.onion, do a search and click on a search result the link goes via a DDG redirect from r.duckduckgo.com. This should be using the hidden service domain, not the duckduckgo.com domain. As it is the redirect goes over a tor exit node rather than directly via the hidden service.
You can have multiple different versions of packages installed and other packages can depend on the different versions. The management of the 'shared library hell' is done behind the scenes using symbolic links in a GNU Stow like manner.
You can create 'environments' that are collections of installed packages and switch between them so tools needed for one task don't pollute the namespace for other tasks. For example, I create an environment for working on Firefox. It uses specific GCC versions and libraries. Only that environment sees them. I then switch to another environment when working on another project which uses clang - that environment can't see the library versions from the firefox environment, etc.
You can build package from source or download from a binary cache. You can modify configure flags and other build settings and the correct packages will rebuild - or download from cache if they are built with the same flags.
I wouldn't describe JavaScript's OOP as bolted on. It's just a different kind of OOP - prototype based rather than class based. You could argue that Lua is more "bolted on OOP" since there are quite a few different libraries that build OOP for it.
As long as you hold the private keys yourself and don't keep them on third party websites your holdings are safe. Safer than cash since you can encrypt and back up the keys.
Exchanges usually charge a withdrawal fee to cover transaction fees. BTC-e also charge a fee for example. Bitcoin software doesn't provide (an easy if possible at all) means to compute the fee up front to pass on to the receiver. So exchanges charge a fee that to cover the average cost per transaction.
Wouldn't multisig on an exchange prevent the use of cold wallets? It wouldn't be possible to move funds to/from hot and cold without a signature from the depositor.
It would also make trades a little more difficult in that users that are slow in signing off a transaction slows the trade down. The buyer has to wait until the seller has performed an action. Could you DoS an exchange with multiple buy/sells that you don't release?
At the time bitcoin wasn't worth so much so trading out might have been more reasonable. The large increase in price has made the debt much more significant.
It's unfortunate that those that have deposited since then have subsidised those that withdrew after the hacks.
The Geeksphone Revolution could be an interesting choice. Comes with Android pre-rooted installed with menu options to install other ROM's including Mozilla's Boot to Gecko as a supported option. You could run the latter with the Mozilla open source RIL implementation if you're concerned about that. I do like the hardware keyboard on the N900/Neo900 though.
It might not be a goal for Mozilla for it to be a production browser but it does seem to be for other people working on it and this is affecting what is being worked on:
Trunk builds of Firefox OS (version 1.4ish) work fine on my ZTE Open. I doubt they'll see consumer release though. I hope they do but I'm not confident in carriers pushing it.
Mercury is used in production with PrinceXML [1] and ODASE [2]. ATS is used in production in the implementation of a bitcoin mining pool [3]. OCaml is heavily used by Jane St [4]. SML (via the MLton implementation) is used in industry [5]. Rust is not ready for production, I agree, but is being used to develop Servo by Mozilla and Samsung [6].
That said I'd hope that systems like ATS, Mercury, MLTon and OCaml being open source make it easier to contribute to the implementation for issues that come up and this would offset any 'not enough real world' problems that they have. If you don't like those languages, pick another (eg. Haskell).
I agree but Flattr does provide an interesting approach. With them you set aside a set amount per month you want to donate. Then when you tip a site it gets a proportion of that amount based on the number of tips you made in the month. This way you cap your total spend per month. You could do this manually of course. Maybe sites could start a system of including a bitcoin address in a file at a common location in the URL space.