Also, anything sounds big when you put it in gallons. Doesn't sound so big when you mention that's 92 acre feet, the amount used by less than 20 acres / 8 hectares of alfalfa per year. Or when you mention that a typical *closed loop* 1GW nuclear reactor uses 6-20 billion gallons of cooling water per year (once-through uses 200-500 billion gallons, though most of that is returned, whereas closed loop evaporates it)
I don't think it has anything to do with that. As soon as I saw the headline, my mind went "cohort study". And sure enough, yeah, it's a cohort study. Remember that big thing about how wine improves your health, and then it turned out to just be that people who drink wine tend to be wealthier and thus have better health outcomes? And also, the "sick quitter" effect, where people who are in worse health would tend to stop drinking, so you ended up with extra sick people in the non-wine group? Same sort of thing. This study says they're controlling for a wide range of factors, but I'd put money on it just being the same sort of spurious correlations.
At this point I think if a good idea walked up and smacked him on the head, the name alone might doom it. It has been an also-ran in a confusing number of categories, so depending on your age you may remember it as a very different kind of failure than I do. Sort of the converse of trademark dilution - it is clear what the name is and who owns it, what's muddy is what the service is supposed to be.
"I just put my models on a usb drive then plug said drive into the printer."
You must have a lot of spare time on your hands.
"It works great locally" - Um, no it doesn't?
They've made a nice easy-to-use ecosystem. For $400 you can get a P1S that supports adding an AMS, auto bed leveling, enclosed-chamber printing, high precision, high print speeds, and 300/100C nozzle/plate temps, and has an easy cloud print service and a robust ecosystem of models you can just download and print with no extra config straight from the app.
But yeah, their behavior is increasingly entering bad-actor territory. I wonder how long it'll be before they lock entry-level printers into their branded filament?
No, it's more about how teams work. Teams have a scope. They don't typically go beyond that scope. So if my team owns the Foo and Bar modules, I work on those. But if there's little important work on Foo and Bar, but a lot of important work to be done on Baz, it's generally organizationally difficult for us to work on Baz. Typically we need to be lent out by our manager and seconded to the other team. Which can be a lot of red tape and politics.
Now if you're imagining some alternate world where programmers an be moved at will- then we're already one big team instead of multiple small teams.
And no, a smaller team doesn't win every time. If it did, then then smallest team possible is teams of 1 and we'd all do that. There are sweet spots, which depend on the organization, the work to be done, and the importance of that work. For some that's bigger, for some smaller. I've definitely worked on teams that were both too small for the work, and that were too big.
They can, under some circumstances. If the scope of what they work on is too small to fill the team's feature set. Or if the work they would be doing is significantly less important than other work to be done, having them in one large team makes it easier to move to more important work and can get critical features built faster. In that case it may not be overall more work done, but it may move the important stuff quicker. If larger teams weren't useful on some level, we wouldn't have teams at all- we'd all be individuals.
They're one of the 4 biggest stock brokers in the US. If you aren't trolling, you're showing yourself to be really ignorant.
In the end- good engineers with sufficient experience and support will get stuff working with any methodology. Bad ones or ones insufficiently supported will fail with any methodology.
There are some things that agile works well for, but it's really limited to domains where you can quickly build something tangible for feedback and you have stakeholders willing and able to give frequent feedback. UIs are a good example. It's a horrible fit for anything that requires actual research, or that can't be shown to low technical knowledge customers frequently (in other words anything that actually needs weeks or months of backend work, algorithm writing, or infrastructure to be written).
The problem with that is the skills needed to manage and the skills needed to do real work (let's take programming as an example) are pretty distinct. Someone can have both, but they tend to have one or the other. Forcing those without the skills to do the practical work into doing it doesn't actually help the team, it just slows everyone down. And if they get on the critical path of any project you can be royally fucked.
There are a couple of ways to solve this problem:
1)Larger team sizes. This can work if the team owns enough to keep everyone busy, but it can lead to effectively being independent subteams calling themselves one team while being inconvenienced by each other.
2)Each manager managing multiple independent teams. This can work if it doesn't overload the manager. The biggest problem is when the manager decides one team is more important and doesn't support the other(s) enough. This works better the closer the teams are, as it requires the manager to know fewer sets of collaborators and politics
I was buying drives to add another stripe when the pricing started to ramp up - I try to buy them over time to get different drives from different lots. Now I wish I'd just bought a bunch.
This time last year they were $369, sometimes cheaper. The most recent one I bought was $500. The cheapest I see them right now is $769.
I think I'll be waiting on that new stripe, but at least I have four spares to keep the existing system running.
I'll wait.
(Executive orders are orders to the executive branch. If you aren't an executive branch employee, they have as much authority over you as a postcard from me does.)
Also a good time to remember that a big part of the anti-Biden case from the techbro money types was how stifling and onerous the "please don't make dangerous robots" guidance was. Bill Ackman upside down in clownshoes on a unicycle, with a kazoo up his ass.
Your metaphor would make a lot more sense if kids were designing Lego sets that Lego then sold and vastly under compensated the creators of those sets (while doing a piss poor job of keeping those kids from being contacted directly by adults)
1. Backups were stored on the same volume as live data, and were destroyed by the same command. I agree that is a bad design on the vendor's part, but dude's responsibility was to read and understand the system he was using, and he tacitly admits he didn't understand that:
This is the part that should be a red alert for every Railway customer reading this. Railway markets volume backups as a data-resiliency feature. But per their own docs: "wiping a volume deletes all backups."
2. No, I think you misread - he says he didn't understand the token's scope:
We had no idea — and Railway's token-creation flow gave us no warning — that the same token had blanket authority across the entire Railway GraphQL API, including destructive operations like volumeDelete. Had we known a CLI token created for routine domain operations could also delete production volumes, we would never have stored it.
3. DR !=backups. Disaster recovery is is ensuring you have a path back to operational health from disasters. It is a set of plans, procedures and assets that has to be rehearsed. We test our ours once a year; if you are not exercising your procedures, you don't have a DR plan.
Further, the "agent obtained the key itself" - from stuff it was allowed to dig through. It found the credential hardcoded in a script it has access to. This required three different fuckups to happen:
(1) They didn't understand the scope of the token - see above.
(2) They hardcoded the token (which they didn't understand to be 'root' scoped) in a script. This turns any disclosure into a full compromise.
(3) They obviously let the robot root around lots of stuff it shouldn't have access to. Even aside from the disaster that happened, that's an invitation for adversarial disclosure - if this didn't get them, something else would have at some point.
Replace the word "AI agent" with "rogue employee". Would you blame yourself for them going postal and burning your business down?
To start with the utterly obvious, an LLM is not a human, and if you attempt to substitute one for the other, you are necessarily taking responsibility for the robot's actions. This is the same logic as not leaving weapons laying around where kids can find them, except some do kids have the capacity to know better than to use them.
That aside, I do agree that in early-stage companies you're not going to have the safeguards you need to survive a rogue employee or carelessly deployed robot, except probably around the bank account. Which is all the more reason to to be careful and understand your tools, or pay someone to do that for you.
The industry is shoehorning this shit into every product and service out there despite multiple documented examples of safeguards not working.
Oh my god. Tech companies are exaggerating their capabilities. This is a never-before seen crisis - how can other companies possibly be expected to understand that advertised claims may not be accurate or products might even be dangerous? My faith in capitalism is crushed. Please pass me my High Noon beverage so I can drink it while driving my Ford Pinto as my kid uses their Samsung Galaxy in the back seat.
To the landlord belongs the doorknobs.
