Mostly, they try to avoid it by allocating extents instead of blocks (so, they look for a contiguous space to store most files) and by delaying allocation to accommodate for a growing files.
My observation is that it is not completely true. I constantly have a close to full partition in ext4 and there is no secrets when there is no space the filesystem WILL create a bazillion of small extents because, it has no physical choice! and everytime you have a non maxed out extent, it will create an overhead I don't see how magically you can avoid that. And it is not like a few, on my main working partition, extends of a few KB by the thousands per files are created instead of the optimal size of 128MB. If you just use defrag in read mode on it, it is red from top to bottom, you cannot find a block of few MB with no fragmented file in it.
Author here. This article features interactive demonstrations of the spanning tree protocol (an old protocol to detect and fix loops in Ethernet networks) using MSTPD (user-space implementation for Linux) compiled to WebAssembly with Emscripten.
The bug on Linux still exists today on this family (e100, e1000, e1000e). Maybe the root cause is different, but the solution is still to disable TCP segmentation offload and I suppose this is a firmware bug. At some point, Mellanox took over the "top" card segment for servers.
I've assumed it worked fine on Linux but your comment brought me to this after a quick search: https://bugzilla.kernel.org/show_bug.cgi?id=118721. I've not seen any major issues on Linux e1000e defaults but never pushed it harder than laptop usage. I've occasionally tried to make em(4) TSO work on FreeBSD (it works fine on igb(4)) but gave up due to stalls. Linux has GSO (maybe invented partially due to those issues?) so the benefit is a lot smaller there.
It is now mostly unusable for web analytics. So many scrapers are pretending to be browsers. On my site, there is a factor 10 with what I consider an honest view of human visitors.
If you're using it to serve the marketing team, then yeah. We use it more for server performance and metrics that cookie-cutter JS analytics tools can't really provide.
btw, JS-based analytics are no longer as accurate for identifying "real humans" as they used to be. bots have gotten much better at behaving like a person behind a keyboard, so it's increasingly easy for them to make your analytics tool think they're a real user
This is not untrue, but I suppose that if you don't prevent bots from accessing your website, they won't try to use the more advanced scrapers running JS and won't trigger your analytics.
When customers ask me for visitor metrics I tend to explain that it doesn't matter anymore before I show them them the highly inflated absolutely unrealistic numbers.
In France, thanks to STIR/SHAKEN, this is not possible any more for the fixed phone numbering plans (and telemarketers have to register their phone numbers in a subset of this numbering plan). For mobile lines, this is still not 100% implemented due to the difficulty of handling roaming, but I think it is becoming efficient as I didn't have a telemarketer with a mobile number since a long time (they seem to hide their number now).
I have switched from FVWM to awesome because of Lua. Many years later, I have switched to i3 because it's not using a programming language for configuration. It's fine to have a configuration language if you have time to maintain, but your configuration can become quite complex and difficult to evolve. And it is also far more subject to breakage when upgrading.
I think I've found balance by using a Python daemon as a "companion" for my i3 configuration. It listens and react to event. It enhances the configuration, so when it's broken, it's not a big deal. And the interface exposed by i3 is smaller, so less risk of breakage. https://vincent.bernat.ch/en/blog/2021-i3-window-manager#i3-...
I have also restored the very first articles I wrote in the 90s when I was young <https://vincent.bernat.ch/en/blog/2026-old-web-articles>. At the time, they were not "great," but now I think they have some limited historical values. For example, one of them is about how the national phone operator was billing minutes. The information was easy to find in the past but is pretty scarce now.
I didn't use the wayback machine because it didn't archive everything I needed and because I still had the files on my hard drive, but if I didn't, I would have been happy to recover them.
reply