And crucially, the DoD, through the normal procurement process, agreed to Anthropic’s terms and made the purchase. Much later, the Secretary of Defense threw a political fit and tried to change the terms.
3,927 karma · joined October 25, 2011
> 12. General terms
> Changes to the Services. Our Services are novel and will change. We may sometimes add or remove features, increase or decrease capacity limits, offer new Services, or stop offering certain Services.
> Unless we specifically agree otherwise in a separate agreement with you, we reserve the right to modify, suspend, or discontinue the Services or your access to the Services, in whole or in part, at any time without notice to you. Although we will strive to provide you with reasonable advance notice if we stop offering a Service, there may be urgent situations—such as preventing abuse, responding to legal requirements, or addressing security and operability issues—where providing advance notice is not feasible. We will not be liable for any change to or any suspension or discontinuation of the Services or your access to them.
You're not buying a gallon of milk or a pound of flour. You're buying hosted software that the host reserves the right to modify.
What's interesting to me as someone who has sold a lot of software to a lot of software companies is that many enterprise vendor agreements explicitly allow companies to pentest their vendors with advance notice and coordination. I don't think any of our clients ever exercised that clause; I expect it's going to be exercised a lot more going forward because it's so easy to do now.
Some of these design decisions seem indefensible to me. For example, what the authors call "Suspension":
-> Static: Await points guaranteed to suspend -- JavaScript
-> Dynamic: No guarantees on awaiting tasks -- C# · Swift · Tokio · Smol · Asyncio · Trio
What is "await" if not a synonym for "suspend"?!?
async/await is one product of a long line of thought that says "threads are too hard for programmers to get right". Threads (really, shared memory) have real usability issues for developers, but once you grok the semantics (which largely map to the physical execution model in a CPU) that knowledge is transferrable across virtually all languages and runtimes.
Meanwhile, profit-driven private industry is actually out there making things better.
Scalpers don't buy tickets and not sell them. The most scalped concerts are obviously the most attended
> fans can’t afford the tickets
See above. I assume what you are upset about is that rich fans are the ones going.
> less connection with the artists, less interest in music overall
I think you need to explain your logic here.
I agree. The question remains - why do U.S. municipalities universally and repeatedly fail to successfully implement rapid transit at an efficient price point? Buses, trains, and subways in America have ever-growing budgets (both in absolute and per customer mile terms) with ever-declining quality of service. Just asking for more tax revenue again and again is not the solution.
[1] https://www.citizen.org/article/biden-doj-2024-corporate-cri...
Epic's employees reaped the gains while it rained in the form of paychecks. While it sucks that people are losing their jobs, those individuals received (much of) the upside of this investment and their jobs never would have existed in the first place had the investment not been made. Their paychecks are not being clawed back. Shareholders (including executives who are largely paid via out-of-the money options) are bearing the costs. Consumers also benefit from increased competitive pressure on Valve and subsidized game prices.
Would it be "better" if Epic had not invested in the Epic Game Store and paid a dividend or conducted a share buyback?
> For a web service, that usually means one log event at the end of every request.
The point of a log, as I have seen it used, is to understand what's going on during a request. Yes, some of that is timing / success / failure information, but you also need:
- Logical tracing - at a high level, what decisions did we make (authz, business logic) when serving this request
- Partial failures or warnings - the request may have succeeded, but we may have failed or timed out a call to a dependent service and delivered a partially degraded response as a result
- Tracepoints to support active development - how often do we hit a certain codepath (to help developers roll out or deprecate features)
It's useful to distinguish between "context" (things we know about a request), timing, success, and plain old logging (using human language to describe to an operator what the system is doing). Context should be included with every line - I strongly agree with OP's proposal of wide events, don't make operators ever JOIN if you can avoid it - but it won't always be the same because we learn things about the request as we process it. Yes, if you wait until the end of a request, you will have maximal context, but at the loss of fine-grained detail during processing.
Unfortunately, the US and many other countries have chosen the other path (sporadic enforcement with severe punishment) largely because it's easier to implement. There's a lot of momentum to change this but it's politically difficult at least in America.
And presumably they wouldn’t be shy about telling us if they had.
Also HN: No, not like that