Rendered at 22:51:22 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
skrtskrt 29 minutes ago [-]
As a general rule I install none of these web conferencing things on my machine. Either the browser version works fine, as Google Meet, Zoom, Teams and even WebEx all do, or this is not a meeting I need to be on.
jruohonen 8 hours ago [-]
"the meeting said something on my system was out of date. i installed the missing item as i presumed it was something to do with teams, and this was the RAT."
Oh dear.
stevenicr 2 hours ago [-]
I had a job offer interview sent to me a couple weeks ago that ended like this.
Everything was normal messaging. Back and forth. Got the invite to schedule a google meet. All looked like all the other things.
Day of meeting, click the google meet button in the email.. redirect to a browser screen showing that google meet needs an update, this is the microsoft store.
Rush, hurry, meeting will be late!
except it was not the msoft store it was all fake.
I wish indeed and other job sites shared more info about these (like fake company signed up with a fake email from a vpn to publish this job listing that possibly infected 1,000 computers- and some are reporting X Y Or Z (ransom, whatever)
simonw 5 hours ago [-]
That's the bit that scares me. I've often found myself installing software in a hurry to join a meeting on some platform that I've not previously used via my current machine.
The time pressure means I'm less likely to pay attention to what I'm installing.
pvtmert 28 minutes ago [-]
IMO, rushing things never helps. If possible, I investigate external calls/meetings well in-advance, at worst case, I add 30-minute calendar block before those. (To prepare and install/update things).
As a DevOps, I have seen the quote about "premature optimisation's root of all evil" in real life quite often. In fact, optimising one bottleneck quickly yields another one -moving the goalpost further-, potentially increasing business-impact if the flow is not contained properly.
Especially during incidents, _rushing_ to fix often yields more problems. I've seen people isolating/shutting-down mildly misbehaving instances. Causing excessive load to the remaining and starting the cascading failure like dominos falling one after another.
Which reminds me a scene from "The Office", where Dwight goes rogue and conducts a "Fire-Drill" by locking doors and deliberately causing smoke. Everyone panics and hell breaks loose. This is at the beginning of the episode, maybe 5-minutes tops. I show this at the incident-management training, this is how people behave in real life. No joke.
To give more concrete aspect on the moving goalpost: SWEs improve transaction processing with multi-threading, but that causes more connections/transactions to the database. Even though theoretical gains are Nx (n-times depending on threads/cores), real life gains are 1.2x-1.3x, because database connections are getting occupied. As the next step, increasing number of DB connections helps, maybe add another master node (risk of having deadlocks increase, but ignore for now for the sake of argument). But then the disk IO becomes the bottleneck due to write-heavy (payments domain). Then we add Redis to reduce load, and maybe some asynchronous processing. At this point complexity increases and we need to solve rare occurrences of duplicate data or race-conditions because it is not single-threaded process anymore...
PufPufPuf 2 hours ago [-]
I wonder if I would have been saved by my absolute disdain for installing anything Microsoft Teams-related on my computer. The web version works fine, thanks.
Oh dear.
Everything was normal messaging. Back and forth. Got the invite to schedule a google meet. All looked like all the other things.
Day of meeting, click the google meet button in the email.. redirect to a browser screen showing that google meet needs an update, this is the microsoft store.
Rush, hurry, meeting will be late!
except it was not the msoft store it was all fake.
I wish indeed and other job sites shared more info about these (like fake company signed up with a fake email from a vpn to publish this job listing that possibly infected 1,000 computers- and some are reporting X Y Or Z (ransom, whatever)
The time pressure means I'm less likely to pay attention to what I'm installing.
As a DevOps, I have seen the quote about "premature optimisation's root of all evil" in real life quite often. In fact, optimising one bottleneck quickly yields another one -moving the goalpost further-, potentially increasing business-impact if the flow is not contained properly.
Especially during incidents, _rushing_ to fix often yields more problems. I've seen people isolating/shutting-down mildly misbehaving instances. Causing excessive load to the remaining and starting the cascading failure like dominos falling one after another.
Which reminds me a scene from "The Office", where Dwight goes rogue and conducts a "Fire-Drill" by locking doors and deliberately causing smoke. Everyone panics and hell breaks loose. This is at the beginning of the episode, maybe 5-minutes tops. I show this at the incident-management training, this is how people behave in real life. No joke.
To give more concrete aspect on the moving goalpost: SWEs improve transaction processing with multi-threading, but that causes more connections/transactions to the database. Even though theoretical gains are Nx (n-times depending on threads/cores), real life gains are 1.2x-1.3x, because database connections are getting occupied. As the next step, increasing number of DB connections helps, maybe add another master node (risk of having deadlocks increase, but ignore for now for the sake of argument). But then the disk IO becomes the bottleneck due to write-heavy (payments domain). Then we add Redis to reduce load, and maybe some asynchronous processing. At this point complexity increases and we need to solve rare occurrences of duplicate data or race-conditions because it is not single-threaded process anymore...
Up to usual Microsoft Teams standards