You can look at the network requests to see what it's doing. It's querying the OpenCitations database followed by the DOI.org content negotiation endpoint, which 302's to Crossref (or whoever the relevant DOI registration agency is).
OCI is for running prepackaged software in black boxes from the internet, where you have no interest or ownership of the container internals.
Most of my containers are not like that. Well, actually none are.
systemd-nspawn is for running your own containers, with a VM-like usage pattern (ie not immutable), deployed as part of your overall systemd based infrastructure for when the thing you need to manage is "too big" to be deployed as its own systemd-service unit, but you still want to be able "to systemd" it.
This distinction is a more useful one that the article made. I love dockerfiles and immutability, but there are good cases for mutable containers, too.
You can also do some neat things with "--ephemeral" and "--volatile" to basically overlay the image (or a subset) with tmpfs; any changes to those overlays will be lost when the container is brought down. The specific mount points can be controlled in greater detail via "--tmpfs" and "--overlay".
Containers already are mutable on all popular runtimes. “Immutability” comes from destroying and recreating them from their image, but there’s nothing forcing you to delete/recreate them, and indeed that’s not even the default behavior.
I think you’re conflating packaging and runtime. OCI images are a packaging format while systemd-nspawn is a runtime. Runtimes and package formats are orthogonal.
> systemd-nspawn is for running your own containers, with a VM-like usage pattern (ie not immutable)
Containers aren’t immutable (OCI or otherwise). Again, I think you’re conflating images (the package formats are orthogonal) with their runtime instantiation, the container. OCI images like VM images are immutable, but containers and VMs are mutable.
My main objection to systemd-nspawn (at least as described in the article) is that it lacks a complementary package manager (or rather, that there’s no remotely convenient way to run software packages with it) and so you have to create your containers with manual changes and dodgy bash scripts. Regardless of what runtime you use, that seems like a not-very-maintainable way to manage software.
Never. If he wanted to go the containers route, Podman is there. There is no reason to use Docker anymore. (Only a satellite tool like docker-compose is not 1-1 compatible with podman-compose, but podman has other ways to orchestrate with systemd as part of podman vision for orchestrating.)
Well, for one, KaTeX doesn't do "LaTeX" but a limited subset of the TeX equation syntax.
As such, it can't handle more complicated macros or typesetting anything apart from equations.
To be fair, the Last-Modified header is very sketchy. I use it as one of the heuristics for determining the age of a website in my search engine. It's not great.
It's frequently found incorrect, both older and younger than the actual age of the document. It's a bit of a relic from back in ye olden days when websites were static .htm files in a folder, which is so rarely the case today.
It doesn't help it's also got overloaded uses via If-Modified-Since -style conditional requests.
Plenty of websites also play with the user-visible dates on websites to game search engines - most dates shown in Google results seem to be complete garbage. I don't think Modified-Since is really worse, and it at least gives you a chance to maybe get a date for static pages.
But you are right that If-Modified-Since forces it to be a date for the complete document rather than the content, which might not be as useful to normal users for dynamic pages.
Yeah, my takeaway after having attempted to do so is that properly dating websites is a very hard problem. You can get Google-level-accuracy decent guesstimates relatively easily, but going beyond that is hard.
Not generally useful to show this by default, because nowadays most pages are dynamically generated and although it's technically easy to implement, the last modified header is typically not set to $now.
Well, if Browsers would show it more prominently, there were more motivation to think about it for developers.
But Browsers are bad HTTP clients. Think about bad user experience with file uploads (no built in progress report!?), HTTP auth (not showing status, no logout etc.)
In Chrome you can F12 and go to "Network" tab and then refresh the page. Choose the first file in the list (that's the HTML itself) and you will find "Response Headers" in the "Headers" panel, which includes Last-Modified. It's a bit deep, which makes sense as it's rarely useful.
Last-Modified can have unwanted negative influence on caching behavior. If you want to expose metadata, there's OpenGraph et al. to do the job properly.
This is not a very good explanation, nor is it useful for anything.
A single qubit is not useful for computation and the way it is written doesn't generalize to more than a single qubit.
The code doesn't even really simulate a single qubit properly, since it doesn't use complex numbers.
What they call a "Rydberg gate" is not a gate at all.
Most of the text feels like it's written by an AI.
Hiiiiii :) GitLab team member and the author of the blog post here.
After reading your comment, we swapped out the photo so that no one else would have such an unsettling experience! I liked the compass photo, so I feel a bit silly that I didn't notice what you did! I'll remember your comment and zoom the next time we pick a stock photo, haha. Thank you!
