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

341–350 of 648 posts

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

#341

Post by Foxboron »

amyjess wrote: post #223
candiddevmike wrote: post #55

Earlier quoted context omitted.

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.

So while Arch ships everything, and being Arch it doesn't really have a default, its recommended networking system isn't systemd-networkd but rather netctl, which is basically everything systemd-networkd should have been.

There is no recommended networkmanager.

`netctl` was explicitly written because systemd didn't have a network daemon. The past 3-4 years the community has in general recommended against using `netctl`.

It was never removed from the ISO because the releng maintainer didn't put that much thought into it, but I'm happy to tell you `netctl` was replaced with `iwd` on this month ISO release.

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

#342

Post by Nextgrid »

neurostimulant wrote: post #312
cmrdporcupine wrote: post #274

Earlier quoted context omitted.

I think it's pretty drastic to say "everyone here has imbibed" that Kool-Aid; I work in embedded, and am not super familiar with the frameworks he's complaining about, but I found the blog post entertaining nonetheless. Sometimes I feel like the people who are deep down in this "full stack developer" land should come up for air and look around at the bigger picture. There's a much bigger world of software development…

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…

> Of course you still need http or how else would your react frontend talk to your microservices?

Don't forget GraphQL on top of that, otherwise you're not really in 2020.

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

#343

Post by tannhaeuser »

dnr wrote: post #215
tannhaeuser wrote: post #33

> HTTP/2 a.k.a. SPDY is a comically bloated Layer 4/5/7 mega-combo protocol designed to replace HTTP. It takes something simple and (most importantly!) comprehensible and debuggable for junior programmers and replaces it with an insanely over-complicated system that requires tens of thousands of lines of code to implement the most minimal version of, but which slightly reduces page load time and server costs once you…

The misconception is the idea that anyone can easily implement a compliant HTTP 1.1 server, or even client. The protocol may appear simple on paper but parsing it correctly and securely is quite tricky. IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries and remove the illusion that interacting with HTTP bytes on the wire is a reasonable thing to do.

That's pretty much in the "cut out future generations from system programming for the web" territory, and complexity for the sake of complexity. Also, you have to implement HTTP/2 in addition to HTTP/1.1.

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

#344

Post by juliend2 »

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?

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

#345

Post by hyperpape »

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 author may or may not have the correct conclusion about over-engineering coming from big-co alumni, but if they can't get their one example correct, why should we discuss their post? Are their insults that novel?

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

#346

Post by giantrobot »

Gibbon1 wrote: post #244
greyhair wrote: post #203

Earlier quoted context omitted.

It makes me think of military contracting as a parallel example. (at least in the USA) The rules required to develop, build, and deliver military equipment to the US is exceedingly complex. And it isn't necessarily a benefit for the Pentagon, as much as it is for the established defense contractors. The barriers to entry in that industry are huge, purely based on the contracting requirements. So complexity (in tools…

My first boss (rip) had a internship with a defense contractor his junior year in college. They gave him one project. Design a cover for the air intake for an APC or some such. Easy!!! No not actually easy because of all the constraints. It had to be stowable. So a hard cover was out. It couldn't produce toxic fumes if it caught fire. So most plastics were out. Cloth was a problem because it couldn't get sucked into…

> I think military tech has a problem that it's trying to keep out with commercial drive tech which operates on a scale that a 1000 timers larger. Military produces a few thousand artifacts to commercials few million artifacts.

Not to excuse military contracting pork and cost padding, but this is a good point that a lot of people seem to miss. There's also the fact a military contract will be for a production run and follow on support.

So they buy a thousand full units and parts/tools to fix and maintain them up front. You can't just go to Autozone and pick up a new tank tread or parts for a jet turbine.

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

#347

Post by coldtea »

throwaway744678 wrote: post #332
icedchai wrote: post #254

Earlier quoted context omitted.

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

Now, that is a bold claim. Are there any stats on that?

"Nobody" here means few, or more loosely, much fewer teams than before, not "literally 0 people/teams".

And the group mentioned is (I deduce) not generally individual devs, enterprise devs building some internal thing, and so on but teams in companies doing public-facing SaaS, teams in startups, companies like Amazon/Google/Facebook/Apple all the way to AirBnB etc, and so on.

So, you don't really need stats for that.

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

#348

Post by Twirrim »

