vandal_at_your

Worked for them in the Herndon DC. Forget the name of their lovecraftian ticketing/control interface (which was always breaking) but it was hands down the worst interface I've ever worked with. Their remote SA team was not very good either. The supply/parts folks serving DC techs earned bonuses on having bad parts recycled into production and the parts delivery was not managed properly. One xmas I saw the same motherboard 5 times after returning it as defective each time. I resigned and was then fired. Only place that ever happened. Was so happy to leave I didn't care but it has come back to haunt me once or twice.

Nope. https, hybrid crypto and pub->free CA's are the largest backdoor into internet traffic ever (accidentally) devised. The standardization on https for everything (including alt app protocols (dns,etc...)) is very apparently an info grab.

Sym crypto is the only answer (Schneier,DJB) people have been trumpeting this for years.

When you demonstrate that your ECNL (equally crappy new language) merits an investment of time guaranteed not to break in perpetuity against programmers in the future and changing standards I'll make an effort to learn it. Mind, it must be as free (to use,modify,permute and as low level) ~ C. I must be able to do what I need to do without being second guessed bc it's dangerous. There are some people who know when to be dangerous and slowing us all down to the speed of the slowest bootcamp grad or most avaricious exploiter of minimal talent isn't progress. Otherwise I'll stick with the libraries I know, trust, and have written in C. This article is great mudsticking btw.

Chrome or firefox. Egregious wastes of my time, 90% inaccessible, untrusted interpreters of untrusted code.

Pushing this language and Go as required, responsible, NG languages is another one of the foibles of the cloud/web and it's owners. For those of us in HPC and scientific compute where is the practical reason to switch from C/Python and the unix toolset?

Fuck the idea of the browser as interpreter for untrusted code.

For me automation was learned behavior in lockstep with my ability to solve problems via programming. It eventually became automatic: to the point that my own patience with manual repetition and documentation of manual processes is minimal. This latter attitude does not do me any good in the enterprise infotech world. Especially in heterogeneous environments or where I don't have front to back visibility. I'd argue that while being able to automate is a great good understanding the business constraints and making good decisions about where you work becomes critical if you must trade toil for time.

I'm torn on this opinion. From 20 years of experience I can see where kubernetes fails and seems absurd (internally routed and natted networks with terrifying complexity and design, obtuse declarations in yml/json that hide more ugly complexity). Kubernetes tries to do too much for too many. OTOH, there are some really nice infrastructure simplifications which can be achieved using k8s that didn't exist previously. Like any tool it can be used in a sane way or made into monstrosity.

Also surprised to see this at HN. The approach to automating interactive applications based on pty superpose (and I/O direction) coupled to a pattern->action model is an extremely old fashioned approach. 20 years ago expect was an invaluable tool though. The model for developing cli tools has changed so much in reaction that very few use cases for 'vanilla' expect remain. Not to mention that TCL is not a very popular PL and unlikely to make a comeback.