hot take: generative AI isn't an existential threat to humanity.
These companies are insolvent and these stories were designed to scare the public, and governments, into implementing regulations that designate these AI corporations the "responsible stewards" for this technology. The ultimate goal is to block competitors and open source alternatives.
They don't know how to make enough money pay their investors so they are resorting to trying to scare the public into submission.
I'm skeptical. The phrase "pacing the frontier" implies disproportionate regulation of firms at the frontier, which if anything would give smaller players time to catch up.
A slowdown that doesn't slow you, that your competitors must also obey, enforced by a government you've asked for an antitrust exemption from, is not a slowdown... it's a moat.
>A slowdown that doesn't slow you, that your competitors must also obey, enforced by a government you've asked for an antitrust exemption from, is not a slowdown... it's a moat.
Why do you believe this is what Amodei is calling for? Why would this be a slowdown that "doesn't slow" Anthropic?
The existential threat is a general public panic. Then the use of that as an excuse for Martial law, with no intention of ending it, and that triggers the out sized response that ends, well, those countries and their populations from viability in the world economy for a decade or more.
Only if you ignore their losses. They are saying they are profitable when not counting their training costs and other expenses. That’s not a good sign at all
How can they exclude training costs?? How is that not fraud? At the exact same time they're literally saying they will never stop training unless the state bans all their competitors
But they are trying very hard to become a public company as quickly as possible? Sure I guess it's literally true but people shouldn't treat it like it's normal. It's like a creepy 40-year-old announcing they're dating someone on their 18th birthday.
When we're looking at whether the company is "insolvent" then they definitely could stop training and it's worth checking if they would survive in that situation, at least for a while.
I think the spending commitments they have already signed close that door too. They don't presently have the revenue to make those commitments regardless of opex; the only way they will be able to hit them is a massive increase in adoption over what we've seen so far. If they stop advancing the models it becomes really hard to see how that doesn't just immediately evaporate. I suspect any "pacing agreement" would include the state bailing out those commitments.
If you exclude model training costs, customer acquisition / sales, and most of employee compensation, sure they're profitable. If, on the other hand, you prefer GAAP reporting to bullshit, then they're entirely in the red.
Hard to argue against it when you get memory holed by playlist entry removals by a cloud service. Much easier living having everything at `.config/mpd/playlists` with git history.
I'm very serious. It's not a simple matter to get any sort of exportable data from these cloud services, and they won't bother to notify you that media that was on your playlist or in your library has been removed. I gave Apple Music a try for about a year. and even that relatively small migration was hellish.
I have an easy time managing a playlist through the many available audio player frontends writing to an .m3u which is itself usable as a file path list in scripts to copy the music from my library to an external device.
There's no physical media here anywhere (necessarily). This is comparing your computer (music on your PC that you purchase beforehand and do whatever you want with) to someone else's computer (cloud streaming that requires the platform to pay a license and get permission, that could one day be taken away without notice).
"In the U.S., the number of civilians whom police have killed annually has only increased each year since the widespread adoption of body camera equipment,"
That is a near textbook case of abusing statistics. Those things are completely independent variables. Perhaps "civilians" (as opposed to what, military?) killed by police increased because crime increased. Or population increased. Or laws changed. Or bullets changed.
Why would we expect widespread adoption of bodycams to decrease the number of criminals shot and killed by police? That starts with the spurious assumption that the police are randomly shooting and killing citizens in droves without cause and bodycams would put a stop to it. As it turns out, this isn't happening, so bodycams have no influence on the variable.
There's no need to read the rest of that article if the authors are trying to secretly sell such a pejorative opinion.
I invite you to go watch a couple hundred bodycam vids on YouTube. It may change your perspective on what police deal with. What I see consistently, regardless of department, is police bending over backwards and using all kinds of non-lethal force, to the point of risking their own lives, before using lethal force. There are well-publicized exceptions but in the vast majority of cases, the officers are facing someone using lethal force against them.
Some of these videos are the result of FOIA requests. Please, make FOIA requests and post these videos where the police are acting so egregiously. We deserve to know the truth about this!
Some less than positive-for-police videos I've seen-
- a weak police officer doesn't take control of the situation and the officer standing behind the first one is shot and killed
- an officer, while chasing a suspect, tazes him as he exits the median grassy area and enters a lane of traffic. The suspect was killed by traffic.
- a forfeiture case where someone's life savings (cash) were confiscated without due process during a traffic stop
I usually use it to edit audio tracks quickly up to 10 minutes long, though I have received nice emails from people who have used for 1hr+ podcasts successfully (though certain heavy operations wouldn't be very fun to use).
For multitrack sessions, there is the ability to export to a .amss file that contains all the settings, markers, tracks etc. For single track edit... it would just crash right now. There is already a feature for caching audio tracks in indexeddb (it's under >File), but honestly it's not a web api I have found to be super reliable. I don't blame the browser developers, because I 'm sure if it was more reliable certain websites would put it to use storing gigabytes of trackers on the user's machine :). For this reason, I haven't made it auto-save the session automatically yet, trying to be a good citizen on the user's computer, maybe that will change in the future if there's a strong need for it.
Also, right now there is no backend, once it loads there are no more requests made to the server, so it's bound to frontend limitations. This is by design, I want it to be an app that respects users, doesn't upload or leak information, no ads, etc, even if it means getting a small hit in functionality in other areas.
I think of it like photopea/pixlr are to photoshop. Quick and easy to use, get you at 90% of the way. If somebody wants to do a serious operation, then by all means go for a paid desktop pro-daw solution :)
i managed to load a 12 hour book. it took some time to load, but once loaded the UI remained snappy, so i guess it is usable. the only problem is that the waveform does not scale when i zoom in.
Did you load it into multitrack, or the regular editor? (in multitrack it does not scale currently, but working on it). On regular editor it should in theory try to zoom.
There is a pyramid cache mechanism for long files, basically it tries to optimize with simple heuristics how many peak-lines to show for every zoom level. The renderer is pretty dumb right now - just old-school 2d canvas "ctx.lineTo" calls - no gpu, so enormous files can really make it slow, this is the reason for the drops (to ease load).
So it might be dropping way too many samples in this case and then not switching properly to the next cache level because the zoom to duration/length ratio is enormous.
> You will notice the trust keyword here. Any operation (such as IO) that has an underlying unsafe mechanism (such as the @print builtin that std.stdio.print uses), must be explicitly trusted, as it is inherently impure.
just document the impure operations and stop forcing the programmer to type extra characters.
that is basically how all large companies behave anyway. socialize the losses (bailouts, layoffs, negative economic impacts in the communities they reside, etc.) and privatize the gains.
