One of the two associations is in power and actively dismantling society. The other develops a technical product and runs a Lemmy instance many people and other instances have blocked.
Handling or concluding them a bit differently seems quite fine to me.
That being said, I've seen plenty of Lemmy dev connection criticism on this platform. I can't say the same about FUTO.
No Gotos, All Subs
That's sub-optimal
😏
I don't think Microsoft will hold your hand. It's the local IT or usage support.
In my eyes the main issue is the decision makers falling for familiarity and marketing/sales pushing.
Which makes it even more absurd/ironic that after the switch investment, they invest again into a switch into something that is not really better.
Either way, this time though, there's a lot more relevance and pressure to make a change, and a lasting change. The environment is not the same as before.
I diffusely remember reading about two/twice. But I can't provide sources either.
What is the vulnerability, what is the attack vector, and how does it work? The technical context from the linked source Edera
This vulnerability is a desynchronization flaw that allows an attacker to "smuggle" additional archive entries into TAR extractions. It occurs when processing nested TAR files that exhibit a specific mismatch between their PAX extended headers and ustar headers.
The flaw stems from the parser's inconsistent logic when determining file data boundaries:
- A file entry has both PAX and ustar headers.
- The PAX header correctly specifies the actual file size (size=X, e.g., 1MB).
- The ustar header incorrectly specifies zero size (size=0).
- The vulnerable tokio-tar parser incorrectly advances the stream position based on the ustar size (0 bytes) instead of the PAX size (X bytes).
By advancing 0 bytes, the parser fails to skip over the actual file data (which is a nested TAR archive) and immediately encounters the next valid TAR header located at the start of the nested archive. It then incorrectly interprets the inner archive's headers as legitimate entries belonging to the outer archive.
This leads to:
- File overwriting attacks within extraction directories.
- Supply chain attacks via build system and package manager exploitation.
- Bill-of-materials (BOM) bypass for security scanning.
The attack surface is the flaw. The chain of trust is the flaw/risk.
Who's behind the project? Who has control? How's the release handled? What are the risks and vulnerabilities of the entirely product delivery?
It's much more obvious and established/vetted with Mozilla. With any other fork product, you first have to evaluate it yourself.
GlobalSign certificat
😺
The post How Functional Programming Shaped (and Twisted) Frontend Development from four days ago provides great broader context about the history and concerns. It ends with what this post seems to primarily concern itself with: The alternatives, improvements, innovation, and opportunities we may be missing / should evaluate.
You could call yourself enlightened 😏
I strongly disagree.
Coloring is categorization of code. Much like indent, spacing, line-breaking, aligning, it aids readability.
None of the examples they provided looked better, more appropriate, or more useful. None of the "tests" lead me to question my syntax highlighting. Quite the contrary.
By reducing the highlighting to what they seem important, they're losing the highlighting for other cases. The examples of highlighting only one or two things make it obvious. When you highlight only method heads, you gain clarity when reading on that level, across methods, but lose everything when reading the body.
I didn't particularly like their dark theme choice. Their initial example is certainly noisy, but you can have better themes and defaults with more subtle and more equal strength colors. The language or framework syntax and spacing can also influence it.
Bolding is very useful when color categorizes code to give additional structure discoverability, just like spacing does.
I failed the question about remembering what colour my class definitions were, but you know what? I don’t care. All I want is for it to be visually distinct when I’m trying to parse a block of code
Between multiple IDEs, text editors, diff viewers and editors, and hosted tools like MR/review diff, they're not even consistently just one thing. For me, very practically and factually. Colors differ.
As you point out, they're entirely missing the point. What the colors are for and how they're being used.
lol wut