333 private links
That's why we need to embrace fluid design and layouts. 2,300 unique viewport sizes is extreme.
DevRel(ish) is an index of tech groups and the gatherings they run — in a room, online, or both — across every part of the industry.
The website is well made to learn french
An original and dynamic website about the fantasy Thorgal
This website has rich colors and scenes. It's different from usual design system.
I like the tech stack with SQLite. This CMS looks interesting for dynamic data.
Webhooks should be considered ordered logs.
Webhooks spread because they were the cheapest thing a provider could ship (one HTTP POST) and the cheapest thing a consumer could receive (you already had a web server, so you just added a route).
Webhooks-for-replication are a local optimum, and the proof is the pile of workarounds on the valley floor: signature schemes, dedup stores, idempotent handlers, retry queues with exponential backoff on the provider side and dead-letter queues behind them, webhook logs with replay tooling because consumers keep asking for replays, and my 3 a.m. cron. [...] The pile has an economy on top of it. Svix exists so providers don’t have to build webhook delivery; Hookdeck exists so consumers don’t have to build webhook ingestion.
So here’s the thought experiment. What if instead of the provider telling us when there is new information, we ask the provider what new information it has for us since we last checked?
So it's a pull-strategy again.
Send
Prefer: streamand the response never ends: each change arrives as it commits, over a connection you opened
Ok that's the strategy: an active connexion streaming the changes.
The draft is available at https://welidev.github.io/scroll/.
It pins down the feed, the cursors, the streaming and polling modes, the checkpoints, tombstones, and retention, and it marks the places where my own confidence is lowest.
Une vulgarisation de la faille d'eMudhra
My feeling is that, overall, the situation here is a bit analogous to the discussion here about why I don't like when people talk about how AI gives a 100x or 1000x productivity increase. There are some things that are sped up by a very large factor, easily over 1000000x. And some things don't currently get sped up at all.
This would be the best occasion to release all images to the creative common licences
Getty Images – which has supplied photos and video for news agencies for more than 30 years – has been struggling amid a pile of debt and mounting competition from AI image generators.
The bankruptcy occurs because AI generated images are used instead of relying on suppliers.
The project folderblog looks interesting: turning a folder into a blog sounds promising for small blogs or people who don't want to go technical.
The project is described on https://folderblog.ninepointlabs.com/
Another classless CSS framework
New hardwares are now optimized for vectors- The details are explained in part 2
It takes several hundred lines of code but now we can source the data from my SSDs faster than the copy from the page cache in memory.
Because the reading strategy is not mmap but something custom. The author also uses 6 CPU cores for reading and one core for compute. Note that data in a buffer at 13 GiB/s RAM was faster than 6 GiB/s disk array.
The mmap() call presents the process with a buffer that is a blank slate even when the data is already in memory. The buffer is populated page by page as it's accessed from the page cache. This isn't a copy, it's just the operating system mapping the cached memory into the process. This costs more than it might seem. The worst case with mmap() the counting has to pause at every 4KB page boundary while the kernel processes a fault, tracks down the page of data in the page cache, then updates the page table of the process to insert the memory into the process. Fundamentally this is a process that is limited by the memory latency, not the CPU speed or memory bandwidth. With the potential for TLB walks and searching lists that track the page cache, we’re taking potentially dozens of CPU cache misses and several microseconds of waiting on memory for every 4KB page.
On theory
On a proper modern server the CPUs will let you do IO directly to the L3 cache, bypassing memory altogether. Because PCIe bandwidth is higher than memory bandwidth, on paper we could even get more max bandwidth than we can get from memory if we carefully pin the buffers into the CPU cache.
and for the memory:
This means to take advantage of memory performance you have to actually treat it more like a disk and less like Random Access Memory.
A try is made in part 3
Microservices add CPU and network costs. The video gives some number.
Vendre et gérer des certificats SSL n'est plus rentable économiquement car Let's Encrypt fournit déjà le service gratuitement à beaucoup de sites web.
Les exigences pour une plus grande sécurité que Let's Encrypt sont rares (et cher).
A Wikipedia customized for the device location