kalmar's comments

This is a better link, as it will include the discussion: https://github.com/rust-lang/rfcs/pull/1774

(OP here) I think that would be a useful thing to do in some situations, but it often won't get what you'd like. There's no guarantee that a view will ever call it's superclass' implementation, so inserting code has to be done a the leaf view classes not further up.

She wrote about it not long ago: http://jvns.ca/blog/2016/08/29/how-i-made-a-zine/

Short answer: she did the first zine on paper, and the second one on a tablet.

Now I want to learn about stack probes!

Ah so the idea is that there's already 8 KB of actual pages set for stack by this point. So when I try to get another (8 MB - 8 KB + 1 B), that blows things up? I wonder if I can watch this happen in /proc/$pid/maps or somewhere else around there.

Oh this is cool! I should have checked more pointers. On my machine, the single pointer was always null, and I read up on stack being initialized to zero. I didn't realize the things-before-main could mess up the stack so much.

> In my view, for a language that bills itself as safe, there should not exist such things as undefined behaviors. As far as I am concerned, then, based on the advertising of Rust, this is false advertising.

The key thing from the reference [0]:

> "Type checking provides the guarantee that these issues are never caused by safe code."

It's subtle, but I think the situation is that "some segfaults are caused by undefined behaviour, and some undefined behaviour causes segfaults". Neither fully contains the other. One thing I was trying to get across is that a segmentation fault has a very specific meaning, and that meaning is not "bad thing was done with pointers".

[0]: http://doc.rust-lang.org/reference.html#behavior-considered-...

I should have made that clearer, thanks! If there were intervening function calls there would be garbage. Then it would only "most likely" segfault instead of always segfault.

This project looks really cool! I'm very curious to find out more about how you make sure constants are correct across platforms and architectures. I will be poking around!

Author here. This is a really valid criticism of the post, and I think it'll inform the next post I write on the topic. Thanks!

I was almost excited! From the FAQ on the project you linked [0]:

> Q: Why doesn't this project mention distribution?

> A: Distribution, for example using HTTP as both Docker v2.2 and AppC do today, is currently out of scope on the OCI Scope Table. There has been some discussion on the TOB mailing list to make distribution an optional layer but this topic is a work in progress.

I really hope CoreOS manage to get distribution into the scope for OCI. We need to move beyond Docker images. Standardizing on-disk layout in OCI is only mildly useful in my opinion.

[0] https://github.com/opencontainers/image-spec#faq

This is pretty great! Looking forward to more service worker support for more offline and push notifications.

I'm not sure of the current status, but I believe the mechanism would be to label nodes with rack information. You'd then be able to specify anti-affinity constraints based on those labels that would be taken into account by the scheduler.

Edit: browsing issues briefly, I don't think this functionality is available just yet. Discussion of node selectors: https://github.com/kubernetes/kubernetes/issues/341#issuecom... -

I don't really know what the alternatives are. I'm hoping by the end of this series to convince at least myself that it's reasonably to run for personal projects.

My main resource is probably time. I read all the documentation when Kubernetes was first announced, and reread it when they were coming up to 1.0. I've also been following the proposals and issues a little. I've also got a clone of the codebase and read bits to make sure I'm understanding what goes on.

But yeah, it's a really fast moving project with a lot of moving parts, and I'm still not on top of everything!

> But, in return for being more low-level, you can run things that are simply impossible in a declarative system like Kubernetes.

Can you give an example? I know next to nothing about Mesos, Aurora, or Marathon.

Could you give some examples of places you mean?

The really easy part is it can happily run Docker containers:

    $ sudo bin/rkt --insecure-skip-verify run --interactive docker://busybox
    rkt: fetching image from docker://busybox
    Downloading cf2616975b4a: [====================================] 32 B/32 B
    Downloading 6ce2e90b0bc7: [====================================] 1.15 MB/1.15 MB
    Downloading 8c2e06607696: [====================================] 32 B/32 B
    2015/08/28 12:15:24 Preparing stage1
    2015/08/28 12:15:25 Writing image manifest
    2015/08/28 12:15:25 Loading image sha512-9d710100ce6769569b12a39100318bfed5b6b98115ee6315b724c11658db3751
    2015/08/28 12:15:25 Writing pod manifest
    2015/08/28 12:15:25 Setting up stage1
    2015/08/28 12:15:25 Wrote filesystem to /var/lib/rkt/pods/run/e3cbf309-5f03-4ce4-b098-597b5ec3e040
    2015/08/28 12:15:25 Pivoting to filesystem /var/lib/rkt/pods/run/e3cbf309-5f03-4ce4-b098-597b5ec3e040
    2015/08/28 12:15:25 Execing /init
    / # ls -l $(which ls)
    lrwxrwxrwx    1 root     root             7 May 22  2014 /bin/ls -> busybox
    / # exit
    Sending SIGTERM to remaining processes...
    Sending SIGKILL to remaining processes...
    Halting system.

The `--insecure-skip-verify` is to disable the GPG verification that rkt does for its native ACI container format. Beyond that, take a look at `rkt help run` and poke around.

Thanks for those links. I'll definitely watch the first one to get an idea for organising the later posts.

And yeah, pods are a great idea. I came across mtail [0], an awk-like language for tailing logs and turning them into metrics. Putting that in a pod with uninstrumented serving components will be fun!

[0] https://github.com/google/mtail

Author here. Yeah, I'm hoping to use rkt instead of Docker when I actually put this all together. Docker wins for familiarity though, plus is the kubelet's default hence using it for this post.