Live data from Hacker News

Etcd, or, why modern software makes me sad

roguelazer.com

251–260 of 648 posts

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

#251
post #218

Earlier quoted context omitted.

Off the top of my head: Gerrit, Bazel, Go, gRPC, Kubernetes.

I've addressed most of these already. Ever had to maintain a Gerrit instance? Bazel is the most complicated garbage I've ever had the displeasure of using. It takes tens of thousand of lines of support code just to add a new tool to your toolchain. Google does not get credit for Go's design. gRPC, k8s: see TFA

> Ever had to maintain a Gerrit instance?

Yes. [1]

> It takes tens of thousand of lines of support code just to add a new tool to your toolchain.

No, I've added custom compilers and languages to Bazel, and it was not nearly 'tens of thousands of line'. Sure, it's complex, but such is life with inversion of control. It's difficult to get around this complexity if you want to follow the design goals of Bazel.

> gRPC, k8s: see TFA

The article says nothing about why gRPC or k8s are bad. It just uses very emotional language to handwave into the general direction of 'bloat' and 'too complex'.

[1] - https://cs.hackerspace.pl/hscloud/-/tree/devtools/gerrit

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

#252
post #133

This is one weird comment section. There are people attacking the author for a statement made about CoreOS, and for some hate towards Kubernetes. The key point of the article is not really being addressed here: vested interests from large companies are able to introduce huge complexity into simple, well-designed projects. While the complexity may be good for some end that said vested interest has in mind, they are al…

I love k8s, think it’s the best thing that happened to distributed computing since .. sliced bread? Anyway, it’s good, but I don’t disagree with the author I just have a different perspective. I see k8s as a vehicle for learning about distributed computing not just for me but the industry as a whole. Same thing about Linux, it’s just a stepping stone for node management and has served us well in figuring out a bunch of problems. K8s removes a lot of duplicated effort in the learning process for the industry, just close your eyes and think back to the past decades of ESB wars.. that was a waste!

“Under the radar” comes a new generation of better systems and components that learns from these learning vehicles of computing and will change how we deliver services fundamentally, but without k8s and Linux we would never have gotten there. Open source RISC-V co-evolved with seL4, WASI, webassembly and NATS comes to mind, but I’m sure the future will take its own path.

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

#254
post #238

Earlier quoted context omitted.

What is unnecessarily complex about TypeScript? It's JavaScript, with static typing plus type inference, and pretty nice generics. The ecosystem of modern JS surrounding it is horribly complex but TypeScript itself seems like a fairly straightforward programming language.

describe the steps to release the simplest ever code in javascript to production: write a js file, host it, done. The same thing in TS adds at least one step (not to mention the rest of the tooling you will want) So while a prefer it over JS, there's no arguing that it is more complex as now you require a build step for a language that only exist because people wanted a language without a build step.

Almost nobody does Javascript without a build step these days, unfortunately. I miss those simpler days.

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

#255
post #84
post #35

Author is really good at discrediting themselves straight off the bat in one sentence: > for a ~~bullshit~~ unsuccessful project called CoreOS Container Linux that was EOL'd several years ago CoreOS was actually quite successful to me as an outside observer. It had decent paid user base as well as people using it without paying. It has showed people that Chrome OS can be used to build atomically updating host OS with…

I want to make constructive comments about this blog post, but the way it conducts itself makes doing so extremely difficult because nothing about it is constructive. This is troublesome for HN - I almost wish I could flag it for being impossible to discuss without turning into a flame war. It feels like several disjointed complaints based on a desire to jam any and all inconveniences into a unified narrative about M…

I have worked with (and under) big names in system software and so many of them think saying "terrible", "garbage", and "trash" will motivate people to do productive corrections or improvements. Nope.

Times have changed and the very people he criticizes are infinitely better at branding and inspiration. There's a reason they're the ones gaining traction.

Like you, I want to be constructive, and I do agree with the author's core complaints. He just doesn't realize he's actively self-sabotaging and harming his own reputation.

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

#256
post #229

> 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. This, I think, is the key to understanding this whole rant. It is entirely of a piece with the anti-systemd crowd, and I think understanding what was really going on there hel…

You hit the nail right on the head here.

I too am sick of people telling me to accept ubiquitous containerisation (snapd), locking down of filesystems (macOS), overly complex init systems (systemd (1)), lack of server access (manage it via ansible/k8s, not ssh). Usually the arguments given are "it's necessary 'for security'", "this is where everything is going", "you have to trust the vendor". This is not the spirit of Linux or open source. I totally see the effect you mention of paid maintainers forcing projects into their employer's direction. As such I found it sad when even Arch fell to the systemd camp. And it's one of the few things it really enforces, it supports 6 different network initialisation methods for example, where all other distributions just pick one and go with it.

