This isn’t explicitly called out in any of the other comments in my opinion so I’ll state this. Valve as a company is incredibly focused internally on its business. Its business is games, game hardware, and game delivery. For anything outside of that purview instead of trying to build a huge internal team they contract out. I’m genuinely curious why other companies don’t do this style more often because it seems incredibly cost effective. They hire top level contractors to do top tier work on hyper specific areas and everyone benefits. I think this kind of work is why Valve gets a free pass to do some real heinous shit (all the gambling stuff) and maintain incredible good will. They’re a true “take the good with the bad” kind of company. I certainly don’t condone all the bad they’ve put out, and I also have to recognize all the good they’ve done at the same time.
Back to the root point. Small company focused on core business competencies, extremely effective at contracting non-core business functions. I wish more businesses functioned this way.
Yeah, I suppose this workflow is not for everyone. I can only imagine Valve has very specific issue or requirements in mind when they hire contractors like this. When you hire like this, i suspect what one really pay for is a well known name that will be able to push something important to you to upstream linux. Its the right way to do it if you want it resolved quickly. If you come in as a fresh contributor, landing features upstream could take years.
Yeah, im sorry. Valve is the last company people should be focusing for this type of behavior. All the other AAA game companies use these mechanics to deliberate manipulate players. IMHO valve doesn't use predatory practices to keep this stuff going.
Just because they weren’t the first mover into predatory practices doesn’t mean they can’t say no to said practices. Each actor has agency to make their own operating and business decisions. Is Valve the worst of the lot? Absolutely not. But it was still their choice to implement.
What makes Valve special is that they were the first mover on those practices like lootboxes, gamepasses... but they never pushed it as far as the competition where it became predatory.
They have a track record of not engaging in these practices. It might be true that someday, we will get the wrong people in leadership positions at Valve that would entertain this behavior, but so far I don't think its going to happen. Valve has been time and time again, on the side of sane thinking around these topics. So IMHO your concern isn't really warranted as of yet.
How much of the video did you watch? I'm not aware of other game companies that enable 3rd party integrations into their item systems. This isn't just "lootboxes bad" - it's Valve profiting from actual gambling happening on external sites.
If you want to see how bad this really is, take a look at AAA games like call of duty where they dynamically alter in game loot mechanics to get people to purchase in game items.
Value is chump change in this department. They allow the practice of purchasing loot boxes and items but don't analyze and manipulate behaviors. Valve is the least bad actor in this department.
I watched half the video and found it pretty biased compared to whats happening in the industry right now.
I feel this argument of Valve deliberately profiting off of gambling not really the whole story. I certainly dont think that Valve designed there systems to encourage gambling. More like they wanted a way to bring in money to develop other areas of their platform so they can make it better, which they did. And in many cases are putting players first. Players developed bad behaviors around purchasing in-game and trading items and have chosen to indulge in the behavior. 3rd parties have rose up around a unhealthy need that IMHO is not Valves doing. And most importantly, since I was around when these systems went into place, allowing me to see what was happening, this kind of player behavior developed over time. I don't think Valve deliberately encouraged it.
The entire gaming industry is burning down before our eyes because of AAA greed and you guys are choosing to focus on the one company thats fighting against it. Im not getting it.
> call of duty where they dynamically alter in game loot mechanics to get people to purchase in game items.
[Citation needed]
> I certainly dont think that Valve designed there systems to encourage gambling
Cases are literally slot machines.
> [section about third-party websites] I don't think Valve deliberately encouraged it.
OK, but they continue to allow it (through poor enforcement of their own ToS), and it continues to generate them obscene amounts of money?
> you guys are choosing to focus on the one company thats fighting against it.
Yes, we should let the billion dollar company get away with shovelling gambling to children.
Also, frankly speaking, other AAAs are less predatory with gambling. Fortnite, CoD, and VALORANT to pick some examples, are all just simple purchases from a store. Yes, they have issues with FOMO, and bullying for not buying skins [0], but oh my god, it isn't allowing children to literally do sports gambling (and I should know, I've actively gambled on esports while underage via CS, and I know people that have lost $600+ while underage on CS gambling).
I'm choosing not to place the blame on them as I don't see it as something they can control. And I trust Valve to do the right thing over most any large game studio out there. The history of reputation and actions matter. I think you want to to try and skew the narrative based on you own particular bias. The situation is much bigger than what you are making it out to be.
The .308 footgun with software contracting stems from a misunderstanding of what we pay software developers for. The model under which contracting seems like the right move is "we pay software developers because we want a unit of software", like how you pay a carpenter to build you some custom cabinets. If the union of "things you have a very particular opinion about, and can specify coherently" and "things you don't care about" completely cover a project, contracting works great for that purpose.
But most of the time you don't want "a unit of software", you want some amorphous blob of product and business wants and needs, continuously changing at the whims of business, businessmen, and customers. In this context, sure, you're paying your developers to solve problems, but moreover you're paying them to store the institutional knowledge of how your particular system is built. Code is much easier to write than to read, because writing code involves applying a mental model that fits your understanding of the world onto the application, whereas reading code requires you to try and recreate someone else's alien mental model. In the situation of in-house products and business automation, at some point your senior developers become more valuable for their understanding of your codebase than their code output productivity.
The context of "I want this particular thing fixed in a popular open source codebase that there are existing people with expertise in", contracting makes a ton of sense, because you aren't the sole buyer of that expertise.
If you have competent people on both sides who care, I don't see why it wouldn't work.
The problem seems, at least from a distance, to be that bosses treat it as a fire-and-forget solution.
We haven't had any software done by oursiders yet, but we have hired consultants to help us on specifics, like changing our infra and help move local servers to the cloud. They've been very effective and helped us a lot.
We had talks though so we found someone who we could trust had the knowledge, and we were knowledgeable enough ourselves that we could determine that. We then followed up closely.
Most companies that hiring a ton of contractors are doing it for business/financial reporting reasons. Contractors don't show up as employees so investors don't see employee count rise so metric of "Revenue/Employee" ratio does not get dragged down and contractors can be cut immediately with no further on expenses. Laid off employees take about quarter to be truly shed from the books between severance, vacation payouts and unemployment insurance.
This is mostly because the title of contracter has come to mean many things. In the original form, of outsourcing temporary work to experts in the field it still works very very well. Where it fails is when a business contracts out business critical work, or contracts to a general company rather than experts.
I've seen both good and bad contractors in multiple industries.
When I worked in the HFC/Fiber plant design industry, the simple act of "Don't use the same boilerplate MSA for every type of vendor" and being more specific about project requirements in the RFP makes it very clear what is expected, and suddenly we'd get better bids, and would carefully review the bids to make sure that the response indicated they understood the work.
We also had our own 'internal' cost estimates (i.e. if we had the in house capacity, how long would it take to do and how much would it cost) which made it clear when a vendor was in over their head under-bidding just to get the work, which was never a good thing.
And, I've seen that done in the software industry as well, and it worked.
That said, the main 'extra' challenge in IT is that key is that many of the good players aren't going to be the ones beating down your door like the big 4 or a WITCH consultancy will.
But really at the end of the day, the problem is what often happens is that business-people who don't really know (or necessarily -care-) about specifics enough unfortunately are the people picking things like vendors.
And worse, sometimes they're the ones writing the spec and not letting engineers review it. [0]
[0] - This once led to an off-shore body shop getting a requirement along the lines of 'the stored procedures and SQL called should be configurable' and sure enough the web.config had ALL the SQL and stored procedures as XML elements, loaded from config just before the DB call, thing was a bitch to debug and their testing alone wreaked havoc on our dev DB.
Igalia isn’t your typical contractor. It’s made up of competent developers that actually want to be there and care to see open source succeed. Completely different ball game.
Nope. Plenty of top-tier contractors work quietly with their clientele and let the companies take the credit (so long as they reference the contractor to others, keeping the gravy train going.)
If you don't see it happening, the game is being played as intended.
There are 'best to brush' timelines around eating/drinking. Usually you want to either:
- Brush no less than 15m before eating
- Do not brush until 45m+ after eating
I don't fully understand the science, as I'm not a dentist, but it's something related to the way that things stick to/are absorbed by enamel and dentin.
I believe water is the exception here, you can drink water and then immediately brush. You should not brush and then immediately drink water though. You want the toothpaste to stick around and form a barrier.
Supposedly, after eating the pH in the mouth drops and becomes more acidic, which softens the enamel, so brushing will do more harm than good. That's my understanding.
Back of napkin math I’ve done previously, it breaks down around 2 million members with Hashicorps defaults. The defaults are quite aggressive though and if you can tolerate seconds of latency (called out in the article) you could reach billions without a lot of trouble.
It's also frequency of changes and granularity of state, when sizing workloads. My understanding is that most Hashi shops would federate workloads of our size/global distribution; it would be weird to try to run one big cluster to capture everything.
From my literal conversation I'm having right now, 'try to run one big cluster to capture everything' is our active state. I've brought up federation a bunch of times and it's fallen on deaf ears. :)
We are probably past the size of the entirety of fly.io for reference, and maintenance is very painful. It works because we are doing really strange things with Consul (batch txn cross-cluster updates of static entries) on really, really big servers (4gbps+ filesystems, 1tb memory, 100s of big and fast cores, etc).
Who orchestrates the orchestrators? is the question we’ve never answered at HashiCorp. We tried expanding Consul’s variety of tenancy features, but if anything it made the blast radius problem worse! Nomad has always kept its federation lightweight which is nice for avoiding correlated failures… but we also never built much cluster management into federated APIs. So handling cluster sprawl is an exercise left to the operator. “Just rub some terraform on it” would be more compelling if our own products were easier to deploy with terraform! Ah well, we’ll keep chipping away at it.
I used this when it was brand new for a bit and it was so incredibly smooth and worked so well. It solved the problem of controlling systemd units remotely so well. I'm pretty sure the only reason it never actually took off was kubernetes and coreos's acquisition, however it actively solves the 'other half' of the k8s problem which is managing the state of the host itself.
I believe the context is that the CVE is that this bypasses the sandbox entirely; so in this specific case this is a real, full-blown RCE. Your comment makes it seem at a glance that you're saying it's a DOS at worse.
Thanks for replying, but my comment is not saying that at all -- it's pushing back on someone making the claim that the new CVE is no worse than what could already be done, by pointing out that what could already be done was (presumably) only a DoS, while the new CVE is full RCE.
I've reread my comment and the parent comment, and I don't understand how this is not clear?
I've used FIM in the past to catch a CEO modifying files in real-time at a small business so I could ping him and ask him to kindly stop. It's not just about BS _processes_. :D
That means CEO has access to do the changes. It's technically easier to remove that, than to insert FIM into the deployment process. (And will stop other unauthorised employees too) I mean, you already need a working deployment pipeline for FIM anyway, so enforce that?
The CEO would've found it very easy to remove the blocker in that case (me). This is the life of small tech businesses. Also, they were modifying configuration files (php-fpm configurations iirc) and not code.
FIM is very useful for catching things like folks mucking about with users/groups because you typically watch things like /etc/shadow and /etc/passwd, or new directories created under /home, or contents of /var/spool/mail to find out if you're suddenly spamming everyone.
That’s a great real-world story. Exactly the kind of unexpected modification FIM can help surface—not only security incidents, but also operational surprises.
As someone who's lived in the bay for a bit over 10 years now, when I first moved here Google was very much that company that you think they were. Now, they are not. Every single friend (and it was >50% when I moved here!) has since left Google in the bay area. There is one left at Google entirely, and they're only remaining due to physical location (near family outside the US). I have watched my friends get brutally and relentlessly pipped over the tiniest bullshit reasons. This is all entirely 2nd hand so my perspective is very skewed, but even my friends from Facebook/Netflix/Apple weren't treated that way.
I'm aware of the many changes; including the cancellation of Google SoC. However, gp claimed neither Google nor Apple have a benevolent track record towards open source, and that doesn't ring true to me. The old Google was very benevolent, perhaps only rivalled by Red Hat and (old) IBM.
Hi, can you provide a few examples of 'tiniest bullshit reasons'? Kinda curious as what is considered bullshit there, I'm from the EU with zero experience of anything like S.F.
One was pipped because they were placed on a moonshot, told how amazing their work was, gave internal talks on it, then the moonshot was defunded... so they got pipped over their lack of business impact. Instead of, y'know, being placed on a normal team, like where they came from only a year or so before.
Incredibly good. A lot of main GPU board partners are making LLM-focused boards. There was a few previews on Gamers Nexus from... Computex I think? I wanna say lots of memory, dual GPU boards that looked very well built for local LLM usage.
Back to the root point. Small company focused on core business competencies, extremely effective at contracting non-core business functions. I wish more businesses functioned this way.
reply