I'm curious how much this is the cause or effect, though?
The publishers have been saying that their ability to promote books has drastically reduced with the internet, along with changes in reading and information habits.
It seems like a book needs a far bigger push today to rise above the noise of the internet (and people's over-abundance of content to consume), and this unfortunately meant that small publishers struggled unless they "joined together" to make a bigger push.
There's extremely small (self published) books and extremely large hits, but the middle is increasingly less viable, it seems. Similar to films.
The hype people are excited because they're guessing where it's going.
This is notable because it's a milestone that was not previously possible: a driver that works, from someone who spent ~zero effort learning the hardware or driver programming themselves.
It's not production ready, but neither is the first working version of anything. Do you see any reason that progress will stop abruptly here?
I've thought for a while now that we'll end up moving to stricter languages that have safer concurrency, etc, partly for this reason. The most prominent resistance against such languages was the learning curve, but humans like OP aren't looking at the code now.
This is standard practice. They need to use current lossless formats to display examples to people who don't have the format yet. They are still showing accurate examples of compression artifacts. I'm not sure what else you'd expect them to do.
Strange, as Cloudinary's test had the opposite conclusion -- jpegxl was significantly faster to decode than avif. Did the decoders change rapidly in a year, or was it a switch to new ones (the rust reimplementation)?
If decode speed is an issue, it's notable that avif varied a lot depending on encode settings in their test:
> Interestingly, the decode speed of AVIF depends on how the image was encoded: it is faster when using the faster-but-slightly-worse multi-tile encoding, slower when using the default single-tile encoding.
In theory yes, but in practice they usually have the speaker up far higher than they are speaking themselves so we do only hear one side clearly.
I think the high distractability is a trifecta of volume, non-naturallness of the sound (compression etc: feeling out of place in the space) and this point.
In this quote I don't think he means it from the business side. He's claiming more data allows a better product:
> ... the answers are a statistical synthesis of all of the knowledge the model makers can get their hands on, and are completely unique to every individual; at the same time, every individual user’s usage should, at least in theory, make the model better over time.
> It follows, then, that ChatGPT should obviously have an advertising model. This isn’t just a function of needing to make money: advertising would make ChatGPT a better product. It would have more users using it more, providing more feedback; capturing purchase signals — not from affiliate links, but from personalized ads — would create a richer understanding of individual users, enabling better responses.
But there is a more trivial way that it could be "better" with ads: they could give free users more quota (and/or better models), since there's some income from them.
The idea of ChatGPT's own output being modified to sell products sounds awful to me, but placing ads alongside that are not relevant to the current chat sounds like an Ok compromise to me for free users. That's what Gmail does and most people here on HN seem to use it.
Is this why everyone only seems to know the first half of Dario's quote? The guy in that video is commenting on a 40 second clip from twitter, not the original interview.
Why do people always stop this quote at the breath? The rest of it says that he still thinks they need tech employees.
> .... and in 12 months, we might be in a world where the ai is writing essentially all of the code. But the programmer still needs to specify what are the conditions of what you're doing. What is the overall design decision. How we collaborate with other code that has been written. How do we have some common sense with whether this is a secure design or an insecure design. So as long as there are these small pieces that a programmer has to do, then I think human productivity will actually be enhanced
(He then said it would continue improving, but this was not in the 12 month prediction.)
This is a great example of its limitations. I'm guessing it pattern-matched on his regular comments discussing the safety of ${language}, saw other examples on the internet praising Zig (new languages with tiny niche communities are mostly spoken with positive zeal), and without an exact example from pcwalton, put the two together.