It's interesting and probably not surprising that the most popular drug on the Silk Road 2.0 (and probably other darknet marketplaces) is MDMA. MDMA is difficult to find in pure forms and impurities can kill you. If you buy MDMA from a vendor with a 4.9/5 rating, you can be reasonably certain you're getting quality product (comparable to old pressed pills you can hear aging ravers wax nostalgic about) at a fair price.

I expect marijuana legalization will eat away at darknet marketplace weed sales, leaving MDMA and LSD as the top two. Which is exactly how it should be. They can be made in large quantities by moderately-skilled chemists to a high degree of purity and safety, and the Silk Road allows them to be distributed without any violence. It'd be impossible to bulk-search the mail for them. MDMA could be packaged as any white powder and LSD is literally paper.

I hope that this safe availability of MDMA and LSD quenches the misinformation campaigns that have so horribly marred their reputation for the public. Both of them have incredible potential for therapeutic and recreational use.

I think the public educational IT system should not be outsourced to the private sector, where schools completely lose control of the data and depend more or less on the good will of the company. University courses should not be organized by Facebook and pupils should not be forced to use IT systems of non-trustworthy companies like Google, which earn money by profiling their customers. Maybe my view is too German, but I think of education as an sovereign function of the state, where everything (theoretically) can be controlled by the citizens (yes, I know that this is some kind of optimistic). We should teach kids to think critical about centralization of data and knowledge and show them how to manage their digital lives with free and open tools which respect the users rights.

> this completely destroys the premise of HTTPS that you have an encrypted connection to the website you are visiting

It does nothing of the kind, it has always been the case that seeing the SSL padlock only informed you that the connection to whichever server you are communicating with is encrypted and nothing more.

Do you not recall the age of customer feedback pages hosted behind SSL that actually just sent plain text emails over the internet to the customer service email? SSL was never a guarantee that end-to-end communication was encrypted, and usually it was barely that.

What CF have done is to say that the jump to their servers can now be secured by SSL and that this works even for those who would not configure SSL (for either cost or complexity reasons). It's nothing more than that, it remains the case with SSL that you are trusting the site to support end-to-end encryption for sensitive data.

But what it does allow CF to do is partner with companies like Linode, Digital Ocean and so on, so that in effect when a user connects to CF via an SSL connection the entirety of the communication could occur within the trusted CF+Partner network and none of the traffic would be plain text over the internet. It's a foundation to build upon.

> If Facebook scans my chat logs, […] their TOS permits them to scan my chat logs.

Your language betrays your cognitive dissonance. It it not your chat log. It was never your chat log. You typed characters into Facebook’s chat log, and the chat log is Facebook’s. There is no “permitting” needed. When you use Facebook (or Google, or whatever), you live in a glass house, an aquarium, with overseers who do not consider you a person with integrity, but more as a kind of pet to be inspected and analyzed at will. Facebook distracts you with “privacy settings”, but those apply to other pets in the aquarium, not its overseers. It might be discomforting to think of yourself as a pet in an aquarium, but you have chosen this yourself, by using Facebook.

The question if Facebook is permitted to scan your chat logs is therefore meaningless; there is no such concept. Facebook “scans” all its chat logs, all the time. (That’s why they have their chat logs.) The “privacy settings” have nothing to do with actual privacy from Facebook — like Monopoly money, it has no validity outside the tiny world of its own. Like “deleting” things, it appears to you to delete things, but does not actually delete them as far as Facebook is concerned — it is all logged and saved, forever. I could go on, but I’d better not.

(The same goes for Google and all the other cloud and social services.)

While it's certainly good enough for english bodies, its half-assed support for compounds is a problem for bodies in languages that use compounds (German for example).

There is sorta-support for compounds, but only really for ispell dictionaries and the ispell format isn't very good at dealing with compounds (you have to declare all permutations and manually flag them as compoundable) plus the world overall has moved over to hunspell, so even just getting an ispell dictionary is tricky.

As a reminder: This is about finding the "wurst" in "weisswürste" for example.

Furthermore, another problem is that the decision whether the output of a dictionary module should be chained into the next module specified or not is up to the C code of the module itself, not part of the FTS config.

This bit me for example when I wanted to have a thesaurus match for common misspellings and colloquial terms which I then further wanted to feed into the dictionary, again for compound matching.

Unfortunately, the thesaurus module is configured as a non-chainable one, so once there's a thesaurus match, that's what's ending up in the index. No chance to ever also looking it up in the dictionary.

Changing this requires changing the C code and subsequently deploying your custom module, all of which is certainly doable but also additional work you might not want to have to do.

And finally: If you use a dictionary, keep in mind that it's by default not shared between connections. That means that you have to pay the price of loading that dictionary whenever you use the text search engine the first time over a connection.

For smaller dictionaries, this isn't significant, but due to the compound handling in ispell, you'll have huge-ass(tm) dictionaries. Case in point is ours which is about 25 Megs in size and costs 0.5 seconds of load time on an 8 drive 15K RAID10 array.

In practice (i.e. whenever you want to respond to a search in less than 0.5 secs, which is, I would argue, always), this forces you to either use some kind of connection pooling (which can have other side-effects for your application), or you use the shared_ispell extension (http://pgxn.org/dist/shared_ispell), though I've seen crashes in production when using that which led me to go back to pgbouncer.

Aside of these limitations (neither of which will apply to you if you have an english body, because searching these works without a dictionary to begin with), yes, it works great.

(edited: Added a note about chaining dictionary modules)

Wow, what an incredibly dense thing to presuppose and advice others that the idea of data normalisation is antiquated because the primary purpose, when it was "thought of", was to save disk space!

Data normalisation is all about correctness - mathematical correctness. It's about reducing inconsistencies in your abstracted domain model so that you do not suffer side effects when using your data (such as in your programs). It is not optional.

This is poor advice to others. Especially if "the adviced" are uninformed, new or finding the subject hard.