jlhawn

I thought it was Uranium 235 which was the common weapons material, so I looked up Wikipedia [1]:

> ... While it is thus possible to use uranium-233 as the fissile material of a nuclear weapon, speculation[8] aside, there is scant publicly available information on this isotope actually having been weaponized ...

[1] https://en.wikipedia.org/wiki/Uranium-233#Weapon_material

I updated it with some comments explaining what's going on: https://play.golang.org/p/xEnlcwBX4CN

I wrote a quick little program to sort of prove this to myself: https://play.golang.org/p/fITZrZgzTT7

While the average difference in time between one record and the next is 10, the weighted average over the entire duration is 20.

Maybe I'm misunderstanding the question, but it sounds like the question is not asking how to parse HTML with a regex, but how to match HTML open tags specifically.

While you obviously can't match arbitrary HTML with a regex (because arbitrary levels of nested elements requires a stack-based parser), can you not match HTML tags with a regex? It seems to be that it should be possible since you always have the pattern '<' followed by the name of the tag, followed my zero or more "key=quoted-val" attributes, and finally a '>' token.

So, if the question is limited to just how to parse a single open token then it seems like all of the answers have just decided to echo what they've heard in the past which is "don't use regular expressions to parse HTML" when the truth is that a real HTML lexer/parser does use regular expressions for creating these "open" and "close" element tokens for the parser.

Very cool experiment! A fork bomb spawns processes at an exponential rate, however it looks like this just creates a linear chain of Docker daemons?

> Now wait patiently until your hd fills up.

This is obviously slower than a fork bomb, but I wonder which happens first: either the hard drive actually fills up or you run into a process limit.

Since when is a security issue which is known to and patched by the vendor a "0-day"? Have there been any reported exploitations of this vulnerability in the wild before it was publicly disclosed with a patch made immediately available?

These swarm tokens (SWMTKN) are not sent to any external service. The tokens are only sent to an existing swarm manager in your cluster.

Here's how it works:

- When you run `docker swarm init` it initializes the current node as a "manager" which has a datastore of cluster configuration and is responsible for assigning tasks to "worker" nodes (including itself). This init process also generates a cluster CA and two secrets authorizing manager and worker joins. The output of this command will be two tokens which you can use to join new nodes to the cluster as either a "manager" or a "worker". These tokens are structured like this:

    SWMTKN-1-<cluster CA hash>-<manager or worker secret>

- When you install Docker on another node, you can join it to your cluster by running `docker swarm join` specifying the token and the address of an existing manager. This new node is able to authenticate to the existing manager by asking for the cluster's CA certificate and hashing it to make sure it matches the value in the token. The TLS connection to the manager is verified by the new node which then makes the join request with the secret which indicates to the existing manager whether this new node is joining as a manager or a worker. These tokens are unique to your cluster and never sent to any external system.

- If the new node is joining as a manager then the cluster configuration is replicated to to the new manager. Docker uses the Raft consensus algorithm to maintain consistency of the configuration data. As long as a majority of your manager nodes are available then the managers will be able to coordinate and issue work to the available workers in the cluster.

I hope this helps you better understand how the cluster is secured.

Thanks! The example used case you describe for `thinker sync` is certainly a good one for smaller dev shops - unfortunately many larger enterprises might have issues with cloning production customer/user data for development purposes. Of course I don't expect this to apply in every situation.

One more thing that you might want to clarify: you gave a metric for the time it takes to sync to your local database over the internet. I think it would be a good idea to indicate the connection bandwidth and the amount of data which was actually saved from being transferred (perhaps only in number or percentage of records) as well as post the full time of a regular clone as a base metric.

Is this meant to be used for making backup and restore easier? If so, doesn't RethinkDB already have `dump` and `restore` commands for handling this? The docs[1] already make it seem pretty easy to do. It would be a good idea to add motivation to the README for this project, just a paragraph on what Thinker solves that `dump` and `restore` do not.

Edit: I'd also like to read why/when `thinker sync` should be used over utilizing RethinkDB's built-in table replication functionality.

[1] https://www.rethinkdb.com/docs/backup/

Which Ubuntu image are you using? The official Ubuntu 14.04 image has always been only 4 layers and is about 190MB total size.

The slides mention that Docker containers have hashes. This is not the case. In fact, it's probably one of the biggest user misunderstandings of Docker. Container IDs and Image IDs are not SHA hashes. Even though it may look like it they are actually just randomly generated 256-bit hex-encoded unique identifiers.

Since the slides also mention that you can use Docker images with a systemd-nspawn/machinectl setup it would be great if they soon supported the v2 Docker Registry and image format which actually does use content-addressable hashes for images.

> trying to see if I could implement `docker build` using available commands

This should be possible soon! The only command missing is a symmetric `docker cp`. I've got most of the implementation ready to be reviewed in a pull request [1] (closed now, but I will reopen it soon).

[1] https://github.com/docker/docker/pull/10198#issuecomment-733...

Hi. I'm the original author of the aforementioned docker image spec document.

Sorry for the confusion. I had not known that "JSON Schema" was a commonly used term like this.

Thank you for bringing this to my attention. I've just opened a pull request on the docker github repo to use a different word for the title of this section [1]. In the context of docker images, the term "Image JSON" is commonly used to mean the image metadata JSON file. This section was titled "Image JSON Schema" not to say that it is a "JSON Schema". Rather, I used the word "Schema" more generically here to mean that this section is an outline/description for the format of this file.

I also agree that this thread is not an appropriate place to discuss the docker image format. If you have any feedback or questions related to it, please open an issue on the github repository, ping me, and I'll gladly help.

[1] https://github.com/docker/docker/pull/10333

Something which was particularly striking to me about this presentation was how the steno input system seems very similar to the Korean alphabet and writing system, Hangul [1], a phonetic writing system in which each syllable is composed of a beginning consonant, a middle vowel, and an ending consonant. Steno seems to have a very, very steep learning curve, but Hangul has been around since the 15th century and is already used by over 50 million people. While the steno 'chords' seem to have as many as 5-6+ keys pressed at the same time, Hangul blocks are typically 2-3 characters. I've been learning Korean for about a month and though I only know a handful of words, I find the writing system easy to learn and use. While it doesn't allow for all combinations of consonants and vowel sounds that exist in western languages like English, with some modifications a hybrid writing/input system could be made which may not be as powerful as steno, but is easier to use and learn like Hangul, allows for all of the consonant and vowel sounds used by most languages, and gets you most of the efficiency gains of stenotype.

[1] http://en.wikipedia.org/wiki/Hangul

In the first lecture of the Artificial Intelligence course at UC Berkeley, one slide says: "A better title for this course would be: 'Computational Rationality'"

Read: Whom to vote out of office.

> None of the above.

I'd use encryption and try to convince others to as well, but I rely on email search too much. I'm sure a lot of people don't bother to 'tag' or 'label' their email, but instead rely on search to find messages with certain content in them. Maybe I'm wrong, but I don't see a way to have both with the server being unable to read the contents of the email to build a search index.

Since you like Sublime and like Chrome, you'll probably also like the Sublime Web Inspector plugin. http://sokolovstas.github.io/SublimeWebInspector/