vishvananda

As one of the original authors of OpenStack and one of the top contributors, I may have a unique perspective. I think the OpenStack community made two related mistakes:

1. We thought that private clouds were generally valuable. In 2010 it seemed like everyone was going to have a private cloud. It turns out if you are a midsize business, having a rack of "cloud" doesn't really offer you much benefit over having a rack of managed vms. You still need to pay someone to manage that rack. The vast majority of the benefit of cloud comes from having a ton of workloads, which means a public cloud or a huge service-provider sized business.

2. We focused on community building by supporting all use cases. The best way to build an open-source community is to bring everyone in. The community grows fastest that way. Unfortunately, it also means that the product quickly becomes an unfocused frankenstein that is decent at everything and good at nothing. Projects like docker and mesos are suffering from the same problem.

The end result of these mistakes OpenStack is good for certain use-cases. It does really well in large companies that need a public-cloud like environment to manage their infrastructure and can hire a team of people to manage it (e.g. comcast, verizon, e-bay, wal-mart).

I don't know that the exodus is due to endemic problems so much as the market finally waking up and realizing that public cloud is the future.

Some things that make chess engines non-deterministic: 1) Most chess engines use an opening book instead of calculating moves early in the game. These books are often programmed probabilistically, so it may have 4 reasonable responses to a given move and pick one randomly. 2) Many engines are programmed to "ponder", that is do optimistic calculations during the opponents turn. This means that the time taken by you to make the move could potentially affect the calculations performed by the engine.

The nat device will have different source ports for two connected clients.

One thing that has helped me to understand fundamentalist groups a bit better is to see these tendencies in myself. I consider myself a strong individualist and free-thinker, but I still have places where I take comfort in fitting in to a group.

I tend to pick groups that I view as positive: hacker, scientist, feminist, etc. but they are fundamentally (pun intended) filling the same need as religious beliefs. They give me a framework to understand the world and feel connected to others.

I think as humans we are deeply attracted to belonging, and sometimes the "better" ideals are more dangerous, because we feel justified in judging others. Intelligent people are better at rationalizing their core beliefs, and therefore have trouble seeing beyond them.

Perhaps if we all could recognize the tendencies in ourselves it would provide enough empathy to facilitate change instead of conflict.

If you tend to vote third party, You should consider being against FPTP voting, because it almost always leads to a two-party system[1].

[1]https://en.wikipedia.org/wiki/Duverger%27s_law

The main problem with user namespaces is file ownership. User namespaces allow you to shift a range of user ids to a different set of user ids on the host, but there is no way to mount a filesystem with the same set of shifts. This means you have to copy the root filesystem for the container and chown it which is pretty hairy. Note that there have been various proposals to do some kind of shifting at the fs layer[1] but nothing has been finished yet. [1] http://lwn.net/Articles/637431/

We have the equivalent for car and room rentals. The escrow is just a hidden feature of our credit cards.

If you try to rent a car without a credit card, you are usually required to put down a deposit.

They used npm install in their example code? Well that was a poor choice. Having dealt with npm and node apps in my own build system, I have not found a good solution for deterministically building node apps. Does nix have a solution for this? Thankfully the prepackaged software with reasonable source build systems don't do craziness like this. See the redis package for example:

https://app.habitat.sh/#/pkgs/adam/redis/3.0.7/2016061320525...

I've been waiting for this announcement for a few weeks. Since the home page is quite lean on an actual explanation, let me give a rough summary of interesting points as i understand it. I apologize in advance if I have anything wrong.

1. It is a from-scratch source build system written in rust that borrows a huge amount from nix. This means repeatable software builds with isolated dependencies.

2. It attempts to move some configuration management primitives into the build pipeline so that the deployment config has enough flexibility for real-world use.

3. It intends to replace single host process supervision with a distributed model based on gossip.

This project is most definitely ambitious, and I'm not sure the whole goal is realizable but some aspects are particularly interesting.

1. The build process seems quite useful for building containers, especially if it gets some traction. The main drawback of nix is that no one knows how to use it. If this gets the backing of the hordes of chef-aware system administrators, we may have a good solution for isolated repeatable builds, especially if they focus on deterministic reproducible builds[1] as well.

2. Distributed systems are notoriously hard to configure in a general way. It seems like every company has their own magic combination of config management, monitoring, and scripting for keeping systems like zookeeper running. Its pretty clear that we don't have the right primitives for sharing this work. I don't think a container management system has the right primiteves for this either, because I don't think you can solve for all distributed systems in a generic way. You really need custom logic for the particular software you are trying to distribute. I'm not convinced that a gossip-based process-supervisor is the best approach for this, but it could give us a place to start collaborating on these primitives.

[1] https://wiki.debian.org/ReproducibleBuilds

Very thought-provoking whitepaper. As someone who has been working on securing containers for the past year or so, it gave me some additional avenues to pursue.

I read code a couple of times and did Nand2Tetris. I also found the edX 6.004 mit course[1] to be extremely useful to fill in some of the gaps. I'm waiting for part three to start in a couple of weeks.

[1]: https://www.edx.org/course/computation-structures-part-1-dig...

