The DevTeam released nethack-3.4.3 in Dec 2003, and then pretty much went dormant for 11 years -- no new releases, no roadmap, nothing. So some time around 2013 some people not connected to the DevTeam created this project: http://nethack4.org/ . So now the DevTeam skips 4.x version numbers completely to avoid confusion.
Huh, what a blast from the past. About 30 years ago, in Russia, I hacked up cyrillics keyboard support for Coherent by extending the line discipline layer in its kernel. It was probably still Coherent 3.0 though (which IIRC was based on Unix V6?), and the one on github seems to be 4.2.x.
Apparently there's no support for smarthost / relayhost (or I can't find any traces of it in the documentation). Running your own low traffic mail exchanger without it is often not a pleasant experience.
Hmm, interesting. Are you speaking from experience? Because I definitely am. I watched my mother die a very slow, very painful death from cancer several years ago. I can assure you she would be absolutely genuinely happy to get that cellophane hood and that nitrogen cannula. And, having seen what I've seen, I will also take the hood over some very real alternatives in a heartbeat. Playing dress up with this ridiculously futuristic glass coffin toy instead seems somewhat preposterous when you are facing death.
No, it (again) doesn't work like this at all. 1) DNS blocking of cloudflare is useless, you can receive IPs, or names in non-cloudflare zones, 2) IP blocking of the whole cloudflare will bring so much collateral damage (unrelated services going down) that it's a non-starter, politically speaking, 3) cloudflare is far from the only mass frontend / cdn available, there are hundreds high-collateral services out there.
They don't have to be strictly unique per user. You can send out different sets of URLs to different cohorts of users, then correlate new URL blockings with client IDs to detect rogue app installations and excommunicate them. Telegram did that when Russia tried (unsuccessfully) block it.
Not as of yet. Actually, if you use tor (with out-of-Russia exit nodes, which I think is the default when using it from Russia?), you can already freely access all the sites blocked in Russia, non-onion ones. But, obviously, tor and VPNs are good solutions only for people willing to go an extra mile to get to the prohibited content.
Not really. You can use whatever you like, the possibilities are endless. AFAIU, the most straightforward approach would be to use Android / IOS push notifications (which can't be easily blocked) to regularly push a constantly changing (to avoid censorship) URL of your backend API servers to the mobile apps.
Yes, you can re-host, but propagating the new URL to your users will take days, and the authorities reaction time is, for high profile cases, measured in hours. Another interesting question is how will you propagate the new URL? To do that, you need some way to reach your users when your website is down. And if you have such a way, do you really need a website?
> In this case there's not many reasons for it to be a native app instead of a Progressive Web App. This would simplify distribution.
The opposite of this is true. Blocking a web application is very easy for Russian authorities, there are well-established legal and technical protocols for that, it's a routine, it happens every day. The opposition uses apps precisely because they are more difficult to censor.
It now has the option to avoid (laggy) Android media service framework, and to use its own scanner to detect media changes instead. That should be immediate.
You are mistaken. PRISM is specifically a program that "collects stored internet communications based on demands made to internet companies" [em. mine]. NSA wiretapping the non-public links of Google et ol was not PRISM (I'm not even sure that the name of that program was ever disclosed).
> IPv4 and NAT require maintaining a lot of state at critical intermediate routers. I'm sure we've all experienced (perhaps regularly) a NAT'ing router losing state because of a reboot, state tables overflowing, or similar hiccups.
As far as I can see, that state is not very important for the mobile IP design describe in the article. A router reboot or other hiccups are handled more or less the same way as an address change (there is a temporary connectivity loss, and when it's restored, you create a new mapping on the Y server between the existing connection, identified by the same old uuid, and the new external/internal addresses/ports of the client X).
I use calibre from community packages on archlinux, it has absolutely no problems reading metadata (authors, titles and covers, and tags etc when present) from epub / mobi / pdf / etc.
This is just Crypviser spreading lies. No, being on that Russian register doesn't imply any intention to comply with any wiretapping / censorship requests; in fact, IIRC, it doesn't even necessarily imply any consent to being added to the register. Saying that Treema's being added to the register means it "moved under the control of the Russian government" is no different than adding their company name and address to some Excel file on your computer and then saying that Threema has moved under your control.
From what I can see, sendfile isn't really async, it still returns the number of bytes written or error status, and nginx probably needs to wait for that to e.g. log the results, handle short writes, or proceed with whatever next operation must be done to the socket (like closing it). No idea why aio_write needs offloading, though.
Well, it's not the first fork in the world, ethereum's fork was pretty big (ETH vs ETC). As far as I can see, exchanges just treat both sides of the fork as two completely separate currencies (which, in fact, they are).
Why do you think that being the exchange used for cashing out is a bad position to be for an exchange? My understanding is, exchanges earn money on commissions, so the more volume they get, the better, and cashing out sure is some volume. Those speculators who buy BTC on the wrong chain -- sure, they will take a hit on that. But the exchange itself will still get their commission just fine. Am I missing something here?
I used DynASM in my little weekend project https://github.com/jsn/icfp06 , see README for my experience. In short: I like the idea a lot, but the implementation is seriously buggy. My experience with GNU Lightning (during the same weekend project) was much more smooth.
Yes, and this is old news, actually. We observed the rise of DDoS as a form of censorship in Russia roughly 10 years ago. People usually think that DDoS attacks are mostly used for extortion purposes, but in Russia it was routinely used to suppress some independent news outlets since 2006. Of course, now (since 2014) they have full-blown Internet censorship in Russia, so they don't need it anymore.
My understanding is that it doesn't apply at least to EV certificates. Also, the parent says that "any user who is delegating their DNS lookups to a third party", but that can't apply to such users either.
Not sure I understand what you are saying. If you are saying that "Any website who is delegating their DNS to some third party is potentially vulnerable" to subverting SSL/TLS, then you are absolutely wrong. Malicious DNS can help the attacker to insert her servers between the user and the web service the user is trying to access, but it doesn't subvert TLS/SSL man-in-the-middle protection in any way.
Password hashing is used to prevent the brute forcing when the attacker already has the copy of the password database, and is free from any failed attempt limits and timeouts. And in this case storing hashes of all 3-letter combos is basically useless, since all those hashes are very easy to bruteforce.