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

471–480 of 648 posts

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

#471

Post by kelnos »

deleuze wrote: post #450
IggleSniggle wrote: post #186

Earlier quoted context omitted.

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.

I think the parent meant that all of those have things (like scala.js) that allow you to write in the JVM language and compile to Javascript.

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

#472

Post by blixtra »

csours wrote: post #407
blixtra wrote: post #269

Earlier quoted context omitted.

Chris from Kinvolk here. Happy to see you're having success with Flatcar. We, of course, agree that CoreOS Container Linux was a huge success. The uptake that we've seen in Flatcar usage, especially since the CoreOS EOL date on May 26th, has been extraordinary. So from what we a can see, the market is there for a minimal Linux for containers and and we're happy to continue filling that need with Flatcar.

Do you have any resources for understanding OSS/FOSS around minimal Linux distributions for containers?

I'm not exactly sure what you're asking. But Flatcar Container Linux is completely open source. In fact, everything we do at Kinvolk is. We do not build open-core products.

For example, we've gone a step further than CoreOS did and have a fully open-sourced update server, Nebraska (https://github.com/kinvolk/nebraska). We also generate a list of contents and licenses for each build. Here is an example from the most recent stable: https://stable.release.flatcar-linux.net/amd64-usr/2512.2.1/...

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

#473

Post by tambourine_man »

juliend2 wrote: post #344
tambourine_man wrote: post #324

Isn’t Etcd Apache licensed? Don’t like the direction it’s taking? Fork it. Is your fork not getting much traction and community support? Maybe you’re the edge case.

People think it's easy to create a durable fork that will gain enough traction to live on many years (in a stable manner) and attract contributors. It's not. Just look at the tons of forks on github for abandonned opensource projects. Let's say there are 10 people willing to fork it to keep it simple as it was previously. Where is the go-to place for that to happen in the open source world?

It's very hard, that's what I was trying to say.

In your 10 people example, it seems that there are a few problems to me: - finding like minded peers - getting critical mass (are 10 enough to maintain the fork?) - getting them all to agree on what subset of features to keep

If I were in the market for a fork, I would search Github first before forking my own, so I think the first item is basically solved. The second varies on a case by case basis, of course. The third seems more critical to me, probably dispersing the effort more than anything else.

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

#474

Post by dijit »

Nextgrid wrote: post #462
pm90 wrote: post #412

Earlier quoted context omitted.

Your answer to everything I said is “actually, it’s not that hard without kubernetes”. Maybe it’s not for you. For most developers, it absolutely is. And that’s why kubernetes is popular. Fads don’t form out of thin air. There’s always some value that they provide. To someone experienced with setting up infrastructure, the tasks may seem trivial, and the value add is low. For others who don’t, having a dead simple wa…

I am approaching this from a developer's perspective. Kubernetes and similar (even local Docker) introduces an extra layer of indirection that you often have to fight with. Sometimes it's worth it, sometimes it's not. For me, if my application is misbehaving in production, I prefer being able to just SSH into the machine and figure out what's wrong than fight with the container layer, its authentication system, comma…

I'm an infrastructure type and everything you said rings true for me.

Kubernetes and abstractions of its ilk (shipping containers for example) have a place, but every abstraction comes with some form of trade-offs, be that performance or transparency.

Dealing with a node brown-out in kubernetes is much worse than dealing with a network, host or service outage because the troubleshooting steps involved evolve fractally.

That said, obviously there is value- but it's good to critically assess the value instead of just jumping in.

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

#475

Post by rodgerd »

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 key point of the article is not really being addressed here:

Perhaps if the author wanted their key point addressed they could have tried focusing on it, rather than on an ill-considered spray across a group of largely unrelated bugbears.

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

#477

Post by bfb09 »

chris_wot wrote: post #411
neurostimulant wrote: post #312

Earlier quoted context omitted.

You should come join the fun! In order to deploy a web app in 2020, one must write his frontend using react and typescript that would transpile the code into a nicely bundled and minified javascript and css files along with thousands of your 3rd party dependency libs. Yes, you heard that right! I just counted the number of libs on the node_modules in one of my small side project and it's over 1000s. You might also wo…

