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.

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.

Comments URL: https://news.ycombinator.com/item?id=29523483

Points: 1

# Comments: 0

I like it that they quote deep learning algorithms

- Deploy a pod, some controller doesn't agree. Finding out the controller is a bit more difficult (why aren't the controller logs aggregated and share a common saga id/key). I understand the evented nature of k8s with its controllers, but still it makes it very hard to trace and debug. - Why is it so hard to see _everything_ that is in a namespace. - Why isn't the YAML typed and so elaborate. Or why can't we prefer a typed JS json/json5 since the actual objects are JS and adhere to a spec? - why are there specs in specs in the templates and templates? - Why is it `kubctl (nothing here) logs` and `kubectl get pods` - Deleting a pod and patching the finalizers?

I know this complexity is somehow needed but it would be nice if the 80% would be easy and the 20% would be possible. When it works it is fine. But when it doesn't its an absolute pain.

Also 80% of my time goes in the same repetitive tasks. Ideas are welcome!

Comments URL: https://news.ycombinator.com/item?id=29040216

Points: 1

# Comments: 0

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?

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.

Comments URL: https://news.ycombinator.com/item?id=28336470

Points: 5

# Comments: 6

Comments URL: https://news.ycombinator.com/item?id=28327290

Points: 2

# Comments: 0