Hacker News Reader

Comment by pjmlp | Hacker News Reader

Not really, unless you're talking about specific Go developers, and even there, that is what the CI/CD pipeline is for.

No one should touch servers directly, unless for down tracking stuff or remote development, in which case, they also don't need to cross compile.

View on HN

Pretty sure lots of people still touch servers directly, and will continue to until servers are no longer a thing.

I mostly touch servers remotely

Sure, but then DevOps aren't doing their jobs.

No devs on production servers unless for tracking down issues, or servers configured for remote development.

Which in both cases, don't require cross compilation to start with.

There are less and less touching servers directly happening. Not only DevOps but the current raise of k8s and serverless deployments making it less relevant. There is also the security aspect of it.

The downside is that people (especially the ones who are just joining the workforce) are less efficient with the command line and more dependant on GUI. For example some of the junior devs do not know git cli anymore and rely on the VSCode plugin to interact with git. This becomes an issue when there is a bug in the plugin and you should use the CLI.

That is easy to sort out, like every git problem, clone the repo and start again.

I know SCM tooling since the RCS days, and couldn't be bothered to master git implementation details to fix broken repos.

Unfortunely we are stuck with git for the time being.

I agree with you based the amount of time someone needs to spend to fix a broken repo.

I just really like to understand the tools that I use. Maybe it is a waste of time.

Yes, we're shelling into k8s containers now

Or worse, when what you think is a big actually is a feature. I basically use vscode git only for staging and merging and sometimes not even that, when it has issues with hunks on the beginning of the file or whatever.

DevOps should IMHO not be a job role but a company philosophy.

The developer should alao maintain their software and deploy it. Has IMHO a lot of advantages

This comment leads me to believe that you’re used to working in one type of organisation to the point where you’re projecting it on your entire understanding of this incredibly broad industry.

Indeed, Fortune 500 consulting.

Everyone _should_ also have 100% test coverage, canary deployments, and local dev parity. Unfortunately, the real world gets in the way and means we don’t all work with optimal setups.

In that case, it starts by having a local environment that matches the OS of the servers.

Linux OEM vendors will appreciate it.

You’re running graviton arm locally? It’s all docker containers in the end, so that’s what you get.

No, and why should I?

I got into UNIX development back when the whole team shared a development server and we used telnet and X Windows for our "IDE".

No one was running SPARC, RISC System/6000, PA-RISC, MIPS, Eclipse MV locally.

When everyone keeps worshipping UNIX, maybe it is time to learn how grey beards used to develop for it.

> it starts by having a local environment that matches the OS of the servers

> No, and why should I?

These two statements are in direct conflict. CPU architecture is as much part of “matching the server” as operating system.

When I built software for SPARC, I was also running SPARC locally…

That's how I came up too. It sucked. It's good that it's being forgotten.

Reply on news.ycombinator.com