Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Etcd, or, why modern software makes me sad

roguelazer.com

Post reply on HN
Print view View original

441–450 of 648 posts

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

#441

Post by mekoka »

bfb09 wrote: post #146
mvanga wrote: 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…

It's a shot across the bow at the Kool-Aid which everyone here has imbibed to some extent. Of course they're going to shoot the messenger. When I clicked this thread I said out loud to my team, "oh, this should be good," and I hadn't even fathomed precisely how predictable the discussion would be. It's so far removed from any consideration that it lands something like explaining to an American that they're a subject…

You should also consider that the contrarian nature of HN would set it up to exactly the opposite reaction had the post expressed the reverse of its current positions. The big irony is that it's not inconceivable that it would involve some of the same actors voicing different opinions.

> "the incentives of modern software engineering value complexity to artificially strengthen a software engineering job economy"

Not sure I would agree. Hanlon's razor comes to mind. To me, the referred complexity is reminiscent of a number of other complex patterns that somehow found their ways in software engineering, out of possibly good intentions. Regardless, an idea needs to be sold and when the marketing is well executed the community will ingest the kool-aid. Which it then tries to digest for a few years. Then begins a game of chicken that consists in not being the first to admit that you're in pain, out of fear of being branded an infidel, or out of sunk cost bias. Eventually a few courageous and influential souls finally spit it out in disgust and scream "wtf is this shit?!?" Then the rest awakes from the common stupor and a holy war ensues. I still remember SOAP. I still remember with what verve I was sold Scrum.

As for Kubernetes, only time will tell.

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

#442

Post by pwdisswordfish2 »

mvanga wrote: 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…

"... of all major software components today."

Thankfully, we still have the "minor" components to ourselves.

Popularity has its downsides.

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

#443

Post by IggleSniggle »

icedchai wrote: post #254
gcbw3 wrote: post #238

Earlier quoted context omitted.

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.

my team (in a large enterprise) uses js for scripts using a shebang interpreter declaration, eg

``` #!/use/bin/env node

console.log("hello cli") ```

While it does depend on node, and there are arguably better crossplatform languages for this purpose, it is a zero-tool chain use case that is very convenient for us.

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

#444

Post by amarshall »

jedberg wrote: post #260
fwsgonzo wrote: post #163

Earlier quoted context omitted.

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.

>> a VM

> Containers

These are not the same thing, and have different security guarantees.

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

#445

Post by inopinatus »

cytzol wrote: post #433
inopinatus wrote: post #424

Earlier quoted context omitted.

Containers share a platform. They increase attack surface by supplying a vector to any neighbour, by being something that can be attacked at all, and by requiring another control plane that requires credentials, making it a social engineering opportunity as well as being another component that itself can be vulnerable. They are not an additional shell of defence, they do not reduce your blast radius.

> They increase attack surface by supplying a vector to any neighbour Could you explain what you mean by this? I'm still not getting it. Here's the example I have in mind: I have one application listening on a TCP port, and another one listening on a different port. I don't want the first application to talk to the second application. If they're just two processes on the same machine, they can both see each other, an…

Trusting the isolation like this is absolutely misguided, to the extent that it’s in conflict with understanding how computers work. Those who do not remember rowhammer or spectre and their kin are doomed to repeat them.

As for your example, there’s no difference between that and OS mediated mandatory access controls, separation of uids, chroot etc. Those capabilities are present irregardless of whether you’re using containers.

Anyone selling you on containers as a security measure is pitching snake oil. They are a resource allocation & workload scheduling tool. They may help applications avoid inadvertently treading on one another’s toes e.g. avoiding library conflicts or easing the deployment of, say, QA and showcase environments on the same metal, but it’s intrinsically a shoji wall.

There’s even a cultural downside, since developers may make exactly these flawed assumptions about runtime safety, or hard-code paths for config files rather than making them relative to deployment location, make assumptions (implicit or otherwise) about uids and so on, i.e. containers can breed sloppy dev practices.

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

#446

Post by abernard1 »

lemmsjid wrote: post #435
abernard1 wrote: post #327

Earlier quoted context omitted.

> Now I can just grab a generated client in a language of my choice. But you can't curl the state of your infra component without creating a program and downloading the client artifacts. This is a very big step backward from an operability standpoint. > because there's a thousand interpretations of REST out there ...but there weren't a thousand different interpretations of the etcd API out there: there was exactly on…

