It’s not just wrong, you’re potentially allowing anything you do on that work computer to 1) be owned by the company and 2) be discoverable in court. it’s amazing how many it orgs are so lax with this. personal/work devices should and always be entirely separate. BYOD is a really bad crutch and a potential compliance nightmare timebomb for all parties.
If you need prolonged therapy under most health plans I have had, costs can well exceed $100 a week in copays. and thats assuming you can get a good one and it is covered.
You’re putting far too much into the response than is there. The point being responded to was “why optimize something like exercise?” a reason was given. It’s not as uncommon as you seem to be making it out to be.
What objection is there? Talk about “handwavy” comments there. This framing is ableist, whether intentional or not, and I was pointing out not everyone is in a situation where this is the case:
> How about you instead of trying to “get away with” as little exercise as possible you found a way to move your body that you genuinely enjoy? One should not optimise away sleep, nutrition and exercise.
Answer: because exercise can be physically very painful, impossible, or sometimes dangerous for people with certain medical conditions. Knowing how much is enough can be useful to know without being shamed for “optimizing” away exercise.
Hope that helps. Pointing out that people with different situations exist to a generalizing comment should not cause such offense, imho.
I am one of “these people.” I’m pointing out something to the gp comment that people don’t consider when they make generalizing, moralizing comments like this.
Not necessarily to the same degree. Physical activity can be extremely painful with certain disabilities. In those cases, it can be useful to know how much is enough to stay healthy.
It could have been investigated. Even this article states prices went down as a likely result of the investigation. Turning a blind eye bears some culpability. All we heard during those years was that it was due to avian flu shortage, and if you mentioned otherwise, you got shouted down by politically connected people.
You don't really ever stream games in normal situations in the same manner though. The content is mostly rendered client side, why does the server need so much bandwidth?
meta only uses inhouse tooling as far as I’m aware, so what exactly is your expertise you’re claiming here?
I didn’t claim kubernetes handles file descriptors, lol. I was saying single vm solutions hit these OS limits faster than you’d think. Try understanding the argument you’re responding to. You haven’t responded with anything of substance, so I can safely ignore you, especially given your comment history seems to have an overwhelming bias against kubernetes, which is weird. Have a good day.
“we” is me. Kubernetes is easier. yes, file descriptors are handled by managed k8s. that was a small example. I could go much further with it. the ecosystem is far easier and I’d never go back to the way you’re describing because it is just rearchitecting the wheel.
You do need service discovery at some point at scale if you are using any kind of distributed system. that is quite a strong claim. what do you have to support that claim?
You sound like you’ve never really seen scale and I’m not sure how to respond in a way that is polite. It is heavily dependent on your use case and industry. if you can get by with docker containers, good for you! My only point is you are probably reinventing the wheel here.
It's exhausting reading about this stuff because there is inevitably a barrage of comments about "you don't need kubernetes, you can run your app out of a single vm you dumb trend chaser" in this style.
Like, sorry, no, not to a point. Yes, if you have a small app without a lot of scale, and it doesn't need to be uber reliable and have very little if almost 0 downtime, okay, sure. Most use cases are like that! This is correct but applying it as a generality is just plain wrong and displays the type of arrogance people accuse kubernetes users of having.
What happens if a container in the VM goes down or the app inside of it crashes, how do you recover? Now you need some self-recovery mechanism via systemD or whatever, which will grow in complexity and fickleness over time. Congrats, you are now doing your own version of kubernetes.
What happens when you need to upgrade/restart your VM? Ok, make a standby VM as backup that will mostly sit idle, or require a full-app redeploy any time you need to do anything to the first VM. Now you need to design a blue/green mechanism between them, and probably some networking layer work. Congrats, you are now doing your own version of kubernetes.
What happens, if running in cloud, you have a regional outage or degradation? Stand up another VM in another region and manage the networking layer between them. Or, if running locally, your ISP has an outage because of a backhoe or something. Ok, we'll rent rack space in another data center as backup. Own all the mechanisms between cutting between those two now. Congrats, you are now doing your own version of kubernetes.
What happens if your app gets huge volume during peak times, and very little volume during non-peak, and you find yourself overprovisioning to the point your CFO/CTO freaks out about the bill? Well, we'll make our own dynamic scaling mechanism. Congrats, you are now doing your own version of kubernetes.
What happens when your app traffic gets so large you start running into OS limitations, like file descriptor limits? Start trying some of the aforementioned solutions. Congrats, you are now doing your own version of kubernetes.
What happens if you need service discovery, monitoring, or ensure network isolation between various services? Different VM's + your own hacked together service mesh, or wire something in the VM. Congrats, you are now doing your own version of kubernetes.
What happens when you need to guarantee secret isolation between containers? Congrats, you are now doing your own version of kubernetes.
Let's say you don't actually need any of this or think you never will. Fine! That's valid. But what you don't want, is to suddenly hit some scale and any of these things (I could list way more but I feel I am belaboring the point), migrating off these setups can become a year+ project, if not way longer. I know because I have had to do this twice now. I cannot possibly overstate how painful it is.
So, people usually just go with kubernetes because 1) it is operationally not that hard to deal with compared to the things I just mentioned, and has a massive ecosystem and 2) the risk of the VM + container spiraling into complexity is perceived as way more than going more complex at the start.
These kinds of posts act like there wasn't already a rich suite of automated security scanning tools available. The fact you can put them in a LLM's hand or point it at a codebase to do the exact same thing isn't really a big leap, the spam is. It's a bunch of amateurs thinking they can do work outside of the realm of their expertise now, and this trend isn't unique to security, you see it spreading across the various realms of expertise out there in the world. The world's slowly filling with slop, and CVE spam is a byproduct of that.
Reluctant Terraform Wizard, Passionate about privacy
the pen is mightier than the sword. - Marcus Brody, indiana jones and the last crudade