I understand that it is hard to integrate into TeX. I don't see how the general problem is hard to solve. Detecting rivers is not hard (maybe hard to do optimally) and adding a penalty accordingly is all the Knuth-Plass line breaking algorithm needs to avoid rivers.
Knuth-Plass is fundamentally a dynamic programming algorithm that depends on being able to say "If in the future I determine that there is a line break at point X, I know for certain that the way I should have broken the paragraph up until X is B", where B depends only on information before X.
If you're trying to avoid rivers, then based on information after point X you might find that your sequence of breaks B wasn't actually the best after all, because it ended up interacting badly with later spaces and producing rivers. So you can no longer prove that you've achieved a global optimum of the penalty function.
Of course you may be willing to take this hit and settle for non-optimum line-breaking (and you still might do better than an algorithm that doesn't take rivers into account at all).
If you google something like "latex rivers" or "latex microtype river" then you will see that there have been discussions, and some attempts. (Perhaps the issue is not as pronounced for mathematics, because of authors shying away from overly long paragraphs and because displayed equations break up paragraphs?)
dumb question: "more ht2000 lines of code" - is that a typo of "more than...", is "ht2000" something I don't know and can't google, or are are these hacks in some way related to an antique motherboard?
Incidentally, running containers is probably a great way to "install" the ghost libc vulnerability[1] (assuming you're basing off of base-images made before the bug was patched, and you haven't updated your containers/images).
I'm not sure neither vagrant nor docker have this really fixed -- that is: easily patching the base system/image (and still be confident that the app keeps running).
Is there an easy way to update a container based off of a (possibly few generations remote) base-image? Eg: You've pulled down a bare-bones, official CoreOS/Ubuntu/Debian/RedHat image from docker -- set it up for your use-case (say made a base image with your own CA-cert bundled, wired it up for kerberos/ldap/AD, maybe set up a trusted ssh-server ca-cert) -- then made a handful of images based off that: db, cache, and web-app.
Is there an easy way to patch the base image and all descendants? I assume all state should be in other volumes, so maybe this is easier than I think?
At any rate, it is something to keep in mind -- that grabbing images are great, but updates are still needed!
As other mention, the ghost refereed to by gp, is a blogging platform.
Bad news: Sandstorm packages do not have any particular separation between "base system" and "app"; your app package is simply one big archive of the entire userspace filesystem needed. This is something we might conceivably do in the future, but for now we like the simplicity.
Good news: Once the app maintainer publishes an updated package, it is trivial to update your local app instances in-place. Much like installing apps on Android, the system just swaps out the old package for the new one without touching the user data. We are confident enough in the robustness of this that we plan to implement auto-updating of apps, again like Android (though you'll be able to turn it off if you prefer).
Curious news: With Sandstorm, it often (not always, but often) doesn't matter if an app has vulnerabilities. Each app instance is initially only accessible by its owner, and only accessible to others if the owner explicitly shares with them. Often, the people you are collaborating with aren't threats -- they're your friends.
Apps that public a public web site -- like Ghost (the blog platform, not the glibc vulnerability :) ) -- actually do so strictly as static content. Sandstorm serves the content for them, without executing any of the app's code.
Admittedly, this starts to break down if you want to have a public web site in which users can make persistent changes -- say, post comments.
Of course, if someone does compromise one of your app instances, it's only that instance. The rest of your server remains safe, since each app is in an isolated container.
None of this is to say that patching exploits doesn't matter, but security is not about absolutes, it's about risk management. It's significantly less likely that a bug in a Sandstorm app will lead to real damage.
even if software is formally verified, and even assuming the specification is both totally accurate and complete, there is plenty of room for issues at software deployment in a multi-component system such as this
This appears not to actually solve the hard problems of cryptography. It simply generates a random key, them XORs your message with it.
The key and the message are independently just random data and don't reveal anything about the content of the original message (except it's length).
It is a pretty rare case where we cannot transmit messages securely but we are confident that we can transmit two messages and not have them both intercepted.
If on the other hand you can securely transmit keys that are as big as your data, you could of course just transmit the data itself.
As such this is a starting point in understanding cryptography rather than a practical application.
You would be right -- if the use case for this was transmitting encrypted information. The reason I made this was mostly for email. Sometimes I want to send someone a message and not have it exist forever. In that case, you could send a link to the message along with the key. Then, after n hours, the message would cease to exist anywhere (assuming the server fulfills its contract). This works better than having the server just store the whole message, since now the server gets to be ignorant of the message's content. Mostly this was a fun little project I wanted to share :)
I'm interested that rivers are such a concern of manual typesetting but I have never heard mention of it in typesetting algorithms.