324 private links
In most of these cases, waiting until we’ve reached the pain point where we’re forced to confront the issue makes solving the problem a much bigger ordeal than if we’d addressed them along the way. At the same time, premature optimization is seen as a bad thing.
How can we reconcile these two facts?
The solution is perhaps to weaponize Jevons paradox and impose real constraints to optimize against, constraints that are smaller than the sum of all available resources.Let me tell you, if you deploy and dogfood your software on a raspberry pi, then it will be fast on a Threadripper too. If you can navigate a codebase in vim in an 80x25 terminal, then you can navigate it in a powerful modern IDE as well.
Resources and capabilities are tricky. Intuition often sells the idea that they allow us to do more, but often they allow the same, but at greater cost.
Hardcore IndieWeb fully embraces existing IndieWeb principles; there’s really nothing new or different there. The key aspects of Hardcore IndieWeb are control over your content and portability of your website:
- If your content doesn’t primarily exist on your own hard drive, you don’t fully control your content.
- If you don’t have a copy of your published HTML and web assets on your own hard drive, it’s not truly portable.
“Did I just read 2,500 words that tell me to write my own HTML and upload it to a web server?” Yeah. You did.
If this seems like ridiculous advice in 2026, I think that’s largely the result of how we’ve strayed so far from the original simplicity we had when working with the web.
Yes indeed.
Est-ce que les parents sont inconscients de faire prendre le vélo aux enfants le long de la route?
Le point intéressant c’est que c’est dit par des automobilistes qui sont la circulation et le danger en question.
Une vision pessimiste puisque la surveillance est de plus en plus possible.
It's a stance; never about quality, voice and/or style, around for other human made products.
But after programming in Rust for 10 years, I think that your coding style has the biggest impact on how your Rust code will look and feel.
People often say Rust’s syntax is ugly, but I’d argue the syntax is the least interesting thing about Rust. The semantics (the bits and pieces the language provides to express your ideas and how those bits combine to build interesting things) are much more important.
Parsing a .env can be clunky in basic algorithm, but elegant in Rust.
Tips:
read_to_string()instead of using a path, opening a file, creating a vector, adding the content to the vector to make a string- Use type inference:
let mut cfg = HashMap::new() - Lean into the typesystem:
.lines()to split strings safely and iterates over the linessplit_once()to get each key-value pair for each lines
- leverage error handling: use an enum to list all possible errors with important values and
thiserrorcan handle the error message
fn parse_config_file(path: &str) -> Result<HashMap<String, String>, ParseError> {
let content = read_to_string(path)?;
let mut config = HashMap::new();
for line in content.lines() {
match KeyValue::try_from(line) {
Ok(kv) => { config.insert(kv.key, kv.value); },
Err(ParseError::InvalidLine(_)) => continue, // Skip invalid lines
Err(e) => return Err(e), // Fail on any other error
}
}
Ok(config)
}
and why this code structure offers more extensibility!
Rust’s beauty is in its semantics and the core mechanics it provides: ownership, borrowing, pattern matching, traits, and so on. If you merely look at its (admittedly foreign) syntax, you overlook the real elegance of the language.
If there is anything that makes Rust “ugly”, it isn’t its syntax but the fact that it doesn’t hide the complexity underneath. Rust values explicitness and you have to deal with the harsh reality that computing is messy. Turns out our assumptions about a program’s execution are often wrong and our mental models are flawed.
Fortunately, we can encapsulate a lot of the complexity behind ergonomic abstractions; it just takes some effort! So don’t worry: once you start to confront your bad habits and look around for better abstractions, Rust stops being ugly.
Suite aux batailles pour avoir des climatiseurs LIDL, l'auteur dénonce la campagne de publicité sans avoir les stocks nécessaires pour les vendre.
Because with slow software comes also a higher degree of care.
It's not (only) the CLI but the mental models that ones must have and fully understands.
The key points:
- A commit is its entire worldline
- Commit content is both a snapshot and a patch
- Remotes have fuzzy identities and time lag
- Branches aren't quite branches, they're more like little bookmark go-karts
- Merge conflicts are actually just difficult
git pullexists
Selon le nombre de jours qu'on a vécu, le temps d'une journée paraît plus ou moins grand par rapport à nos jours déjà vécu.
Le message que je souhaite faire passer est que si tu ne veux pas ou peux pas donner d’argent à un projet que tu estimes pourtant qu’il le mérite, il y a également la solution pour toi de donner de ton temps. Va parler du projet, convaincre d’autres personnes qui elles peuvent donner de l’argent de donner. Tu peux donner 5 euros, et/ou convaincre 10 personnes de donner 5 euros : cela sera encore plus utile pour le projet auquel tu crois au final, vu qu’il récoltera plus d’argent que ce que tu aurais pu donner. Et surtout, il y a tout ce temps que tu as pris pour ce projet, dont on peut difficilement mesurer la valeur
Use UIs instead of writing code. Ok.
I don't believe this is the case. In my opinion, LLMs do not represent a layer of abstraction, but rather a layer of automation. It doesn't abstract away the code layer, it automates it.
I believe in the importance of making understandable software. To this end, I'm working on projects that further this goal.
Primarily, I develop ReTangled, an Entangled-compatible bi-directional tangler written in Rust. It's meant to extend literate programming as far as it can go while integrating it as tightly into existing toolchains as reasonable. As of writing, it's in the early stages of development. I welcome contributions!
First files are awesome, because the file format is the API to understand the content.
You may create a file in one app, but someone else can read it using another app.
After this introduction, an everything folder for social media is the theory: the folder would include everything you've created across different social apps. In that world, a “Tumblr post” or an “Instagram follow” are social file formats.
Bluesky, Leaflet, Tangled, Semble, and Wisp are some of the new open social apps built this way.
The author then details a typical social media post in JSON format, and how to store them as files. Domain names can be used to split each social media.
Then how to store a like with identity files (and the standard DID).
An example of such architecture is available at https://pdsls.dev/at://did:plc:fpruhuo22xkm5o7ttr2ktxdo
The apps then reacts to the change made in the social filesystem.
Encore un kudo pour Fabrice Bellard, cette fois de John Carmack.
About the movie Avengers, weeknotes, stickers, BuJo (the brand is bad, but the system has a lot of good ideas), Tacos.
We could have machines sending raw QUIC packets directly over the physical link or with minimal encapsulation + metadata for routing, in some case bypassing the need for a networking stack (i.e. directly talking to the optic fiber driver).
As John Quiggin writes, the pre-2020 Musk was the Musk of Tesla, batteries and Starlink. The post-2020 Musk is the Musk of Starship, robotaxis, Cybertrucks and Twitter – a string of commercial flops and assets that literally exploded.
It matches the "Dead Economy Theory" from https://www.owenmcgrann.com/p/the-dead-economy-theory.
The actual dead economy risk is that our institutions and markets will continue to move capital from productive activity into memestocks, vibes, and bubbles.
That's not just a dead economy – it's one that'll kill everyone you love and everything that matters.
The idea is to die young as late as possible
Distributing Rust crates via git URLs instead of crates.io