Yeah I don't disagree, I was mainly pointing out that there isn't a black and white 'grpc = bad' argument. Especially since I believe grpc does take steps to mitigate some of the RPC issues you'd have with, say, Thrift. For example having the REST gateway so you can support the curl scenario without any extra work. (For example when building my own Thrift-type services I would do extra work to have a mini REST API fo…

> For example having the REST gateway so you can support the curl scenario without any extra work.

I would agree with you except for one thing--it's very clear that's a second class citizen. There is this totally extra thing to support the original use case of etcd, and it comes with all the extraordinary quirks of how gRPC protobuf -> JSON serialization works (a strong term in my opinion).

It is very very hard for me to not see an unintentional conspiracy to push this very bad standard of gRPC. It does NOT make 99% of real-world programs faster. It does not make operations easier. It is not even a "data" format at all: go try changing an enum in downstream systems.

The standard is bad. Objectively, terribly bad. Someone somewhere on HN said that "Google was a ball-pit for gifted children." I kinda laughed at that, but really, after k8s and protobuf3, I won't even grant "gifted".

Google is a ball-pit for autistic children who can be funded by their monopoly on search. I'm tired of dealing with their protocols that make everything worse.

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

#447

Post by Foxboron »

GekkePrutser wrote: post #426
Foxboron wrote: post #386

Earlier quoted context omitted.

>The issue I have with systemd was mainly related to its heaviness not really fitting in with Arch's simplicity. Arch is a pragmatic distribution first and foremost. If we can build systemd, and ship it as-is to have a complete init, and more features along with it, that is much more enticing then the alternative. > I think it (openrc) would have been a good choice for Arch, for me it would have been better than syst…

I understand, and it was not my intention to drag the systemd discussion up again. It was just one of the many things I thought of after reading cwyers post which really resonated with me, and the parent article as well. And there are things I do like about systemd, I also have to say. Especially the way you can pass a variable to a server with @, like run 2 instances on different ports. I know very well that the rc…

>and you support millions

I'll be amazed if Arch has a million users. Our napkin math using steam user statistics put us on around 500k-600k users.

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

#448

Post by jchw »

mvanga wrote: 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…

The problem, as I pointed out elsewhere, is that the post makes very few constructive comments and presents a lot of opinions and assertions without justification or reasoning, making it extremely hard to actually make meaningful comments about. As someone else pointed out, if it were an HN comment, it would be flagged.

I don’t agree that this is a statement about complexity, so much as it is a rant about the author being inconvenienced by technology they personally deem pointless and unnecessary. If the CoreOS comments aren’t a sufficient red flag, the HTTP/2 ones really ought to be. Also, some etcd users debate their assertions about newer versions being more complex internally. On the other hand, its difficult to argue with overly cynical type attitudes.

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

#449

Post by jazzyjackson »

rubber_duck wrote: post #399
jazzyjackson wrote: post #264

Earlier quoted context omitted.

It hasn't been a big detriment for me as someone learning Typescript on their own, but it is another moving target for looking up "how do I do x..." and finding most of the forum posts are a little outdated and the latest version of Typescript has a different/better way of doing things than just a year or two ago. I find myself scrolling through github issues comparing my tsconfig to figure out why my stack behaves d…

That was my experience with TS maybe two years ago - at this point project scaffolding tools are good enough to generate sane output that I spend a little bit of time upfront but then keep plowing away. Maybe I got better at it as well - but I haven't kept up with TS news in a long time and I don't feel like I'm missing out on stuff or encountering things I don't understand. I've written >50k LoC of TS in last few mo…

Yeah I probably shouldn't complain, I've written less than a couple thousand LoC so I'm still googling a lot, but TS has definitely paid for itself in code clarity already.

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

#450

Post by deleuze »

IggleSniggle wrote: post #186
dynamite-ready wrote: post #153

Earlier quoted context omitted.

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…

TypeScript is a funny one. I love the language, but at the same time, I totally agree with the premise that it is unnecessary complexity! And yet I swear by it. I can't explain why there's not more cognitive dissonance there. JavaScript taught me to love async, then functional programming, and TypeScript taught to me to love static types. I'm now desperately wishing for a world of OCaml/Haskell, but where are you goi…

All the JVM languages you list aren't transpiled. They target JVM bytecode just like Java. They're first class, even if Java obviously gets the overwhelming amount of VM level support. Engineers working on the JVM are definitely aware of and want to support non-Java langs.
Post reply on HN