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.
You quit and then you were fired? How did they manage to do that - Virginia is a right to work state, you can quit any time. They can't fire you for.... quitting first?
Eh - this has happened to me. Literally word-for-word: "You can't quit! You're fired!"
I know it seems like it could be right out of a Simpsons episode or w/e but managers can have some pretty backwards egos. The same manager tried telling my colleagues that I had been fired and like 2-3 people were like, "Nope - actually he quit. Thanks for screwing us out of 2 weeks of project hand-off..."
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.
If I connect to a server via https and see it's certificate, I am confident that my communication is secure between me and the server hosting that certificate.
To validate the person holding that certificate is who they claim to be, how can I do that? By either getting their certificate out of band (impractical), or trusting an intermediate.
Lets encrypt doesn't make it any easier or harder to get an invalid certificate.
Now if the server wants me to authenticate, https has that built in. I can present my own client certificate, and if it's signed by somewhere the server trusts, it knows who I am. But how would a random server authenticate who I am? I'd personally rather use certificates or ssh keys or similar than usernames and passwords, but that's too complex for the average person.
Clearly I could have lost control over the key to my certificate, or the server could have lost theirs, there's not much you can do about that, no matter what type of authentication system you use.
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.
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?
I'm in the web field generally. Those I've spoken to outside of that field find Rust a much faster way to develop safe and stable programs that would have otherwise been written in C. Feel free to take this with a grin of salt. I suspect the C devs who don't like Rust haven't taken the time to discuss it with me.
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.
'expect' is definitely for edge-case automation, but in the few cases where it is useful, it is extremely useful. Despite the fact that it's quite 'old fashioned', it is a dependency of DejaGnu which, itself, is a dependency of the test cases for a huge number of GNU projects. This leads me to believe that it'll still be around for a very long time and will continue to work the same as it does now.
I used it as recently as a couple years ago to make short work of some build + deployment stuff on some slightly unusual platform. Might've been Garmin wearables? Something like that.
Sure, but is it worth learning TCL for a few edge-cases?
I like python, so I used "pexpect" in the past. I am sure other languages have such libraries too.
And if you are going for solid production, you probably want to re-implement "expect" anyway -- so all input is whitelisted and unexpected messages are flagged. You probably don't what to break your expensive 1990's industrial device because you were driving it with expect script, and it cheerfully ignored "WARNING RESERVE BATTERY DEAD, REPLACE BEFORE POWER OFF" messages.
