With a caveat that when dithering in color, you need both: linear RGB for diffusion/color blending, and a perceptual color space for palette search. Distance in sRGB is more closely aligned with perception of color than linearized RGB.
It could work for classifying honest/innocent differences.
However, LLMs are incredibly naive, so they could be easily fooled by a malicious actor (probably as easy as adding a comment that this is definitely NOT a backdoor).
BTW, libjpeg turbo had been selected by JPEG (the group) as the reference implementation.
There's no reason to entertain the old incompatible libjpeg fork. It didn't have any worthy compression improvements, and if you can use something less universally compatible, there's JPEG XL and AVIF, or even the old JPEG with arithmetic compression or Lepton recompressor.
> Unfortunately, most people seem to have taken the wrong lesson from Rust. They see all of this business with lifetimes and ownership as a dirty mess that Rust has had to adopt because it wanted to avoid garbage collection. But this is completely backwards! Rust adopted rules around shared mutable state and this enabled it to avoid garbage collection. These rules are a good idea regardless
Ownership and borrowing are very useful regardless of performance and memory management.
They help to reason about the program, enabling local reasoning instead of global. When your function gets an owned object or exclusive reference, you know nothing else will mutate it (and you get that without resorting to purity/immutability). You don't need defensive copies.
In your methods you can return temporary references to internal objects, and you don't have to worry that users will keep them too long (such as use a handle to a resource after you close/delete the resource).
There are many useful patterns that can be expressed with control over sharing, copying, and mutability, and memory management is just one of them.
Whether that’s the sweet spot really depends on what your goal is.
The languages that you mention are several times slower than Rust for non-IO bound stuff (in the computer language benchmarks game). If this speed penalty matters for what you are doing, then idiomatic Rust can be much better than Haskell or OCaml code tuned for performance.
And when it comes to Linear Haskell specifically, GHC does not use linear types for performance optimization. If this has changed recently, I’d be thankful for a source to read more.
What I can tell you is that there are tasks that I cannot do in Python because my work would take 70 times longer to finish than if I did it in Rust. And that’s not a delay on the order of seconds but on the order of weeks.
Spot on, Rust is only for very special use cases, where the only viable alternative would be raw C, or C++ with its wrong defaults, instead of any other compiled language.
Between Python and Rust there is a myriad of compiled languages to chose from, no need for Rust for those 70x improvement.
Yet, to come back to the microbenchmarks reasoning, many folks will still pick up Python's productivity over Rust's 70x speed improvement.
You are a reasonable person. I don’t know why you are arguing that one approach fits every use case. In your earlier post above, you declared a sweet spot that fits everyone. All I’m saying is that the sweet spot depends on the application.
If Python’s productivity made up for its problems, then the OS you’re using (kernel + significant parts of userland) would be written in Python, too. But it isn’t, because sometimes its speed penalty is prohibitive. This is not a controversial statement. And the OS is not a “very special use case.”
I am typing this from an OS that is mostly written in Java, with only enough C, C++ and Rust for when it matters.
Rust will probably never replace Java on this OS, or Kotlin, for the applications on Play Store, that aren't a game engine. It isn't even officially supported on the NDK.
Just like on my fruity devices, it is Swift, with non copyable types that will be used for systems services and firmware, not Rust.
This is the kind of sweet spot I am talking about.
Python only came into the picture, as an example of people that don't look into performance charts before picking their tools.
And if Python community was half as serious as the Lisp community in JIT/AOT toolchains, who knows, maybe some would be crazy enough to create a Python Machine.
> it is Swift, with non copyable types that will be used for systems services and firmware
When you mention firmware, do you know of examples where Swift is used for this, or is this an aspiration? Are you talking about Swift for Arduino maybe, or do you have something else in mind?
Open-source projects depend on their community and contributors, and community management is inherently political. No matter what "neutral" thing you do, some contributors will approve of that, and some will see it as a red flag.
Even saying "no politics!" will be seen by some people a political stance — as an approval of the status quo (which may be unfavorable to some groups of people), or even as a denial that certain social problems exist, and a red flag that you won't help them if someone discriminates against them.
Even in a "no politics" environment the you will end up having to decide what is "political" and what isn't, and that is a political stance! Someone will have a Bible quote in their email signature — is that neutral or political? Then is Quran okay too, or rainbow emoji? And when you tell people to stop this circus, the "no politics" policy itself will be questioned as a political stance against free speech, freedom of religion, freedom of expression, freedom of association, etc.
> Open-source projects depend on their community and contributors, and community management is inherently political. No matter what "neutral" thing you do, some contributors will approve of that, and some will see it as a red flag.
There's this saying some people have, "there's three things you don't talk about at work: sex, politics and religion". (I think an older version had "money" instead of "sex"–from the days when sex wasn't talked about so much that we didn't even talk about the fact that we didn't talk about it.)
And it isn't necessarily bad advice. Do we really want heated workplace arguments about Israel-and-Palestine, Biden-vs-Trump, etc? We have to work with people who have completely different views from us on big picture political issues. Sometimes it is better we just agree to disagree and focus on what we have in common – airing those disagreements in detail can just produce negative feelings and disruption.
But of course, every office, every open source project has politics. But that's the thing, people traditionally draw a distinction between "micropolitics" (the politics of our workplace) and "macropolitics" (national politics, geopolitics). You cannot escape micropolitics, it is everywhere, it is inevitable. But macropolitics, yes, we should avoid it at work whenever possible.
Of course, people will then bring up "the personal is the political", and it is true. Transgender issues, for example: a big political controversy, but obviously for transgender people a very personal one.
However, even there, I think there is a useful distinction. A transgender employee isn't breaking the "no macropolitics at work" rule by being transgender, or talking about their personal experiences, or so on. But, consider Lynn Conway's public campaigns against the psychologist J. Michael Bailey and the sexologist Ray Blanchard – even though that was obviously very personal for her, it wouldn't have been appropriate for her to carry it on at work. Well, she actually did use her UMich web page for those campaigns, but the norms about this are different in academia than in your average workplace.
And politics is personal for all kinds of people: I remember back in 2010 when the Israeli military intercepted the "Gaza Freedom Flotilla", the team I was in at the time had some very heated discussion over it. Afterwards, a Jewish team member talked to me privately, and I could tell the whole discussion had made him feel rather uncomfortable, because it felt personal to him. And one of the other participants in the conversation was Palestinian, so it was obviously personal to him too. But still, in hindsight I wish the whole discussion had never happened, and I regret my own (rather peripheral) role in it. We broke the "no politics at work" rule, and it did pointless harm to our cohesion as a team.
It's basically an OS too. Application isolation, UI toolkit, 3D graphics APIs, storage, network stack. Netscape was right — browsers reduce the underlying OS to (a buggy set of) device drivers.
Usually people compile a "hello world" exe, and implicitly extrapolate that size to all programs of all sizes.
...which is then followed by arguments about how libc's own size should be compared to other libs that need to be linked statically and do a different amount of work.
Do you realize that at least half of the bike accidents don't involve cars? Getting rid of the cars won't get rid of the dangers of the two wheeled, unstable machines that frequently toss the riders when the brakes lock.
I'm not sure where you're getting this. This link doesn't have pages and it gathers information from a variety of sources.
The top of the report clearly says, "50% of crashes are a single bicycle accident (HOPE)" and "21% of crashes are a bicycle-bicycle crash (HOPE)". Is it possible that only 29% involve cars?
