There are a number of serialization libraries that outperform JSON in NodeJS.

It's important to avoid generating extraneous garbage when doing these kinds of benchmarks.

It's important to provide an appropriately sized buffer when performing serialization.

If you care about serialization performance, consider using a different programming language with better tradeoffs.

A Finite State Transducer seems to be the best algorithm instead of a full index search.
The data don't need to be stored in a database indeed. They only need to be searched as text.

Tout le monde peut utiliser la config git user.name et user.email.

Afin de vérifier ces commits, ils faut indiquer à Git de les signer

Générer une clé
ssh-keygen -t ed25519 -C "votre@email.com"

Puis instruire à git de l'utiliser:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

Puis ajouter cette clé de signature dans la forge logicielle.

Pour GitLab: https://docs.gitlab.com/user/project/repository/signed_commits/

Github place ce bug comme "ineligible", puisque cela ne donne pas accès aux repos ni privilèges, donc ce n'est pas une faille au sens strict.
Cepeeendaaaaaant, l'identité affichée influence les décisions; et il incombe à l'utilisateur de vérifier les signatures.

Source: https://infosecwriteups.com/the-curious-case-of-github-commit-spoofing-a-lighthearted-exploration-54ddbaaaf40a?gi=861657732a48

You're running Android but not the official one? reCAPTCHA does not work anymore.

Practical resources created by the author, grouped by references

Maps are unrelated to the software release. That's definitely a good thing.

Les liens de téléchargement du logiciel ont été modifié.

D’après Thomas Klemenc de Malcat, le fichier distribué par les pirates contient bien l’installeur de JDownloader, associé à une charge malveillante de type RAT (Remote Access Trojan) écrite en Python.

Cette nouvelle méthode permet de sécuriser plus rapidement Firefox, puisque l'IA montre une faille et essaie de résoudre le problème. Cela sert de base de travail.

Rappelons que d’un point de vue réglementaire, les informations qui révèlent l’orientation politique relèvent de ce que le RGPD qualifie, dans son article 9, de « données sensibles ».

ainsi que l'article de Korben https://korben.info/les-donnees-de-120-000-adherents-lfi-dans-la-nature.html

During my research I identified nine types of comments:

• Function comments: They prevent the reader from reading code in the first place. Instead, after reading the comment, it should be possible to consider some code as a black box that should obey certain rules
• Design comments: they states how and why a given piece of code uses certain algorithms, techniques, tricks, and implementation. [...] With such background, reading the code will be simpler.
• Why comments: explain the reason why the code is doing something, even if what the code is doing is crystal clear.
• Teacher comments: They teach instead the domain (for example math, computer graphics, networking, statistics, complex data structures) in which the code is operating, that may be one outside of the reader skills set, or is simply too full of details to recall all them from memory.
• Checklist comments: sometimes because of language limitations, design issues, or simply because of the natural complexity arising in systems, it is not possible to centralize a given concept or interface in one piece, so there are places in the code that tells you to remember to do things in some other place of the code
• Guide comments: they do a single thing: they babysit the reader, assist him or her while processing what is written in the source code by providing clear division, rhythm, and introducing what you are going to read.
• Trivial comments: a bad one, a guide comment where the cognitive load of reading the comment is the same or higher than just reading the associated code.
• Debt comments: debt comments are technical debts statements hard coded inside the source code itself:
• Backup comments: the developer comments older versions of some code block or even a whole function, because she or he is insecure about the change that was operated in the new one. We have git now.

Comments can be considered analysis tools; and they are often harder to write than code.

1. Clarity is job #1
2. Interfaces exist to enable interaction
3. Conserve attention at all costs
4. Keep users in control
5. Direct manipulation is best
6. One primary action per screen
7. Keep secondary actions secondary
8. Provide a natural next step
9. Appearance follows behavior
10. Consistency matters
11. Strong visual hierarchies work best
12. Smart organization reduces cognitive load
13. Highlight, don't determine, with color
14. Progressive disclosure
15. Help people inline
16. A crucial moment: the zero state
17. Great design is invisible
18. Build on other design disciplines
19. Interfaces exist to be used

• Convert external sources to motivation: a bot that reminds a new subscription for example
• Leave tasks unfinished: I try to leave a task 90% finished at the end of a working session. It feels slightly worse than closing out the work, but it makes starting the next day 10x easier.
• Use the thing myself, as much as possible
• Address the pain, instead of pushing through: The trick, is that you can almost always make these less painful.
• do nothing before work
• update the users (or keep a notebook)
• get a partner
• no zero days, to avoid listless guilt

Google course on error messages

The point is many actors can detect the flaw during the same week. A 90 days window to deliver a fix no longer holds

Every attempt to score open source is not accurate.

The most consequential mistake is treating the absence of a signal as a low value of that signal.

Missing FUNDING file

Easy to collect doesn't mean something

Stars on Github (ICU only 3.5k, 2.5k), CVE counts (compare the Linux kernel to

One number, many units

npm "download" is mostly a count of CIcache misses. Dependent counts are different between a string-padding helper on npm and a C compression library that is statically linked and distributed as vendor or a git submodule.

Github as the visible universe

Not everything is on GitHub. Contributors (so the bus factor count too)

Project identity is different on different platform

curl has many names across platforms.

Invisible funding

The most common funding arrangement for critical infrastructure is none of those. It’s a maintainer employed by Red Hat, Google, Intel, Canonical, or a hardware vendor, with the project as some or all of their job, and that arrangement leaves no trace in any file a crawler can fetch. The second most common is consulting and support contracts around the project, which is similarly invisible.

and it compounds because the project doesn't look like an npm package. "The quiet system library with one tired maintainer and no dashboard footprint is exactly what we built all of this tooling to find, and it remains the thing the tooling is structurally worst at seeing."

Somewhere out there, someone wrote a really good blog post today. You'll probably never find it. Google won't show it to you. Social media buried it under engagement bait.

Bubbles tries to surface it. Community voting applied to thousands of personal, independent blogs, with identity and discussion routed through the Fediverse.

Hacker News and Lobste.rs have community voting figured out, but non-tech content gets drowned by the tech majority. Kagi Small Web curates thousands of personal sites, but has no community-driven ranking. Blog directories help you find blogs, not today's best blog post. Social platforms own the conversation. Mastodon is decentralized and ad-free, but you only see what the people you follow share. RSS is great, but solitary. There's no collective signal telling you what's worth reading today.

L'espagne a tranché: l'homéopathie, c'est du flan