Not the original poster, but I assume: https://en.wikipedia.org/wiki/Bootleggers_and_Baptists

I'm a big fan of bpython[1] for this. F10 copies current session to clipboard, F7 opens it in an external editor, and Ctrl-s saves it to a file.

[1]: https://github.com/bpython/bpython

thanks for the tip on spectacles. I've been using sizeup for the same functionality for years bit it looks like spectacles does the same thing for free. How does paw compare to postman?

I haven't come across your project before. Any relation to my (similarly named) project https://github.com/vishvananda/wormhole ? I always thought that one of the most interesting piece of my project was easy ipsec tunnel setup. It turns out that setting ip ipsec tunnels is pretty tricky.

It also needs to reap orphan processes or they will become zombies. The dumb-init code does not appear to be doing that so I reported an issue[1].

In general docker is half-trying to be the init system, but most people using it are putting a whole child os with its own init system in their container. I think the approach that rkt uses where it uses systemd to run the process is safer. Now if people would just start using lightweight containers...

[1]: https://github.com/Yelp/dumb-init/issues/44

I noticed you removed etcd recently in favor of running raft internally. I have a couple of questions:

1) Why did you remove etcd? 2) Why use the hashicorp raft implementation[1] over the coreos raft implementation[2]?

[1] https://github.com/hashicorp/raft [2] https://github.com/coreos/etcd/tree/master/raft

when you declare your income you subtract your cost basis from the sale price. In 1 you paid $10 and sold for $100 = $90 profit you have to pay taxes on. In 2 you paid $35 and sold for $100 = $65 profit. It isn't the time at which you exercise that makes the difference, it is the higher strike price.

EDIT: to be clear, 1 and 2 refer to the original differences in the first post. If we are comparing different exercise time with the same strike price, then the taxes are nominally the same (Because the income tax % you pay depends on your income, you might be able to save money by exercising in a year when your income is low).

Actually your taxable income in the second case is less because you made less money. :)

Yes once upon a time companies could set whatever they wanted for the strike price but not anymore. I think there might still be a way to do it with complex bookkeeping but AFAIK everyone just uses the 409a value.

The main difference would be the strike price of the options, which can make a huge difference in both taxes and income at a liquidity event. Assuming the company is growing over time, you absolutely want option 1. The strike price is determined by a 409a evaluations.

Example: assume the valuations each year are 0.10, 0.20, 0.30, 0.40, 0.50 and the sale price is $1 at year 5.

In option 1 your strike price will be $0.10 for all 100 options so should you choose to exercise you have to pay $10, netting you $90. You can choose to exercise these as they vest, paying $2.50 each year. If you choose to exercise on vest, your cost is the same, although you potentially will owe AMT.

This means that if you make enough money you essentially have to declare the difference between strike price and current value as income. This means you will have to potentially pay taxes on an extra $25 over the four years.

In option 2, exercising the options will require $5.00, $7.50, $10, $12.50 for a total of $35. This means you only make $65 in the sale.

Most definitely not April fools, just terrible timing. Source: I was Nebula's CTO.

Gradle?

https://gradle.org/

Generally they follow exposure to the vaccine with exposure to the actual virus and see if the monkeys become infected.

I'm very curious to read the paper if anyone can find it posted online.

Shameless self plug, but not sure if you saw my project that does something along these lines:

https://github.com/vishvananda/wormhole

I'm a big fan of bpython (especially bpython-curtsies), but I have to admit the multiline editing and the navigation keybindings in this are very nice. Bpython lets you rewrite the last line via ctrl-r but it doesn't let you navigate through a multiline function. I find the way bpython shows the docstring when you type the open paren for a method extremely useful, however, so that would be a nice addition here.

If you haven't seen it, you should check out bpython-curtsies, it solves the scrolling problem problem:

    pip install bpython[curtsies]
    bpython-curtsies

This is very insightful. It is very hard to produce something that provides clear value in the microcosm (i.e. useful to developers) but is also valuable in the macrocosm (i.e. can be deployed to all targets).

One approach is to build something that solves the small problem but keeps enough options open in order to eventually grow to encompass the larger issues. I think this generally superior to the reverse approach, which tends to die from lack of adoption.

I don't know if docker, kubernetes, et. al. will actually get there. I agree that they will have to reshuffle and rethink to make it happen, but I hope that they can.

Vms and containers are roughly interchangable, yes, but I would argue that the tendency for vms to be treated as whole servers leads deployers to pack all of the solutions to the above problems into the vm building block. In the end there is a tightly-coupled virtual appliance and it is difficult to reuse the useful pieces. We missed the opportunity to separate these concerns and have meaningful and reusable pieces.

Containers are giving us another opportunity to revisit these choices. I'm hoping we don't miss the opportunity again.

I think this is a key point to bring to light, because most of the hype around using containers seems to focus on the fact that you can replace the hypervisor layer with a container manager (docker) and achieve a ton of benefit. For most use cases there isn't a significant enough difference to matter.

Changing the paradigm for how applications are built and deployed is the key innovation that docker is offering us, but as you point out, there are still plenty of problems to solve in this area.