"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.
Greetings Filipinos, its a trap. Do not trust the US. They will exploit your labor and pay you pennies (do those still exist anywhere?). They are selling you a bill of goods. Fire your representatives that are allowing this. No jobs are coming, only higher energy costs, more pollution, more fat cats, and more corporate ownership of your political system. Abort ship.
chimeing in late, but, yes i know that, and thank you all for the help, and hospitality, i know a number of vets that were and still are grateful for the support.
> We're not prisoners of history. We don't have to go back to being serfs for the few people who own all the land, oil, food, energy, data centers, and operating systems. I hope.
Unfortunately, that is the current stage of humanity. We all currently live in a global subscription model for food, housing, safety, etc. No doubt that we will move beyond it eventually, but the current organization of society is kept in place by the owner class which benefits from the current arrangement.
One of the steps for moving beyond it is educating the modern day serfs (our peers) about reality as it is and alternative visions of a future where we are no longer selling our labor to the owner class. It will take generations.
Worth mentioning that Chinese people have a vastly different perspective on new technology, in the west people are incredibly pessimistic. It's not the technology itself, it's the surrounding system that makes that difference. The alternative vision for the future already exists.
There's not really a way to bypass Google if they don't want there to be, and that's what they're moving towards. The only long-term solution is to cut Google out entirely.
Motorola with GrapheneOS is an interesting prospect. The space is ready for disruption and the tools to do it are more available than ever. Maybe it will come from the EU. Who knows, but Google overplayed their hand, IMO.
Also, let's be clear about the mobile landscape right now. Many apps aren't written in Java or Swift, but instead are being transpiled from other languages like TypeScript and using UI libraries that aren't locked to the mobile platform itself.
When a new mobile platform enters the space it will require some react-native and capacitor glue code and we are in business.
on an often under reported note, police body cams have led to an increase in police brutality as opposed to a reduction.
https://prismreports.org/2024/07/16/complex-troubling-histor...
excellent book on the topic: https://thenewpress.org/books/copaganda/
reply