Etcd, or, why modern software makes me sad • Hacker News Board

Re: Etcd, or, why modern software makes me sad

#111

Post by jacques_chester » Tue, Jul 14, 2020, 5:23 PM UTC

listennexttime wrote: post #29

hoebbz wrote: post #11

Earlier quoted context omitted.

What is dishonest/revisionist about the statement you have quoted?

How tedious to have to constantly refute FUD when it's easy to find the answers with Google. Anyone involved in Kubernetes, near CoreOS at the time, or really anywhere in the space at the time (instead of looking back at it with anger), knows this all to be false. CoreOS was setting direction for etcd, and understandably adding features for one of its bigger users (and in fact, some of those features are used by thin…

Of the folks heralded as "founders": Brendan Burns is at Microsoft, Craig McLuckie and Joe Beda are at VMware via the Heptio acquisition.

Google is still the plurality contributor, followed by Red Hat. If you count Red Hat and IBM jointly, they overtake Google[0].

Disclosure: I work for VMware, which competes with Red Hat/IBM.

[0] https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var...

Re: Etcd, or, why modern software makes me sad

#112

Post by epse » Tue, Jul 14, 2020, 5:23 PM UTC

kminehart wrote: post #13

I really dislike articles like these. I don't think the author is interested in having any kind of productive discussion or criticism. There's a million reasons to hate Kubernetes, the author couldn't be bothered to venture beyond the lowest hanging fruit (yaml)? If I could downvote this I would.

But it's not about kubernetes. It's about simple API's becoming complicated for no reason (according to the author, I have no experience on etcd) using etcd as an example

Re: Etcd, or, why modern software makes me sad

#113

Post by ddevault » Tue, Jul 14, 2020, 5:24 PM UTC

zaphar wrote: post #110

ddevault wrote: post #59

Earlier quoted context omitted.

Name a single piece of good software from Google.

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.

Re: Etcd, or, why modern software makes me sad

#114

Post by MorganGallant » Tue, Jul 14, 2020, 5:25 PM UTC

Summarized by GPT-3 as "Etcd is a cool thing, but some bad people took it over and made it worse."

Re: Etcd, or, why modern software makes me sad

#115

Post by outworlder » Tue, Jul 14, 2020, 5:25 PM UTC

> In 2015, an unrelated tool called Kubernetes was released by Google (but, really, by Xooglers). I would go so far as to say that Kubernetes (or, as the "cool kids" say, k8s) is the worst thing to happen to system administration since systemd.

Oh for crying out loud. This Kubernetes bashing is getting so old.

Frankly, I think it's the best thing that has happened in the past few years. Boohoo it requires some YAML. Yeah. And then you get lots of value out of the box.

Systemd bashing is a bit more deserved, but this horse has been dead for a while now.

And there's also some CoreOS bashing too. CoreOS is/was spetacular.

Re: Etcd, or, why modern software makes me sad

#116

Post by outworlder » Tue, Jul 14, 2020, 5:26 PM UTC

jonfw wrote: post #70

ixtli wrote: post #47

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.

> What's wrong with the YAML?

Nothing at all. Until you start 'templateizing' it (looking at you, Helm).

It's definitely better than JSON (it can even have comments, imagine that). Most people don't bother reading the spec or even examples though, and don't realize how good it actually is.

Re: Etcd, or, why modern software makes me sad

#117

Post by jonfw » Tue, Jul 14, 2020, 5:28 PM UTC

ddevault wrote: post #89

jonfw wrote: post #77

Earlier quoted context omitted.

Gmail, google maps, and google docs are all excellent

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

Re: Etcd, or, why modern software makes me sad

#118

Post by dekhn » Tue, Jul 14, 2020, 5:28 PM UTC

ddevault wrote: post #105

dekhn wrote: post #101

Earlier quoted context omitted.

I'm not sure what you mean by debatable loyalty. The creators of the language have all worked at the company for more than 10 years and support the product for internal users. Can you put your grinding axe away and stick entirely to facts and technical merits?

Look, Go has way more to do with the experience of its creators than with their contact with the engineering culture of Google. The influences from Plan 9, Inferno, Limbo, and so on are all extremely apparent in Golang's design and were all born outside of Google. Very little of Google's spirit made it into Go.

I don't know how you got from "debatable loyalty to Google" to "the language was mostly inspired by Bell Labs tech, rather than Google", which is perfectly fine. But it doesn't explain your animosity and refusal to discuss based on technical merits, rather than just (what is clearly) axe-grinding.

Note that Go ended up being a major language within Google for a wide range of systems (even replacing systems built previously by the Go developers, such as sawzall), so rather than saying "debatable loyalty to google", might it not be better to say that the developers worked to transform Google from the inside to be less dependent on C++ and Java?

Re: Etcd, or, why modern software makes me sad

#119

Post by outworlder » Tue, Jul 14, 2020, 5:30 PM UTC

Macha wrote: post #71

jeppesen-io wrote: post #32

Earlier quoted context omitted.

I've grown to think its a very vocal minority that objects simply ideological reasons, then finds techincal reason to back that up Even https://nosystemd.org/ mostly just lists bugs After moving all my services from varius init systems to systemd, I'd never go back

I'm mostly a happy systemd user. Unit files are much easier to work with and more consistent than init scripts, the faster bootup (at least on my arch and Ubuntu systems, maybe you could make Gentoo even more minimal with initscripts), and the container/isolation features won me over. That said, I can understand the objection to software that would previously support BSD or macOS now only providing systemd units or d…

Unit files are great. SystemD should have stayed there. But then it handles networking(including configuring network interfaces), and time synchronization, and name resolution, and the kitchen sink.

Re: Etcd, or, why modern software makes me sad

#120

Post by ddevault » Tue, Jul 14, 2020, 5:30 PM UTC

dekhn wrote: post #118

ddevault wrote: post #105

Earlier quoted context omitted.

Look, Go has way more to do with the experience of its creators than with their contact with the engineering culture of Google. The influences from Plan 9, Inferno, Limbo, and so on are all extremely apparent in Golang's design and were all born outside of Google. Very little of Google's spirit made it into Go.

I don't know how you got from "debatable loyalty to Google" to "the language was mostly inspired by Bell Labs tech, rather than Google", which is perfectly fine. But it doesn't explain your animosity and refusal to discuss based on technical merits, rather than just (what is clearly) axe-grinding. Note that Go ended up being a major language within Google for a wide range of systems (even replacing systems built prev…

I retract "debatable loyalty to Google". I meant something more along the lines of "debatably attributable to Google's engineering", i.e. a statement directly in support of my main argument.