(1) I'm not all anti-systemd by the way. I agree init was bad. But I think other systems like OpenRC are way easier to work with.

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

#257
post #181

Earlier quoted context omitted.

What if 'advancements' were anything but? How would we know whether we're advancing a nascent engineering discipline in the best way possible? Is public cloud, an optimization for a certain calculus of engineering resources, the optimal form of computing delivery? There's an underlying presumption about computing progress that has weaseled its way into your thinking, and the devil of it is that there are vanishingly…

You seem unfamiliar with the mystical energy force that always ensures the direction of "progress" is always positive for everyone. It's very un-techy to not believe in this, you need to immediately forget enough social science subjects so you can get back to the purity of ignorance.

That demo from 1968 ruins everything (https://www.youtube.com/watch?v=yJDv-zdhzMY), like the illusion of progress.

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

#258
post #133

This is one weird comment section. There are people attacking the author for a statement made about CoreOS, and for some hate towards Kubernetes. The key point of the article is not really being addressed here: vested interests from large companies are able to introduce huge complexity into simple, well-designed projects. While the complexity may be good for some end that said vested interest has in mind, they are al…

Agreed. I saw it as a general lament against over-engineering. I don't think the point got lost in the super specific example... You could just as easily level similar rants against the likes of React and it's wider ecosystem, Tensorflow, Typescript (many will disagree), Docker... I'm sure others have their own bugbears. Much of this is subjective, of course. But to me, it feels like software development is trending…

> towards unecessarily complicated development processes and architectures

please note that what's "unnecessary" for you is not necessarily unnecessary for others.

this is an important point.

i guess what these projects need is a way to communicate explicitly the costs of maintenance and developer mind-share when adding more complex features to their product.

Because especially as small dev team it is difficult to figure out these costs during a short evaluation of the software, is not easy to pick the best tool for the job unless some members have got experience in some previous job with these tools.

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

#259
post #185
post #133

This is one weird comment section. There are people attacking the author for a statement made about CoreOS, and for some hate towards Kubernetes. The key point of the article is not really being addressed here: vested interests from large companies are able to introduce huge complexity into simple, well-designed projects. While the complexity may be good for some end that said vested interest has in mind, they are al…

Then the author should have focused the article. If their goal was to address that, then don't take a left-turn into hating on Kubernetes for no reason, before even reaching the point trying to be made. > Funding and adoption (in the extreme, some might say hijacking) of open-source projects from large corporations dictates the direction of all major software components today This is because large corporations are th…

> gRPC wasn't added for no reason, or because politics; its a sister CNCF project, and would increase the performance of the API surface, which greatly benefits all of its users.

gRPC (Google RPC) was absolutely added because of politics. Yes, it's performant, but let's not kid ourselves that gRPC wasn't picked because it falls nicely into the orbit of Kubernetes and the Google ecosystem. It's also why etcd can even threaten to remove support for HTTP+JSON (!!!) in the API, when it costs nothing at all to keep that support. This is exactly what the post is bemoaning.

> Did the author join in on the discussion when these changes were made? Did they voice their concerns?

Did you? Did anyone outside of a few people in a SIG or an RFC? This is also the complaint the author is obliquely getting at. Google may be 95% of the etcd _volume_, but they are basically 0% of the institutional users. That a small group of people can push a project in a direction that uniquely benefits them while adding an incidental complexity tax for everyone else is worth complaining about.

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

#260
post #133

This is one weird comment section. There are people attacking the author for a statement made about CoreOS, and for some hate towards Kubernetes. The key point of the article is not really being addressed here: vested interests from large companies are able to introduce huge complexity into simple, well-designed projects. While the complexity may be good for some end that said vested interest has in mind, they are al…

I think everyone here remembers that time they wrote a simple HTTP server, that just works, and would continue to work today. If anything, I hope that we can recognize that there has been advancements in computing. Back in the day you would be open to attacks left and right. It was the wild west back in the day. Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone bre…

> Today, you can take that tiny webserver and put it in a VM, and voila, now it doesn't matter if anyone breaks in

This is a dangerous viewpoint to hold. Containers do offer some slightly better security, but they are not a silver bullet or anything close. There are still lots of ways to cause problems whether the software is in a container or not.

Post reply on HN