121–130 of 648 posts
I thought this was moderately-funny cheeky banter, but I wanted to see what implementation decision they were making fun of with this silly misrepresentain. Quote RFC 7541: "The static table was created from the most frequent header fields used by popular web sites." Oh.
I run k8s in production and I think this is a really bizarre axe to grind that sort of smells like someone who got upset by how steep the kubernetes learning curve is. Which, in a way, is understandable. > 1) Add hundreds of new failure modes to your software In my entirely anecdotal experience, it removes error modes. It turns out that just because k8s offers a feature (it offers many!) doesn't mean you're required…
What's wrong with the YAML? It's easy to read and write, concise, and generally has sane defaults meaning you don't have to be overly verbose.
I think the unnoticed problem is that the tailors (old school system administrators and dev ops) are being asked to become the managers of Old Navy (kubernetes cluster administrators). Their entire skill set is opposed to this new role. I can't really blame them for being frustrated.
To keep stretching my already thin analogy, there are still tailors in this world. However, most people buy their clothes at outlets like Old Navy. Whining about the quality of the clothes and the crummy manufacturing process at Old Navy won't change that.
Earlier quoted context omitted.
Bazel, gRpc, Guava, Go, Dart, I could go on but you technically only asked for one.
Bazel is fucking awful . Most miserable years of my career is when I was tasked with maintaining a build system based on it. Same for gRPC, which TFA also does a good job of shutting down. Google doesn't get credit for Go, Bell Labs does.
Earlier quoted context omitted.
Gmail sucks. They use it as a vehicle for anti-competitive "standards" and it's needlessly difficult to deliver mail to. Their new JavaScript-riddled frontends (which they seem to develop and then shrug off every couple of years) have awful performance and are terrible at doing what has ultimately a very simple task for 30 years. Google Maps is fine. OSM is superior technically but Google Maps only wins because it ha…
Engineering quality is about nothing other than meeting the spec- how well does google accomplish that? It sounds like you have some issues with the design itself, maybe some issues with the business practices. Those are issues with the spec, not the engineering. The engineering team delivers the spec, they do it smoothly, they do it at scale
Edit: you changed your comment out from under me and I fail to rouse the enthusiasm to reply to your new comment.
I run k8s in production and I think this is a really bizarre axe to grind that sort of smells like someone who got upset by how steep the kubernetes learning curve is. Which, in a way, is understandable. > 1) Add hundreds of new failure modes to your software In my entirely anecdotal experience, it removes error modes. It turns out that just because k8s offers a feature (it offers many!) doesn't mean you're required…
What's wrong with the YAML? It's easy to read and write, concise, and generally has sane defaults meaning you don't have to be overly verbose.
Earlier quoted context omitted.
Almost like with etcd, it started simple, but got expanded into a huge incomprehensible monster by the original developers. Politically and business-wise, systemd is a clear win for Lennaert and his clique, as well as the whole Redhat/IBM. But I am sure that future historians will view the impact of systemd on computing as largely negative.
The systemd/RH relationship is complicated. Red Hat doesn't use most of systemd's features--they don't even ship systemd-networkd on RHEL8, preferring NetworkManager instead. On the flipside, I see more use of systemd's features on Arch or Debian. I don't think you can frame systemd as some kind of RH trojan horse when so little of it makes it into RHEL/Fedora.
Earlier quoted context omitted.
Almost like with etcd, it started simple, but got expanded into a huge incomprehensible monster by the original developers. Politically and business-wise, systemd is a clear win for Lennaert and his clique, as well as the whole Redhat/IBM. But I am sure that future historians will view the impact of systemd on computing as largely negative.
> But I am sure that future historians will view the impact of systemd on computing as largely negative. I don't really think so. They probably will point out a lot problems with at some point somehow got fixed but it should be net-neutral or positive. The thing is todays linux is running manny services and to do so nicely you want to have some form of service manager which does startup/shutdown/restart/circicute bra…
It's a logical fallacy to assume, because systemd was the thing that came along and resulted in the problems in sysv being fixed, that systemd's approach or implementation were necessary, desirable, or the best option available.
Earlier quoted context omitted.
What's wrong with the YAML? It's easy to read and write, concise, and generally has sane defaults meaning you don't have to be overly verbose.
In the Kubernetes and Ansible/Salt world it's frequently templatized, and then you need to worry about indentation that you place or your template engine places. Every day I pray that Helm will incorporate support for jsonnet so I never need to touch YAML again.
I don't understand why you would want to directly edit markup language without parsing it. YAML's goal is to represent a data structure so that a human can interact with it. It accomplishes that goal well. If you want to edit that data structure programmatically- no markup language makes sense to use, represent the data structure using your programming language's native representations.
Earlier quoted context omitted.
My team ran about 50% of a Fortune 500 software company on CoreOS up until a few months ago when we migrated to Flatcar. We even paid a lucrative support contract while we ran it. I can count the number of major OS issues we had with it over several years on one hand- and we've had even better success with Flatcar so far. Calling CoreOS unsuccessful is a massive misunderstanding of the market.
Your company running on it (and not flatcar, heh) is what shows a massive misunderstanding of the market. Just because people buy snake oil, it doesn't make it a good product.
Clearly, people are using it successfully and enjoying it (or other similar products). Just because you don’t like it it doesn’t change the reality of the situation.