Because that display mode is often also sluggish in the scenarios where you would reach for it, including client-side input handling, and it loses information like the radius of interdiction bubbles.
Slow car computers aside, it doesn't really make a difference in the scheme of things. Spend the time backing up now or later. Also, maybe you need to use your trunk and you'd rather have it opening into free space instead of another vehicle or a wall.
wkhtmltopdf is pretty out of date at this point and headless Chrome/Chromium or something that wraps them is probably a better and safer, roughly equivalent, alternative. Docker might not be a great option if you're already running a containerized service and don't want to deal with getting them to play nice together.
I agree that stacking multiple modal dialogs should generally be avoided, and if whatever you're doing is complex enough you should consider whether it needs to be in a dialog at all.
What I'm talking about is if I'm using popover to alert the user about something, let's say another user updated the page they were viewing, and they clicked into a confirmation dialog fractions of a second after the alert arrived, the alert is now behind the dialog and attempting to click on it either does nothing or closes the dialog, depending on how I've configured the dialog.
As the application developer, I'm responsible for deciding how the modes in my multi-modal application behave, and I want top-level alerts like this example to be interactable and in front of confirmation dialogs in all modes, regardless of which one opened first. With the current top layer behaviour, that is not really achievable without doing something like reparenting open alert popovers into the most recently opened dialog, and that's ALSO not properly functional (element state gets reset) until Element.moveBefore() is generally available.
I've been trying to use HTML's native popover and dialog recently. The promise of not having to write/import focus traps, better integration with standard platform "cancel" UX, the top layer concept, etc made them sound great, but in reality it's been kind of painful.
Stacking order when you have multiple modal dialogs and popovers in the top layer is based on most recently revealed element, so that toast that just opened is now hidden under a dialog. Anchoring is currently only supported in Chrome, so popover tooltips show up in the corner. Firefox supports transition animations when opening a dialog but not closing it. The web platform feature needed to tie the mobile back button to closing a dialog isn't actually implemented yet. Frameworks that patch the DOM might clobber modal dialog state because it's a function of both the "open" attribute and the result of showModal().
Some of these will improve but I think the display order problem is here for the long haul.
If you need features offered by the self-managed Enterprise version of a Hashicorp product, I've heard the price tag is something like low six figures per product.
I've only played around with LXC/LXD a little bit, what are some of the Ubuntu image issues? I did a quick google, but the first results seemed to be questions about hosting on Ubuntu rather than with the images themselves.
Relatedly, I was recently horrified to learn that not only will Excel (and LibreOffice Calc) automatically parse formulas in plain CSV files, but there is also a formula that will _run external programs_.
I would guess it's a combination of Framework not having the same deal the big OEMs are getting, OEM grift, and based on the price, Framework appears to be selling retail Windows licenses rather than OEM licenses.
It seems reasonable to me (for a compose-in-prod setup). The standard setup (at least for Rails, in my experience) is that the web server and background job processor will have the same dependencies and nearly identical configuration. Until the app has gone off the rails and I really do need to have the server and worker diverge, this approach seems like less to worry about than maintaining multiple images and duplicated but 98% identical container definitions.
Ruby on Rails lives inside a long-running application server. In development, it has dynamic class loading and will reload on file changes, but in production an app can have a lengthy startup time. It does have the memory problem, but I have never seen the server crash outright as a result of an exception while handling a request.