I've observed the same and, anecdotally, how much of a pain the ops team is is a function of how much responsibility shifts from the dev team to the ops team during the project lifecycle.
Basically, is the ops team there to support the developer/development team, or the product?
In the case of the development team, the ops team will tend to be willing to provide advice and suggestions but be flexible on tooling and implementation. In the case of the product, the ops team will tend to be a lot more rigid and inflexible.
This plays out in things like:
When the PWA becomes critical for the production line and then "is not working" at 3AM, who is getting paged? If it's the developer, then ops is "supporting the developer". If it's the ops team getting called to debug and fix some project they've never laid eyes on before at 3AM, then it's the product. They are, naturally, going to start caring a lot more about how it is set up, deployed, and supported because nobody likes getting woken for work at 3AM.
When some project's dependencies start running past EOL, who is going to update it? If it's the developer, then ops is "supporting the developer". If the ops team isn't empowered to give a deadline and have _someone else_ responsible for keeping the project functioning, then they're supporting the product and by letting it be deployed effectively committed to maintaining it in perpetuity and they're going to start caring a lot more about what sort of languages, frameworks, etc are used and specifically how projects are set up because context switching to one of dozens of different projects at 3AM is hard enough as-is without having to also be trying to learn some new framework du jour.
(And before anyone says "well the updates probably aren't necessary this is just ops being a pain"--think of the case of a project relying on GCP product that's being shutdown or some kubernetes resource that's been changed. In one case inaction will cause the project to fail, in the other ops' action will cause it to fail. See the first point as to who is going to get called about that. Even in the happy case, consistency brings automation and allows the team to support a _class_ of deployments instead of individual products.)
I don't think places exist stably in the middle ground because it's a painful place to be for very long. The responsibility and the control land on separate people, and the person with the responsibility but without the control is generally going to work to wrestle control to reduce misery. In the case where ops acts as if they're supporting the developers but is in practice supporting the product, it's not going to take too many 3AM calls before they start pushing back on how the product's deployed and supported.
I've been both of those ops guys you describe. When I was the "checklists, meetings, and picking the project apart" guy it had nothing to do with me wanting to make anyone's life difficult or flexing my knowledge. It had to do with the 3AM calls waking myself, my wife, and my newborn up. If I was taking on responsibility for keeping your _product_ functional through its useful life, yeah, I wasn't going to let people dump stuff on my plate unless I had some reasonable basis to believe it wasn't going to substantially increase my workload and result in more middle of the night calls. The checklists were my way of trying to provide consistency and visibility into the process of reducing my own pain, not my way of trying to create pain for others.
> I wonder how much this really matters. For me my dishwasher is far enough from the hot water heater that it generally takes several gallons for the water to run hot.
(I'll preface this with: If your dishes are coming out clean and you're happy with them, then keep on keeping on. The reason there's a lot of discussion around this is because there are a lot of people who _aren't_ getting clean dishes out of their dishwasher.)
If you listen to your dishwasher's cycles, you'll probably hear it do a relatively short initial rinse to get off the bulk of the gunk, then the main wash, then another rinse. (Maybe multiple washes/rinses, but that's the general pattern.)
The idea is to make that first rinse most effective. Anything that can be taken off in the pre-wash cycle is something that won't be washed off in the main wash and cycled over the dishes over and over.
As people normally use their dishwasher, that cycle is being done with cold to lukewarm water and no soap. Most people wouldn't see a oily plate with dried-on sauce on it and think to clean it by spraying it in the sink with cold water until it were clean. But that's what the dishwasher's doing to their dishes.
Hence the suggestion of running the hot water tap first. It's a very easy thing to do to ensure the dishwasher's using hot water in that initial rinse and everyone generally accepts that hot water's going to dissolve and rinse off the food and oils better.
Another very easy improvement is adding a bit of soap to the basin. Most dishwashers only have a single compartment for soap and it's released during the main wash. If you throw a squirt/scoop of detergent into the basin before you start it, that will get mixed in to the pre-wash cycle.
The cycle's happening anyway, using hot water and soap is just making the most of it!
Anecdotally (like all these other comments), my wife's approach is definitely the "racoon on meth" archetype--throw the dishes wherever they could fit, throw one of those detergent pods in, hit "start", close it, wait a few hours, then take all the dishes out and dump water out of cups and bowls and handwash them because they're still filthy. When I was building the kitchen, she was questioning the expense and effort of the dishwasher because in her entire life she's never had one that actually cleaned the dishes properly and thought they were kind of pointless.
Since I didn't want to spend the next however many years hearing about how the dishwasher sucks, after we put it in I played dishwasher czar for a month. I loaded the dishes properly, put in the proper amount of soap (and a sprinkle in the basin), made sure the rinse aid wasn't empty, ran the tap first, ran the dishwasher. Every single load came out spotless. She'd often question something I was putting in because "there's no way it's going to get that off". It did. Every time.
Wife satisfied that the dishwasher is good and having had a month of instruction I unleashed the meth-y racoon on it, and we're back to the dishwasher being a really elaborate rinsing machine we use before handwashing the dishes.
Is it just the running the tap? Probably not. Just like it's not _just_ the adding soap to the basin, using the rinse aid, loading them properly, etc. They all contribute to "using the dishwasher most effectively".
We're not talking starting up a hosting company but renting idle capacity. I'm already paying for the hardware, maintenance, electricity, and connectivity.
The only real marginal cost to renting some of my idle capacity would be additional power use. Versus current draw, the power supply running maxed out 24/7 would increase my power bill by $36/mo.
If we use the $4.59/mo VPS as a point of comparison, just one of the servers heating up my utility room has 24x the CPU cores ($110/mo), 96x the RAM ($440/mo) and 1024x the storage ($4,700/mo).
I would never in a million years actually do so, but I'm relatively certain I could turn several dozen CPU cores, hundreds of GB of RAM, and terabytes of disk space into more than $72/mo (assuming only getting 50% of the revenue) _somehow_.
Pretty much the same boat. Early 2020 I was spending so much time on calls headphones were just tiring. So it started as "get a microphone + speaker setup that doesn't echo" and just kind of spiraled into a half decade of incremental improvements.
Don't know that I've had anything as loud as a fire truck, but more than a few times I've had a 75lb dog a few feet away from me barking like mad, whining at me, playing by throwing a cow femur up in the air and letting it crash down on the vinyl floor, etc and apologized about the noise only to have people look at me funny and tell me they didn't hear anything but that explains why I seemed like I was having trouble speaking.
I think the only time I had anyone say anything about anything was when I accidentally had an air conditioner blowing directly on my microphone. They couldn't hear it, but my voice was coming through a little less crisp than usual as the noise cancellation was trying to remove the constant, high volume white noise.
Don't know what OS you're on, but on Linux I can definitely recommend Easy Effects (https://flathub.org/apps/com.github.wwmm.easyeffects). Been using RNNoise + Speex along with some other filtering for quite a while now to great effect.
One thing I found worked _really_ well if you're already using an external microphone of some sort--using the webcam microphone as part of a noise gate. On top of the filtering and existing gating, my audio only opens if my webcam _also_ picks up sound of sufficient volume. Lets me keep the microphone in front of my face fairly sensitive while still entirely eliminating echo and most off-axis sounds.
(That's their "picks", but they have reviews and tests on a lot more models. I just can't find a good place to link to just "all of the noise cancelling headphones".)
Don't just skim the list, click in and take a look at the individual products. They do pretty extensive quantitative measurements of all of these headphones and provide useful commentary alongside (e.g., the Sony ones are shallower so if you have big ears they might get uncomfortable). They have full frequency response graphs for the noise isolation, recordings of how it fares against some test samples, etc.
They also measure some less typical stuff like "clamping force" and "ear breathability" that's hard to tell just from briefly putting them on in a store.
I've personally tried some (older) Sony against (older) Bose and I can't really comment on whether the ANC is better because they pushed on the arms of my glasses hard enough and the shape left them resting _on_ my ears instead of over them such that they hurt to wear after a little while. They could be head and shoulders above, but that would be worthless to me because I would never use them. So I'd mostly echo what the other commenter is saying--they're all pretty much "great" in passive/active noise cancellation and sound quality. Just get whichever feels best to you.
I agree you shouldn't write off any platform/software/etc based solely on the number of vulnerabilities. I also agree that how responsive they are to fixing things is a factor to consider. But I think that's only _a_ factor.
Take something like a container escape vulnerability.
We could have Vendor A where they're just running containerd on a bunch of hosts on a single network segment and throwing everyone's containers at it so a container escape vulnerability essentially gets you access to everything any of their customers are running.
Where-as Vendor B segments running containers into VMs, so a container escape vulnerability means you can only access your own data. Not great because if one container is compromised that gives them a path into the rest of your workloads, but at least I know they're maintaining a pretty solid wall between tenants.
Then there's Vendor C that actually runs containers using some micro-VM framework so each container is running fully isolated by a hypervisor with a fully separate emulated network stack, etc so the escape really gets them no more access than they had inside the container.
A pattern of issues like Vendor A is, well, a pattern. A series of issues that show their systems are fundamentally not designed for proper isolation between tenants and are lacking defense-in-depth measures to mitigate the fallout of the inevitable security issues is a very good reason to write off Vendor A regardless of how quickly they respond to the issues.
I'm not going to go back and review all the Azure issues, but my recollection from the few writeups I've read definitely paint a picture of a lot more "Vendor A" type issues than I'd be comfortable with.
All of this presupposes that whatever you implement yourself will be more secure and/or that you have the budget to even begin to approach the same level of security.
I’ve been there, done that, and was amazed how the security aspects only rapidly escalated to many millions of dollars and an ongoing cost also in the million or two range!
Think of this like a CEO: they’re less worried about Chinese hackers and more worried about about insider attacks. They’re much more common and do way more financial damage.
The cloud automatically provides separation of roles because an entirely different vendor is in charge of the lower layers, such as networking and storage.
Do you have any idea how hard it is to prevent a smart sysadmin from simply copying all data to a USB drive and walking out of the building with it?
That’s much harder when everything is on a managed hosting platform and no single person can access all accounts / subscriptions.
The first episode I ever saw was "Takeaway" (dad and kids are waiting 5 minutes outside the Chinese takeaway restaurant). It so perfectly hit on not only the actual experiences from my life but how it _felt_ in the moment that I think I laughed until I cried. Then immediately made my wife watch it.
The episode referenced in the article ("Whale Watching" about the parents being hungover) is another that, while not my favourite or anything, is certainly one of those experiences you probably have as a parent that nobody's really talking about or making media about. Bluey's managing to be entertaining and wholesome for kids while hitting on a mostly untapped niche of "relatable parenting experiences".
With how much "junk food" TV is out there, Bluey's a real gem. For kids and parents alike.
> But from the nation that brought us our greatest human experimentation regimen, hardly surprising.
To assume good faith here I'd have to assume wherever you are you've never donated blood?
When you donate blood you've lost a pint of fluids. They give you something to drink to work on rehydrating.
The sugar in the juice and the sugary snacks are to help give you a bit of energy since... you just lost a pint of blood.
Which is to say this is pretty standard everywhere. It's not payment. The ice pack after my vasectomy wasn't "payment for population control". It's healthcare.
> Had they actually found out about the fact that we bypassed security measures on a bootable CD-ROM that allowed us full system access, [...] or that we figured out every computer used VNC and they all had the same password stored in plaintext in the registry (which we accessed via that bootable media)
Hey, sounds familiar!
Our school district had a policy that all new computers went to the high schools, then when those aged out and were replaced went to the elementary schools. They wanted iMacs for the elementary schools. That meant that for a couple years our high school had to have iMacs.
Of course literally everything we were trying to do, all the courses and curriculum, etc were built around Windows. So all of them were set up to dual-boot... Which is to say we didn't even need to haul in any bootable media.
Rebooted into mac, which had absolutely no respect for NTFS file permissions, and copied the SAM registry hive off. Took that home, ran the password hash through a cracker and a day later had the local admin password that was shared among all of the computers in the school.
It too was mostly used for running GTA.
There was also that time with a little light B&E and doing some network cabling under the cover of night. Though I think there's technically no statute of limitations on that so that's probably enough said.
Not sure how fair of a comparison that is given how much of what makes that vehicle go is not in that bay, but an example more of what he's talking about...
Basically, is the ops team there to support the developer/development team, or the product?
In the case of the development team, the ops team will tend to be willing to provide advice and suggestions but be flexible on tooling and implementation. In the case of the product, the ops team will tend to be a lot more rigid and inflexible.
This plays out in things like:
When the PWA becomes critical for the production line and then "is not working" at 3AM, who is getting paged? If it's the developer, then ops is "supporting the developer". If it's the ops team getting called to debug and fix some project they've never laid eyes on before at 3AM, then it's the product. They are, naturally, going to start caring a lot more about how it is set up, deployed, and supported because nobody likes getting woken for work at 3AM.
When some project's dependencies start running past EOL, who is going to update it? If it's the developer, then ops is "supporting the developer". If the ops team isn't empowered to give a deadline and have _someone else_ responsible for keeping the project functioning, then they're supporting the product and by letting it be deployed effectively committed to maintaining it in perpetuity and they're going to start caring a lot more about what sort of languages, frameworks, etc are used and specifically how projects are set up because context switching to one of dozens of different projects at 3AM is hard enough as-is without having to also be trying to learn some new framework du jour.
(And before anyone says "well the updates probably aren't necessary this is just ops being a pain"--think of the case of a project relying on GCP product that's being shutdown or some kubernetes resource that's been changed. In one case inaction will cause the project to fail, in the other ops' action will cause it to fail. See the first point as to who is going to get called about that. Even in the happy case, consistency brings automation and allows the team to support a _class_ of deployments instead of individual products.)
I don't think places exist stably in the middle ground because it's a painful place to be for very long. The responsibility and the control land on separate people, and the person with the responsibility but without the control is generally going to work to wrestle control to reduce misery. In the case where ops acts as if they're supporting the developers but is in practice supporting the product, it's not going to take too many 3AM calls before they start pushing back on how the product's deployed and supported.
I've been both of those ops guys you describe. When I was the "checklists, meetings, and picking the project apart" guy it had nothing to do with me wanting to make anyone's life difficult or flexing my knowledge. It had to do with the 3AM calls waking myself, my wife, and my newborn up. If I was taking on responsibility for keeping your _product_ functional through its useful life, yeah, I wasn't going to let people dump stuff on my plate unless I had some reasonable basis to believe it wasn't going to substantially increase my workload and result in more middle of the night calls. The checklists were my way of trying to provide consistency and visibility into the process of reducing my own pain, not my way of trying to create pain for others.
reply