Where do companies otherwise prioritize long-run development over short-term output? In my experience, generally nowhere. So why would this make managers push RTO more?
Some who already want RTO may use this as an excuse, but I would think it would actually reduce RTO pressure overall, as it confirms less short-term productivity, which is what companies actually care about.
In some areas and for some people, Medicaid probably does count as proper healthcare. But it certainly doesn't for other people / other places. Imagine there being one doctor within a multi-million person metro area who takes Medicaid for some sub-specialty. 90 minutes away from you by car. And you don't have a car. This is the reality for millions of Medicaid recipients, including ones I know personally in Chicago.
If I were making a single line code change, then Claude's "style" would take me enough time to edit away that it would make it slower than writing the change myself. I'm positing this is true also for the parent commenter.
This is interesting, and I'd say you're not the target audience. If you want the code Claude writes to be line-by-line what you think is most appropriate as a human, you're not going to get it.
You have to be willing to accept "close-ish and good enough" to what you'd write yourself. I would say that most of the time I spend with Claude is to get from its initial try to "close-ish and good enough". If I was working on tiny changes of just a few lines, it would definitely be faster just to write them myself. It's the hundreds of lines of boilerplate, logging, error handling, etc. that makes the trade-off close to worth it.
This has been true since it stopped being true for Internet Explorer. I've not noticed any significant change over time. I have been using Firefox for over 20 years.
I believe it's that the bus can only serve one chip at a time, so it has to actually be faster since sometimes one chip's data will have to wait for the data of another chip to finish first.
Corrupt Qeynos Guards -- Qeynos is SonyEQ spelled backwards. And, depending on your race / class, it didn't even take that much to make them hate you.
Killing the corrupt guards, often one at a guard tower in the Plains of Karanas west of town, and turning in their bracelets to a non-corrupt guard at the bridge to South Karanas, was great XP for quite a few levels in the midgame. And it is possible to repair the corrupt guard XP (slowly) with low-level quests.
This matches my memory. When I got my dad's old work computer with QuickBASIC on it, and I discovered the compiler, and could write programs other people could "just run", I felt like a real programmer for the first time.
Surprised not to see this mentioned in the article.
Lots of places (including a former employer) have done tons of work to upgrade internal infrastructure to support HTTP/2 just so they could use gRPC. The performance difference from JSON-over-HTTP APIs was meaningful for us.
I realize there are other solutions but this is a common one.
The reason this is an issue is that the sub value changes often enough that intergrations ignore it rather than bother users with having to re-OAuth.
As far as what Google is doing in the bug bounty, that's a good question -- we don't know. The author is proposing two new values, for the domain and user, that wouldn't change in the cases that sub changes now, but would change in this case.
Yes, it adds an additional level of complexity to do role-based access control within k8s.
In my experience, that access control is necessary for several reasons (mistakes due to inexperience, cowboys, compliance requirements, client security questions, etc.) around 50-100 developers.
This isn't just "not zero trust", it's access to everything inside the cluster (and maybe the cluster components themselves) or access to nothing -- there is no way to grant partial access to what's running in the cluster.
I understand that reaction, I feel it too. But what is the alternative? Sharing details of an assault?
Note that in Tim's response at the bottom of the article, he says clearly he believes the board that the details can't be shared and that they are serious.
> For example, in one run, it edited the code to perform a system call to run itself. This led to the script endlessly calling itself. In another case, its experiments took too long to complete, hitting our timeout limit. Instead of making its code run faster, it simply tried to modify its own code to extend the timeout period.
They go on to say that the solution is sandboxing, but still, this feels like burying the lede.
I see why you'd think a human-read one would be better, but in my experience that's not the case. It's not that easy to read out loud and actually sound good.
I've spent a fair amount of time listening to free audiobooks (https://archive.org/details/librivoxaudio) including many that are out of copyright like these, as opposed to modern but in the public domain.
After listening to a few minutes of "Frankenstein" on his site, I would say that these OpenAI generated voices sound better than almost all of the human-read ones on Librevox, both in audio and performance quality -- these are voices that are designed to sound good, and they succeed at that.
> Each individual file, unless otherwise noted, is released under the terms of the MIT License. A copy of this license can be found in LICENSE.mit.
Worth . . . noting . . . that every file with license info says MIT; none say anything else. So the "unless otherwise noted" is purely future-proofing.
Some who already want RTO may use this as an excuse, but I would think it would actually reduce RTO pressure overall, as it confirms less short-term productivity, which is what companies actually care about.