Hate to break it to you, but you’re not really learning.

Looks trivial and easy to automate.
I possibly would have done it if they had a test suite.
But unless I didn’t look hard enough, they have no tests at all (other than linting)!

opt-level = ‘z’ # Optimize for size.

🙄 😠

You just referenced two languages that don’t have proper sum types. lol.

Also mentioning Microsoft tech while a certain world event is taking place right now. lol.

Gitorious-ed too fast.
Let’s see if you’ll get a team around federation now.

Certain low-memory machines may also want it

This is a part of the misconceptions about it.

It doesn’t meaningfully help with that unless much harder constraints are applied in development where it would become relevant at run-time. It can be relevant for low-storage machines however. That’s what binary size is primarily about after all. And low-storage and low-memory may go hand in hand at times as device properties.

I’m not sure who’s recommending it

See the link in my other comment.

The freeze-the-world “stable distro” concept is an outdated meme, especially when it comes to desktop usage.

In server usage, at least there is the idea of not breaking things by avoiding major version upgrades of used services/daemons. But even then, freezing the used services alone, while letting other system components have what may amount to thousands of fixes for some of them (and yes, a few bugs), is probably better, at least conceptually. But it’s admittedly not a well supported setup, unless you’re willing to basically maintain a distro yourself.

And no, the “stable” distro maintainer is not going to magically backport all the “important” changes, unless backport means applying an almost full diff from a later version of the source package.

(I actually mention this because I remember Debian doing this a long time ago with what I think was ffmpeg. lol.)

Many desktop users know this.
Upstream developers definitely know this, and occasionally write about it even.

(I was a Debian user many moons ago. That was before systemd came to existence, or PulseAudio became default in any distro. Went from stable to testing to sid. Testing was the worst, even stability wise. Sid was the best for desktop usage. Then a sid freeze came because a stable release cycle was near. Went to a rolling-release distro and never looked back.)

There is no deep explanation or anything.

Release profile defaults to -O3. -Oz compromises runtime performance for binary size.

When you start seeing for example network services which are not going to be running in constrained environments, nor do they restrict themselves from using heap allocations and all, when you see them set -Oz in their release profiles. Then you start to see small beginner projects setting it like OP here. You start to wonder if it’s a pattern, and the settings are being copied from somewhere else, with potential misconceptions like thinking it can meaningfully reduce runtime memory usage or something.

I actually think I found the culprit, thanks to one of the projects I was hinting at mentioning it:

https://github.com/johnthagen/min-sized-rust

Looks like we have a second wave of net-negative common wisdom in the ecosystem, the first being optimizing for dependencies’ compile times. But this one is not nearly as bad, as it doesn’t affect libraries.

Welcome.

[profile.release]
opt-level = 'z'     # Optimize for size

It doesn’t matter here, let’s get that out of the way.

But I’m wondering if someone/someplace is wrongly recommending this!

Because lately I’ve been seeing this getting set in projects where their binaries wouldn’t be typically running on environments where this is required or even helpful.

My concern is that some developers are setting this without really understanding what -Oz actually does.

What’s needed is renewed ethos, not just fresh blood.

What’s needed is people who actually like the projects, on the technical level, and use them daily. Not people who are just trying to maintain an open-source “portfolio” they can showcase in pursuit of landing big corpo job.

A “portfolio” which also needs to, in their mind, project certain culture war prioritizations and positionings that are fully inline with the ones corpos are projecting.

It will be interesting to see how much of the facade of morality will remain if these corpo projections change, or when the corpo priorities and positionings, by design, don’t care, at best, about little unimportant stuff like American-uniparty-assisted genocide! We got to see murmurs of that in the last few months.

Will the facade be exposed, or will it simply change face? What if a job was on the line?

I’m reminded of a certain person with the initials S.K, who was a Rust official, and a pretend Windows-user in hopes of landing a Microsoft job (he pretty much said as much). He was also a big culture-war-style moral posturer. And a post-open-source world hypothesiser.

Was it weird for such a supposed moral “progressive” to be a big nu-Microsoft admirer? and one who used his position to push for the idea that anyone who maintained a classical open-source/free-software position towards Microsoft is a fanatic? No, it wasn’t. He was one of many after all.

All these things go hand in hand. And if you think this is a derailing comment that went way off the rails, then I hope you maintain the same position about the effects of all this on the open-source and free-software world itself.

Is it true what some Rust opposers claim?
That the semantic shift of the word “awesome” to mean comprehensive/exhaustive is only observed among ever-positive Rustaceans?
What about the word “curated”?
“A curated list of awesome…”
Is anything missing from the list?
How are tools listed with a 1/5 maintenance rating fit into this?

You should be thankful it’s not 18446744073709551615 days to go.

While pure Python code should work unchanged, code written in other languages or using the CPython C API may not. The GIL was implicitly protecting a lot of thread-unsafe C, C++, Cython, Fortran, etc. code - and now it no longer does. Which may lead to all sorts of fun outcomes (crashes, intermittent incorrect behavior, etc.).

:tabclose

Federation is a bad fit anyway. Gitlab should just state that and reiterate focus on core functionality and sustainability, so we don’t end up with another Gitorious situation.

The Rust hype at least makes sense.

In technical context, yes. I’m a Rustacean myself.
In business/marketing context, …

It’s not you who needs it.
It’s for buzzword chasers and cost cutters.

Rust (=> fast and hip)
Shared (=> outsourced)
AI generated (=> robot devs)

Get it?

If NULL was a billion dollar mistake, imagine how many billions it’s going to be for AI-generated code.

Yeah, sorry. My comment was maybe too curt.

My thoughts are similar to those shared by @Domi in a top comment. If an API user is expected to be wary enough to check for such a header, then they would also be wary enough to check the response of an endpoint dedicated to communicating such deprecation info, or wary enough to notice API requests being redirected to a path indicating deprecation.

I mentioned Zapier or Clearbit as examples of doing it in what I humbly consider the wrong way, but still a way that doesn’t bloat the HTTP standard.

Proper HTTP implementations in proper languages utilize header-name enums for strict checking/matching, and for performance by e.g. skipping unnecessary string allocations, not keeping known strings around, …etc. Every standard header name will have to added as a variant to such enums, and its string representation as a constant/static.

Not sure how you thought that shares equivalency with random JSON field names.

Weak use-case.
Wrong solution (IMHO).

If one must use a header for this, how Zapier or Clearbit do it, as mentioned in appendix A.2, is the way to go.

Bloating HTTP and its implementations for REST-specific use-cases shouldn’t be generally accepted.