greyhair wrote: post #203
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…

It makes me think of military contracting as a parallel example. (at least in the USA) The rules required to develop, build, and deliver military equipment to the US is exceedingly complex. And it isn't necessarily a benefit for the Pentagon, as much as it is for the established defense contractors. The barriers to entry in that industry are huge, purely based on the contracting requirements. So complexity (in tools…

> And it isn't necessarily a benefit for the Pentagon, as much as it is for the established defense contractors.

As with many government related procurement systems, there is so much paranoia about abuse, and desire not to repeat various disasters from the past, that the system has by perceived necessity become complicated.

Of course it makes it frightfully expensive to the degree that few companies can actually throw the resources at it to be able to navigate it. The lack of competition can result in projects costing a large amount of money, and the buyers in the agencies having no real options to look elsewhere.

At an e-government company I worked for, we a service for the state that helped companies navigate the state's procurement system. We created a centralised place for all data to be gathered by the applicant, generating all the forms they needed, and provided a way for the applicant to track the state of their application. It introduced quite a change for the state, dramatically widening the potential pool of companies that could bid for contracts. Also pissed off quite a few of the already entrenched ones :)

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

#349

Post by sfgweilr4f »

Gibbon1 wrote: post #244
greyhair wrote: post #203

Earlier quoted context omitted.

It makes me think of military contracting as a parallel example. (at least in the USA) The rules required to develop, build, and deliver military equipment to the US is exceedingly complex. And it isn't necessarily a benefit for the Pentagon, as much as it is for the established defense contractors. The barriers to entry in that industry are huge, purely based on the contracting requirements. So complexity (in tools…

My first boss (rip) had a internship with a defense contractor his junior year in college. They gave him one project. Design a cover for the air intake for an APC or some such. Easy!!! No not actually easy because of all the constraints. It had to be stowable. So a hard cover was out. It couldn't produce toxic fumes if it caught fire. So most plastics were out. Cloth was a problem because it couldn't get sucked into…

Those constraints seem a lot more reasonable than what I've seen in other aspects of the business world. At least they are grounded in the realities of the actual purpose. Well, mostly anyway. I'll leave justifications for the $1000 left-handed hammers as an exercise for later.

I've seen (and removed) plenty of requirements that were put in the specification just because. Because someone needed X amount of Y technology in their projects for the year. Because it seemed cool. Because other people were doing it. Because they wanted it on their resume. Because. But not because it was appropriate to the project or its purpose.

I'd say the majority of the work I do now is pruning these nonsense "just because" clauses out.

Its entertaining at least. I regularly shake my head in disbelief as I go through a specification and wonder, "who hired these people?" or "Why is the person who hired them still working?"

Fortunately for me I also get to hand these questions back, much like the good uncle who only needs to uncle and not actually parent: "Here, have them back!" I say at the end of the visit.

All is well. Go pleasantly amid the wastes.

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

#350

Post by tannhaeuser »

derefr wrote: post #217
KaiserPro wrote: post #190

Earlier quoted context omitted.

HTTP2 fails for mobile clients. it shoves everything down a single TCP connection. This means that if you loose a packet (and 4g is lossy) it stalls the _entire_ queue. Instead of addressing the main complaint (that multiplexing everything down a single TCP connection is a fundamentally stupid idea) they come up with an entirely _new_ protocol. It also fails to understand what HTTP2 has turned into: a file transport…

To be clear, it's not like there are any HTTP/2- only servers in the world. HTTP/2 is something a client connection upgrades to. One might think of HTTP/2 and HTTP/3 not precisely as versions of HTTP, but rather as variants —HTTP/2 is "optimized binary HTTP, fixed-station profile" and HTTP/3 is "optimized binary HTTP, mobile-station profile." (Mind you, they are versions relative to each-other , because HTTP/3 is str…

I think if you're making this trade-off and "optimizing just the traffic going to these [big] sites—with a special protocol clients only use when speaking to these sites—makes the whole Internet faster", then I guess you shouldn't be surprised to be criticized by the majority (according to your own words) not having these problems, yet having to shoulder additional complexity for little or no benefit, and even only serving to increase asymetry on the web. Why can't the "big sites" (it's just Google who's behind QUIC anyways, isn't it?) not then create their own network and take their enormous traffic there? The web was created for easy self-publishing after all.
Post reply on HN