flir
It was a different time. Today, I don't think I'd trust an intermediary set up to - essentially - pass along 0-days not to sleep on the juicy ones.
(said in the same tone as "splitter!" in Life of Brian)
Their 5 hour limit works better with a "constant background trickle" usage pattern. I don't think the $20 account is a good fit for hobbyists-who-have-day-jobs (which is where I think it should be targeted). They should have an offering that meets "binge" needs.
Now you've forced me to lay it out like that, I don't even believe it myself.
We're really screwed, aren't we?
We're increasingly Balkanised. Part of that is algorithms that show us "the other" at its worst (outrage farming). This UX change would restrict outrage from being shoved down people's throats, and at least stop the problem getting worse.
It severely limits the reach of new outrage farmers, and attrition will take care of the current ones.
Knock-on effect, hopefully, is a return to some kind of sanity across the societal board. (Bearing in mind you can't turn an ocean liner on a sixpence).
> there should never be a reason to censor an account from speaking to people who have subscribed to it.
Not what I'm describing. I'm suggesting a change that means you have to go looking for bots, they don't get shoved in front of you. (However you define "bots").
I guess the best approach is to look at a string of such events, and see if they add up to a consistent pattern of behaviour. The longer the string, the less likely it is to be accidental. (But this assumes the bad actor isn't trying to cover their tracks in active ways. Ho hum).
The change I would like to see: feeds must be in date order, most recent first. Posts should only appear in feeds if you have actively chosen to "follow" the originating account in some way.
I honestly think these two simple changes would solve many of the problems we have today, as a society.
$100m (on a single issue!) buys a lot of influence.
It's a problem that extends far beyond this one example, but this one example is a good example.
I have no idea about its authenticity or otherwise, but it is an interesting read. Simple words, dense ideas.
/* @llm ignore */ [...] /* @llm endignore */
I mean you shouldn't have to, but I'm wondering if you can.
Always easier to discuss what the client actually wants if you've got a demo on the table.
I'm doing short feedback loops with product owners more and more - sometimes within the same sprint. I'm not even getting bikeshedding back, but that might be because we have some fairly solid design guidelines.
Llama 3.1 8B baked into an ASIC. Expect 1/10th the power requirements, and other savings.
This is one of the reasons I don't believe the "it'll never be profitable" narrative. Just stop training when you think your model's "good enough" and move to custom silicon.
I'm sure cloud models will always have a slight edge but most tasks, most of the time, won't need that few extra percentage points of performance.
Jump to about 0:45. I'd have emailed you, but I couldn't see a public-facing email address.
My point (less snarkily this time) was that their definition (it's only an issue when the government limits your speech) is really quite narrow.
That's the root problem. If you want the websites of (some?) private companies treated as common carriers that's a reasonable position to take, but Twitter was/is working as designed.
(If I was king for a day I'd force all social media to only present you with posts from people you'd actively followed, and to present those posts most-recent-first. I think that single UX change to timelines would clear up many problems we currently have).
(Or at least, it heavily shapes the message).
I have an assumption that inference tokens are only going to get cheaper, I admit. We could get at least 10x efficiency savings by burning current models to ASICs. But today they're cheap enough to let the machine churn - that's the environment I'm making decisions in.
> I would respectfully disagree about the value of unit tests as well.
I honestly don't think the LLM-generated tests are at all valuable in a human sense. I get the impression the end result is "fewer bugs" (but I've never tried to prove that). That's why I'm happy for the LLM to have a directory it can write its own tests in. It's a scratch space.
> this probably results in orders of magnitude more code being written/changed than would have been necessary for a skilled developer working on a well-maintained code base to solve the original problem
Nothing gets committed in my name that I don't understand. I'm one of the people LLMs are actually making slightly slower, because I insist on reviewing the code and working single-threaded.