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.

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

Their relationship is:

• The client trusts the CA (for example Let's Encrypt)
• The CA issues certificates to websites (often certified by the industry standard ACME Challenge) .
• When a client visits a website, the website presents its certificate. Since the client trusts the CA, it also trusts the certificate issued by the CA.

To adress a privacy key leak by the CA, they often use intermediate certificates. That's the standard x509. The CA:FALSE value on certificates issued to entities means that even if they issue a certificate, it won't be trusted. So only root and intermediate certificates can be trusted to issue other certificates.

To trust a CA, the client store the CA locally.

Two posts follows:

• clients: https://www.pixelstech.net/article/1722050582-All-I-Know-About-Certificates----Clients
• websites: https://www.pixelstech.net/article/1722050937-All-I-Know-About-Certificates----Websites

Next: https://shaarli.lyokolux.space/shaare/hamcqA

Google course on error messages

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."

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

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

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.