Many people and projects have tried to ditch OpenSSL in favor of LibreSSL, WolfSSL, MbedTLS, etc, but by now many have returned to OpenSSL. The IQ curve meme with "just use OpenSSL" applies.

I don't see how OpenSSL can recover from it's 3.0 disaster. They would basically have to write off the past few years of development work and start over from version 1.1.1

I have systematically and successfully banned OpenSSL across all of my Rust projects. Sure, RusTLS shares a few C crypto primitives with OpenSSL forks. But I've never been happier with the overall library.

Rustls is great.

I think it's also worth pointing out that https://pkg.go.dev/crypto/tls has no OpenSSL in it.

Whenever Wolfram brings up cellular automata again, I think of John Conway who got tired of being known for Conway's Game of Life.

Try this: https://www.terrygodier.com/phantom-obligation/ascii

What comes closest is scandir [1], which gives you an iterator of direntries, and can be used to avoid lstat syscalls for each file.

Otherwise you can open a dir and pass its fd to openat together with a relative path to a file, to reduce the kernel overhead of resolving absolute paths for each file.

[1] https://man7.org/linux/man-pages/man3/scandir.3.html

This is a (3) man page which means it's not a syscall. Have you checked it doesn't call lstat on each file?

Fair, https://www.man7.org/linux/man-pages/man2/getdents64.2.html is a better link. You'd have to call lstat when d_type is DT_UNKNOWN

in what way does scandir avoid stat syscalls?

Because you get an iterator over `struct dirent`, which includes `d_type` for popular filesystems.

Notice that this avoids `lstat` calls; for symlinks you may still need to do a stat call if you want to stat the target.

> Zip with no compression is a nice contender for a container format that shouldn't be slept on

SquashFS with zstd compression is used by various container runtimes, and is popular in HPC where filesystems often have high latency. It can be mounted natively or with FUSE, and the decompression overhead is not really felt.

Just make sure you mount the squashfs with —direct-io or else you will be double caching (caching the sqfs pages, and caching the uncompressed files within the sqfs). I have no idea why this isn’t the default. Found this out the hard way.

Wouldn't you still have a lot of syscalls?

Yes, but with much lower latency. The squashfs file ensures the files are close together and you benefit from fs cache a lot.

"I/O is the bottleneck" is only true in the loose sense that "reading files" is slow.

Strictly speaking, the bottleneck was latency, not bandwidth.

Another interesting choice of GitLab's CI is to effectively display `head -c N` of the logs instead of `tail -c N`.

Some builds produce a lot of output, and Gitlab simply truncates it. Your job failed? Good luck figuring out what went wrong :)

Showing the last N bytes makes so much more sense as a solution to the artificial problem of CI output being too large.

Um, no? It does a tail.

Exactly. The discussion should center on the fact that Microsoft's shift was a contingency, not a technical necessity. It cannot have escaped them that their design choices create a legal point of entry for data requests that they are then obligated to fulfill, which would not have been the case with proper end-to-end encryption; in that case they would have told authorities that they simply cannot fulfill these requests.

That's a false dichotomy. You can hold an organization accountable to the law without requiring them to maintain a "master key" to your private data.

It isn't required.

> Since then, there has been no further development of the service.

That's not true, the website and app both got a major redesign after acquisition.

It is mainly cosmetic and probably due to sharing resources (web template) with their other products. There are no new features.