technicolorwhat

Yeah, we're also pushing for SSE for this kind of things.

The idea is nice and needed. However maybe the spec is a bit elaborate for me to adopt it immediately. I've been rolling my own for some time at some clients, for our kafkaesque/event sourcing patterns.

However what I used there was simple http stream/json stream like this:

- No start of [] but JSON newline entries a new line is an new entry

- Using Anything as an id (we've been using redis XSTREAMS as lightweight kafka concepts, just 64bit integers)

- have an type as an event, and versioning is just done by upgrading the type, ugly, but easy.

- We'er considering using SSE at this moment

Compaction is not something that I would do in the protocol I think I would just expose another version of it on a different url I think or put it in a different spec.

Hmm for me a course did wonders really. It really allowed me to better express my own needs and feelings and dial in the feelings of others.

What described above I've seen happen, but mostly with beginners or people that use this new found ideas as agenda but without actually connecting with the other, expecting miracles or use NVC as a tool for policing. Or people that were already manipulative in the first place, but now just try to use NVC.

It can also come off as manipulative in an already unhealthy situation, where the relationship consists of so much mistrust that bringing anything new to the table is frowned upon and already met with suspicion.

My personal take away from it was to ensure that I prevent destructive communication and prevent blame using words things like "You should have" because they don't give the other tools to work with and actually address the problem at hand. For me the bottom line of the book was that us expressing our emotions and needs to allow the other, if willing, to actually address the problem at hand. It also made me see that sometimes effective communication was blocked because I had to deal with my own things first.

Communication, empathy, and time to actually listen, is something that unfortunately in my culture isn't thought as a core skill.

> The depth maps we currently generate come from our hardware and software prototypes. And yes, we’re already at incredibly high levels. That’s because our “deep-learning algorithms” learn from all small errors and inaccuracies.

I like it that they quote deep learning algorithms

Let's outsource social care/s

Its almost like applying DDD bounded contexts after the fact.Breaking up your apps in their boundaries and moving them out on the storage level. I do have some questions though:

1. wonder what happens on the edge of the boundaries when a table does need data from another domain. And what if that domain/cluster is down?

2. How do they physically connect to the cluster? A seperate db connection?

Ah nice to hear from a rancher employee <3. Ah yeah, I totally understand the move, no blame there. But cattle was just amazing, it was easy and elegant!

There is no mention on LXC/jails which is ofcourse the biggest inspiration for docker, if I am not mistaken it also used lxc under the hood. That was already a good'ish product and but hard to configure and not for the mainstream at the time. Docker introduced AUFS and downloading of images which was added. I always saw docker as a properly marketed nicely ribboned lxc but mediocre implemented since they removed a lot of options at that time that were super useful like cpu limiting etc from std lxc.

I think docker itself had plenty of time to innovate. They could have solved the problem long before mainstream got a hold of kubernetes. They just didn't solve the actual problems users where having at that time, which was container orchestration across multiple servers. They went very very deep with a lot of drivers and API changes and what not. If I am not mistaken docker-compose wasn't even a part of docker first before it got bundled, someone else was solving docker's same-server orchestration problems.

Kubernetes is for a lot of organisations pretty difficult and way too much for a start. We used rancher for solving our problems which did a fine job, rancher got a worse when they made the move to Kubernetes.

In the beginning they (docker) also removed a lot of options like cpu throttling and configuration and such that LXC had from the start. They also had their own version (a shim) of pid 1, some point at the time. And other things that made it a little painful to properly containerise. I was often very frustrated by docker and fell back on lxc.

There was also something with the management of docker images like pruning and cleaning and other of much needed functionality that just didn't get included.

Also something with the container registries which I a this point can't remember (maybe deleting images or authentication out of the box or something that made it hard to host yourself).

Anyway I think it's failed because it failed to listen to its users and act upon them. They really had a lot of chances I think. I think they just made some wrong business decisions. I always felt they had a strong technical CTO that really was deep on the product but not on the whole pipeline from dev->x->prod workflows.

Darn it, I feel excluded, I am dutch and haven't opened any multiple back accounts yet. I probably should.

Thank you!