If your goal is to understand the quality of the espresso shot, rather than experience a high quality espresso shot, letting it cool off provides a useful data point.
> Schiendelman sent you a message on hacker news clarifying what its showing. It's you asking about the plant she told you about, it finding that text message, summarizing, and also proving with the text that it's accurate.
In the simplest possible terms: this is total bullshit security theatre. At no point has there ever been a bomb or even a bomb threat carried out via usb device names. There is absolutely no reason to even look at the names of Bluetooth devices on a flight.
The title is misleading and not in the article. This change is for business/enterprise accounts. Also, these are still credit based. The change is that credits now operate on tokens like the API rather than on messages as they used to.
The TurboQuant paper is from April 2025. I’m sure the major labs knew about it on, or even before, the day it published. Any impact it had would have been a year ago. Yet I keep seeing these posts and discuss completely ignoring this.
Can we please start talking about this in that context? We already know what TurboQuant will do to DRAM demand. We already know what it will do to context windows. There is no need to speculate. There is no need to panic sell stocks.
It could also be that masters degrees concentrate in fields with lower compensation. Teachers are in high demand, but yet they still tend to have something beyond an undergrad.
Most of the staff doesn't have the visibility into the business to understand what may or may not make money. You can have a great idea, even on that could be a successful product, but it could still be a bad fit for the business.
This depends on your goals. If your goal is to drive efficiency into your processes, drive down tech debt, or fix pain points for customers of your existing products, sure. Most people at a your company with have thoughts, and lots of them will have good ideas.
If your goal is to pivot the company into new verticals, or to develop an entirely new product, then "asking staff for ideas" isn't a likely way to succeed.
I don't think it's odd. Sacrificing deep understanding, and delegating that responsibility to others is risky. In more concrete terms, if your livelihood depends on application development, you have concrete dependencies on platforms, frameworks, compilers, operating systems, and other abstractions that without which you might not be able to perform your job.
Fewer abstractions, deeper understanding, fewer dependencies on others. These concepts show up over and over and not just in software. It's about safety.
It's not just fork. The operating system overcommits memory all over the place. For example, when you map memory, that can/will succeed without actually mapping physical pages. Even "available" memory is put to some use and freed in an asynchronous way behind the scene, a process that is not always successful.
Honestly, I think overcommit is a good thing. If you want to give a process an isolated address space, then you have to allow that process to lay out memory as it sees fit, without having to worry too much about what else happens to be on the system. If you immediately "charge" the process for this, you will end up nit-picking every process on the system, even though with overcommit you would have been fine.
If you make structural changes to your filesystem without a journal, and you fail mid way, there is a 100% chance your filesystem is not in a known state, and a very good chance it is in a non-self-consistent state that will lead to some interesting surprises down the line.
In the context of the kernel, it’s hard to say when that’s true. It’s very easy to fix some bug that resulted in a kernel crash without considering that it could possibly be part of some complex exploit chain. Basically any bug could be considered a security bug.
> The spontaneous explosions become so common and normalized that just about everyone knows someone who got caught up in one, a dead friend of a friend, at least