I'm genuinely curious - do you really have to do all of that? Why not just ignore the frameworks and technologies that overcomplicate things and use what works best for you? I am wondering why someone just hasn't forked etcd if it is truly so awful now.

Yes. If you don’t, and scp a Perl script to run under supervisord that meets the business requirement in three days instead of three months of microservices strategy, you are accused of being so hopelessly junior that you are unemployable.

I have witnessed that firsthand. Despite the anecdote being backend, I’d bet my 401(k) it’s the same up front.

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

#478

Post by apta »

cmrdporcupine wrote: post #459
apta wrote: post #413

Earlier quoted context omitted.

> By falsely representing a _remote_ resource as if it was a _local_ one we open a whole can of worms I've heard this argument before, but how does gRPC itself cause this issue to manifest? I'm curious to hear what your opinions are on a better alternative, and how not to represent a remote resource as a local one.

You could use gRPC responsibly, yes. But the fact that it presents the remote resource in an API which resembles a local object means that programmers often get lazy in the manner of which they think about these things. The REST semantic is supposed to make this more explicit. A remote object is not an object in your program or even your computer. It's something you're taking from something that is computationally mi…

Thank you for taking the time to write this up, and the interesting anecdote.

What I don't see though, is how is making a (g)RPC call any different from making a REST call? Like you said, the REST call is supposedly more explicit, but at the end of the day, it seems more of a convention and some hard underlying difference. What's the difference between `httpClient.get("...")` and `grpcClient.foo(...)`?

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

#479

Post by munchbunny »

MaxBarraclough wrote: post #452
markus_zhang wrote: post #288

Earlier quoted context omitted.

Yeah exactly, and we can also pick the features we need in a language. E.g. C++ is super complex after C++/11, but we can still just pick a small subset to make it easier.

> we can still just pick a small subset Unless you have to work with legacy code or libraries.

Then some poor soul gets to wrap the old patterns into the new patterns!

But seriously, if modern C++ has one thing going for it, it has a great backwards compatibility and forward refactoring story.

I'm not a huge fan of the "evolved" syntax, and I rarely use C++ anymore, but I like modern C++ substantially more than C++03, which was where I first cut my teeth as a programmer.

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

#480

Post by cmrdporcupine »

apta wrote: post #478
cmrdporcupine wrote: post #459

Earlier quoted context omitted.

You could use gRPC responsibly, yes. But the fact that it presents the remote resource in an API which resembles a local object means that programmers often get lazy in the manner of which they think about these things. The REST semantic is supposed to make this more explicit. A remote object is not an object in your program or even your computer. It's something you're taking from something that is computationally mi…

Thank you for taking the time to write this up, and the interesting anecdote. What I don't see though, is how is making a (g)RPC call any different from making a REST call? Like you said, the REST call is supposedly more explicit, but at the end of the day, it seems more of a convention and some hard underlying difference. What's the difference between `httpClient.get("...")` and `grpcClient.foo(...)`?

The latter encourages you to model things as remote procedure calls, the former, well, in my experience it's open to incompetence and abuse, too, so... ehh... but done properly... well, go read the Roy Fielding paper :-)

I mean, internally at Google we have load balancing for grpc (I'm sure the outside world does now, too, but it was new to me when I joined) -- but load balancing HTTP requests containing readable JSON or XML documents, that's far more sysadmin friendly, wouldn't you say? Off the shelf infrastructure, nothing exotic, easier to monitor. Same goes for caching, for proxies, etc.

Being able to just stick a URL for a given resource in your browser, or hit it with wget/curl to read it, that's a serious bonus.

In general URLs follow conventions similar to those down by our Unix forefathers, when they designed the filesystem API. We are all familiar with this model. And in some ways REST done right is very Unix philosophy -- provide a consistent model upon which a bunch of little tools can interoperate.

I could go on... have to go put my daughter to bed tho

Post reply on HN