xcjs

I...do not miss XP, but I understand the nostalgia attached to it.

I learned a lot of technical skills on XP, but that's what made me appreciate the architectural decisions behind UNIX-likes all the more.

A minor complaint, but I hope they remove the yellow highlights throughout Wear OS. It's just unnecessary.

Are they insane?

• The touchbar needs to go
• Make Fn + horizontal arrow keys Home and End again
• Get rid of the copilot key for the Developer Edition at least so I can still use the right Ctrl for VM escaping

I replaced my existing XPS 13 with a used 2019 model for the first reason alone. At this point, I'll just look for a different model and brand entirely.

Of course!

Valid, but not standard and more inconvenient.

Additionally, you act like query strings can't be used to track you when they certainly can.

Most of the advantages of Gemini are implemented in the client and not the protocol itself.

The Docker client communicates over a UNIX socket. If you mount that socket in a container with a Docker client, it can communicate with the host's Docker instance.

It's entirely optional.

There's a container web UI called Portainer, but I've never used it. It may be what you're looking for.

I also use a container called Watchtower to automatically update my services. Granted there's some risk there, but I wrote a script for backup snapshots in case I need to revert, and Docker makes that easy with image tags.

There's another container called Autoheal that will restart containers with failed healthchecks. (Not every container has a built in healthcheck, but they're easy to add with a custom Dockerfile or a docker-compose.)

I would recommend installing EmuDeck!

It's really not! I migrated rapidly from orchestrating services with Vagrant and virtual machines to Docker just because of how much more efficient it is.

Granted, it's a different tool to learn and takes time, but I feel like the tradeoff was well worth it in my case.

I also further orchestrate my containers using Ansible, but that's not entirely necessary for everyone.

The issue is that some of those techniques are only useful after the client has rendered the content rather than before.

You can tinker in the image in a variety of ways, but make sure to preserve your state outside the container in some way:

1. Extend the image you want to use with a custom Dockerfile
2. Execute an interactive shell session, for example docker exec -it containerName /bin/bash
3. Replace or expose filesystem resources using host or volume mounts.

Yes, you can set a variety of resources constraints, including but not limited to processor and memory utilization.

There's no reason to "freeze" a container, but if your state is in a host or volume mount, destroy the container, migrate your data, and resume it with a run command or docker-compose file. Different terminology and concept, but same result.

It may be worth it if you want to free up overhead used by virtual machines on your host, store your state more centrally, and/or represent your infrastructure as a docker-compose file or set of docker-compose files.

You can set your new tab page to a local HTML file.