- encode()/decode() have used UTF-8 as the default since Python 3.2 (soon, 15 years ago). This is about the default encoding for e.g. the "encoding" parameter of open().
- This (along with n+1) is somewhat encouraged in business applications due to the prevalence of the repository pattern.
- It is very noticeable to basically everyone when you consume cannabis regularly.
- Hierarchical databases, which are often more similar to what we would consider a file system today, predate relational ones by a decade or two.
- WALs are typically DB-page-level physical logs, and database page sizes are often larger than the I/O page size or the host page size.
- But we know this is not actually robust because storage and power failures tend to be correlated. The most recent Jepsen analysis again highlights that it's flawed thinking: https://jepsen.io/analyses/nats-2.12.1
- SSDs have three block/page sizes:
- The access block size (LBA size). Either 512 bytes or 4096 bytes modulo DIF. Purely a logical abstraction.
- The programming page size. Something in the 4K-64K range. This is the granularity at which an erased block may be programmed with new data.
- The erase block size. Something in the 1-128 MiB range. This is the granularity at which data is erased from the flash chips.
SSDs always use some kind of journaled mapping to cope with the actual block size being roughly five orders of magnitude larger than the write API suggests. The FTL probably looks something like an LSM with some constant background compaction going on. If your writes are larger chunks, and your reads match those chunks, you would expect the FTL to perform better, because it can allocate writes contiguously and reads within the data structure have good locality as well. You can also expect for drives to further optimize sequential operations, just like the OS does.
(N.b. things are likely more complex, because controllers will likely stripe data with the FEC across NAND planes and chips for reliability, so the actual logical write size from the controller is probably not a single NAND page)
- The 5800X3D is an almost four year old CPU (2022), which was the last major product on its platform (first product in 2016, last new chipset launched in 2020). The successor platform (AM5) was released just months later and is now about 2/3rds or so through its lifecycle.
Normally an old, used CPU for a dead 10yo platform will go for a small fraction the MSRP. Not a multiple. Silicon economy seems in a good shape.
- > I assume any Wi-Fi camera has basically the same problems.
ftfy
- You’re in for a surprise then once you actually go look at the performance.
- > My HN addiction is now vindicated as I would probably not have noticed this RCE until after christmas.
Always makes sense to subscribe to the security-announce mailing list of major dependencies (distro/vendor, openssh, openssl etc.) and oss-security.
- Free jailbreaks for everyone though!
- I still quite often have even Opus 4.5 generate empty indented lines (regardless of explicit instructions in AGENTS.md not to (besides explicitly referencing the style guide as well), the code not containing any before and the auto-formatter removing them), for example. Trailing whitespace is much rarer but happens as well. Personally I don't care too much, since I've found LLMs to be most efficient when performing roughly the work of a handful commits at most in one thread, so I let the pre-commit hook sort it out after being done with a thread.
- Just consider the sheer number of computations offloaded to TMUs. Shaders would already do nothing but interpolate texels if you removed them.
- Not so sure about formal verification though. ime with Rust LLM agents tend to struggle with semi-complex ownership or trait issues and will typically reach for unnecessary/dangerous escape hatches ("unsafe impl Send for ..." instead of using the correct locks, for example) fairly quickly. Or just conclude the task is impossible.
> automatic code formatters
I haven't tried this because I assumed it'll destroy agent productivity and massively increase number of tokens needed, because you're changing the file out under the LLM and it ends up constantly re-reading the changed bits to generate the correct str_replace JSON. Or are they smart enough that this quickly trains them to generate code with zero-diff under autoformatting?
But in general of course anything that's helpful for human developers to be more productive will also help LLMs be more productive. For largely identical reasons.
- Besides limiting the length and number of outstanding IO requests, SFTP also rides on top of SSH, which also has a limited window size.
- Ford actually makes a highly practical electric work vehicle. It's called E-Transit.
- Alternate parse: "we put flock(2) under surveillance: go(1) makes them behave differently"
[heavy green check mark]
[red x] The latter form also has the genuine disadvantage that nothing ensures the two keys are the same. I've seen typos there somewhat often in code reviews.