1. It took the end of ZIRP era for people to realize the undue complexity of many fancy tools/frameworks. The shitshow would have continued unabated as long as cheap money was in circulation.
2. Most seasoned engineers know for the fact that any abstractions around the basic blocks like compute, storage, memory and network come with their own leaky parts. And that knowledge and wisdom helps them make the suitable trade-offs. Those who don't grok them, shoot themselves in the foot.
Anecdote on this. A small sized startup doing B2B SaaS was initially running all their workloads on cheap VPSs incurring a monthly bill of around $8K. The team of 4 engineers that managed the infrastructure cost about $10K per month. Total cost:$8K. They made a move to 'cloud native' scene to minimize costs. While the infra costs did come down to about $6K per month, the team needed new bunch of experts who added about another $5K to the team cost, making the total monthly cost $21K ($6K + $10K + $5K). That plus a dent to the developer velocity and the release velocity, along with long windows of uncertainty with regards to debugging complex stuff and challenges. The original team quit after incurring extreme fatigue and just the team cost has now gone up to about $18K per month. All in all, net loss plus undue burden.
Engineers must be tuned towards understanding the total cost of ownership over a longer period of time in relation to the real dollar value achieved. Unfortunately, that's not a quality quite commonly seen among tech-savvy engineers.
Being tech-savvy is good. Being value-savvy is way better.
Thanks for sharing the story. Despite the whole TCO being higher, I wonder how the 8K to 6K reduction happened.
On AWS, fargate containers way are more expensive than VMs and non fargate containers are kind of pointless as you have to pay for the VMs where they run anyway. Also auto scaling the containers - without making a mess - is not trivial. Thus, I'm curious. Perhaps it's Lambda? That's a different can of worms.
As said, most of their workloads were on cheap VPSs before. Moved some to 'scale-to-zero' solutions, reduced the bloat in VMs, fixed some buggy IaC, also moved some stuff to the serverless scene. That got a decent ~20% reduction.
Once a capable AI that can make a "Two Brothers" trailer like this one below comes up, humanity has some serious issues to tackle, other than climate change ofc! :D
> there is a great opportunity to help businesses manage their software supply chain
Yes, very much. There are so many layers, components, and their intricate relations that goes totally ignored today at least in most places. Because, doing so is insane amounts of work. Only BigCos can afford to have dedicated teams for 's/w supply chain management', considering the cost-parity-with-returns. However, the solution on this end that works for BigCo doesn't necessarily work for SMEs & startups. That gap isn't small, if am right.
> Another product that is often requested is a visual DAG debugger. When a pipeline break, you want to know why, and staring at your CI logs is definitely not the best experience for that. With a web UI, there's a lot we can do there.
Yes. This definitely helps. But more than a viz DAG element, people look for an early-warning of a failure. Most common build-failure reasons (other than failed tests) -> expired creds used somewhere in the pipeline, provisioning failed/time-out, problem at some other dependent module totally outside org's control (some OSS/dep). People seem to be bothered equally about how to squash'em rather than just where to squash. Locating the part where pipeline broke is just half the part. Actionable insights as to how that pipeline can be healed is the hard part. And considering the diversity of the ecosystem, that's gonna be a wild ride.
BTW, are you folks hiring? "DevOps OS for enterprises" seems very very enthralling, esp for an old toolmaker.
1. If identity providers start offering a dynamic, trusted element within the critical pages (login, password prompt, 2FA/OTP verification etc)
2. if such dynamic element is from a known range/set of customer/trusted-party supplied identity elements.
Ex. During my account creation, say I am prompted to select some "secret identity themes", and I choose { batman, bike, carrots }
At the login/password/OTP prompt, I am shown a 3x3 grid of pics / words / hints, which have at least 3 (or whatever configurable number, in my account preferences) that are somehow connected to my "secret identity theme". This way, I know I can trust this page. The grid also has many unrelated ones acting as decoys elements, so that any malicious spoofing party cannot really figure them out.
I believe you get the general idea.
Do y'all feel this can possibly help, in mitigating this very serious & very harmful threat?
The Barclays Android banking app gets you to choose a few words that you make up, and displays those words on the login screen as a way of authenticating to you that it actually is the Barclays app login screen.
I remember some big service many years ago (maybe yahoo?) had a “memorable image” or something that was associated with your username as some kind of anti phish metric. Of course nowadays that would be trivial to bypass with something like Modliskha or a different reverse proxy passing through the website content.
Yes. That's why a cluster of elements for a "secret identity theme", instead of just one image. (After all, infosec/security is finally just a game of making reward-to-effort ratio too impractical for most threat-actors & thus achieve reasonable 'sense of security', in a world where exploits exist for almost every ring in the stack - including ring 0)
I feel BITB mostly gets used by those who may not really be having access to lob a proxy attack at the intended target as well, which filters a good set, among potential victims.
I think the concern (if you ever see this comment) is that an attacker will for instance put the fake browser ui around an iframe to a proxy to the legitimate website content using a tool like Modlishka. In that case, whatever is presented to the user in the legitimate application (including whichever superheros or whatever are selected that time around) and all of the bogus images will be presented in the proxied version. Transparent proxies like that are very effective ways of doing phishing because you can phish 2fa or even SSO or similar info by just passing on a legitimate login page to the user but through your MITMed page.
Yes, I understand that BITB+MITM is a huge risk. But my point was that most who want to run BITB won't typically have the means to run an MITM along with it. (unless 'MITM within a browser' becomes a reality!)
I was trying to say that the dynamic security element helps in filtering at least the most common kind of attack, which otherwise leaves consumers to bear a very large risk.
Perhaps this is the thing that I don’t understand. Why wouldn’t an attacker have such means? This attack isn’t something that requires control of the network, it’s just a fantastic way of producing a lookalike page.
"A member of the team, Dr Vivek Sathe, frisked the student and found a mobile phone in the inner pocket of his trouser. The phone was switched on and connected to a Bluetooth device, Dr Dixit said. However, the team did not find a Bluetooth device on the student.
On sustained questioning, the student confessed that an ENT surgeon had fitted a skin coloured micro Bluetooth device in his ear.
The squad also found another student with a small SIM-powered device and a micro Bluetooth device, but the student informed the squad that it was not inserted surgically and can be removed with a pin.
The devices have been sent to an internal examination committee, which will decide whether a police case for using unfair means in an exam should be filed, Thakur said.
Dr Anand Rai, the whistleblower in the so-called Vyapam scam, where various competitive exams were rigged, said: “It is very easy to get Bluetooth fitted in the ears. It is attached to the ear temporarily and can be removed. Such a technique was used by a Vyapam scam accused too to clear his medical exam eight years ago.”
Many here take that high-risk path, even though they know that clearing the entrance is just step 0, and there are tougher exams further. Such is the mindlessness at display.
Although I haven't come across many Kannadigas who choose en_CA due to KA and CA sounding similar, this is an angle for sure.
But OP's guess (en_CA alphabetically above en_GB / en_US) is a more possible reality.
Another trivia: Kannada-English dialect is called "Kanglish" here. Ex: "ಲಾಕ್-ಡವ್ನ್ ! ಬಸ್ಸು ಕಾರು ಎಲ್ಲಾ ರೋಡಿಂದಾ ಬ್ಯಾನ್!" [phonetic: 'lockdown! baSSu, kaaru ellaa road-indaa byaan!'] Though the sentence is accepted to be Kannada, only true Kannada word there is "ellaa" (=> all)
Kanglish is the norm here, and textbook Kannada isn't getting good love from many. The onslaught of Sankrit on pure classical Kannada is a different topic altogether, for another day!
I assumed you were referring to how people normally conversed in Kannada :)
Personally, I don't consider TV Kannada to be indicative of the language spoken on the streets or in the homes of the city. I would be concerned if this headline had made its appearance in print; I don't think that has happened yet.
Every language tends to evolve and borrow some amount of vocabulary from other languages. I've seen this to be especially true when the spoken and written forms are different, as is the case with quite a few Indian languages. The language spoken on the street is not textbook Kannada - it hasn't been textbook Kannada in forever! None of "Hegidiya Guru" or "Yenu Maga" or "Bro!" is a textbook example of an interpersonal greeting - you'd be hard pressed to find the first one in vogue these days, it is now history. The spoken form continues to evolve on its own. (I can see this being the case with at least three other languages).
Many out here are saying that "the system has collapsed".
They are _SO_ wrong. We never _had_ a system to begin with, in the first place!
Our "system" is only _EXPOSED_ now, to the entire world.
What's seen and exposed now, is what had been operational for the last 30 odd years. Everything needs some strings to be pulled and some hands made warm with a stash of notes.
A nation full of mostly meek, timid, inherently corrupt people all of a sudden wondering that "our system has failed! uiuiuiui!"
Indian nation had a grand opportunity at getting better. The Indian public just shat on it and smeared cowdung listening to the right wing propaganda. Now, let them drown in cow-urine / dung.
Many of the older core banking systems were keyboard only, because it made the tellers work a lot faster.
I know because I had been on some of those unfortunate teams that transitioned to GUI that required to use the mouse and the teller's productivity decreased terribly - something that took 30 seconds ended up taking almost 4 minutes, and seeing this, the banks refused to transition to the "new and advanced" versions, until the old charmode UI was slapped on it again.
I'm glad we're using dedicated vpn boxes... kind of annoying that I can't use a wifi directly, but usually at my home desk and tethered in anyway. Didn't know about the VPN issues in practice.
1. It took the end of ZIRP era for people to realize the undue complexity of many fancy tools/frameworks. The shitshow would have continued unabated as long as cheap money was in circulation.
2. Most seasoned engineers know for the fact that any abstractions around the basic blocks like compute, storage, memory and network come with their own leaky parts. And that knowledge and wisdom helps them make the suitable trade-offs. Those who don't grok them, shoot themselves in the foot.
Anecdote on this. A small sized startup doing B2B SaaS was initially running all their workloads on cheap VPSs incurring a monthly bill of around $8K. The team of 4 engineers that managed the infrastructure cost about $10K per month. Total cost:$8K. They made a move to 'cloud native' scene to minimize costs. While the infra costs did come down to about $6K per month, the team needed new bunch of experts who added about another $5K to the team cost, making the total monthly cost $21K ($6K + $10K + $5K). That plus a dent to the developer velocity and the release velocity, along with long windows of uncertainty with regards to debugging complex stuff and challenges. The original team quit after incurring extreme fatigue and just the team cost has now gone up to about $18K per month. All in all, net loss plus undue burden.
Engineers must be tuned towards understanding the total cost of ownership over a longer period of time in relation to the real dollar value achieved. Unfortunately, that's not a quality quite commonly seen among tech-savvy engineers.
Being tech-savvy is good. Being value-savvy is way better.