Skunkleton

In the before times, and sometimes now even, the way I always coded was by thinking/discussing the work, then hacking up various interesting bits, then throwing it away and doing it the "right" way. Plan mode makes it harder to go back and forth between "hacking" and "thinking" phases.

Related username?

To answer the original question, most people who care about their filesystem at all care about its stability. Not just "does it work now" but also "will it work and improve over time". Infighting puts the future at risk.

If you ignore the ethical issues, and you shouldn't (!!!), there is an appeal to mined diamonds, and it is exactly what you say above. The idea that some dinosaur or tree or whatever got mushed down is really interesting too.

> In the first case, TFA refutes by claiming 'wrong' repeatedly, which does not convince me of anything. If anything, Zitron is probably right in this regard, since the majority of progress in recent LLM tech has been setting up of guardrails to cajole the models using 'agents'.

You don't have to like them, use them, or consider them "good enough", but the idea that models haven't gotten better in the last two years is ridiculous.

I wouldn't trust it with a credit card, or really any sort of non-reversable decision making. Most of what I do outside of work either requires physical interaction, or is something I do for fun. For now, I assume that is what people use this stuff for. Fun.

You are forgetting that there are multiple multi-core servers.

Kagi is an aggregator for other, some paid, search APIs. They have, at least in the past, served some percentage of their results from Bing's API among others for example. Kagi seems to me to be dependent on these APIs being available, if they were to go away, so would Kagi.

I am a happy subscriber of Kagi though, they provide a really excellent service.

Or get this - you get a drm free copy and they let you redownload/stream it for and undefined (hopefully long) period of time. After that you can play your copy or use a copy from elsewhere.

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.

Watts * seconds are joules. Joules is a unit of energy. Watts are power.

> 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.

wow! we are in the future!

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.

You must be joking. Google ties all of your searches to you wether you log in or not.

Yeah, this is basically what happened with prop 65 as well.

My understanding is that the rules around those is similar to prop 65 rules. So unfocused as to dilute the original purpose.

Because spacex already bought xai.

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.

I didn't add a why. Here is why.

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.

My experience is that "asking staff for ideas" does not lead to successful products. Sometimes, sure, but in general it does not.

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.

Yes, that is really all it is.

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

That’s an extraordinary claim.

Over commit is a design choice, and it is a design choice that is pretty core to Linux. Basic stuff like fork(), for example, gets wasteful when you don't over commit. Less obvious stuff like buffer caches also get less effective. There are certainly places where you would rather fail at allocation time, but that isn't everywhere and it doesn't belong as a default.

The question that isn't answered completely in the article is how useful are the pipelines for these startups? The article certainly implies that for at least some of these startups there very little value add in the wrapper.