Would it be enough to have <body> hidden using an inline style in the initial html response and when everything is loaded, one would remove the style using javascript?
Thanks! The countries available now are the ones with presence on Ticketmaster (and in the UK, one additional provider). If it proves popular I'll certainly look at scraping more ticket sites!
That's a reasonable baseline, yes. I would also consider trying running it on Arch Linux, because it usually has newer library versions and it's the base of SteamOS.
At this point, that's exactly what Windows needs. As Microsoft only adds new features and doesn't remove almost any, Windows is getting reaaally bloated. And what was Microsoft's response? Everyone should buy a new faster computer to run Windows 11.
Tbh, a better strategy would to slim down Windows again would be to remove all the new user-facing stuff which was added over the last two decades. There have been significant improvements in the kernel and DirectX, but on the surface, Windows somehow managed to remove user-facing features while at the same time adding an incredible amount of bloat in layers above the core operating system. From a usability perspective the Windows desktop UI in Win2k was singnificantly better than anything that came after.
> remove all the new user-facing stuff which was added over the last two decades
That's not all that needs to be removed from Windows, and it's not what they're interested in removing. The old MFC, GDI, COMCTL, COMDLG, Winsock etc. must be a lot higher in their "do delete" list.
Well, yes, but APIs aside, as long as the developers and users have the choice, they won't choose a new backwards incompatible solution if when they can stay with their old solution.
Look at Apple Macs, all went from x86 to arm, breaking software and fixing incompatibilities later. Users had no choice but to use m1 macOS if they wanted a new device.
For short lived one off scripts and programs, bun is amazing. Everything you need without configuring much and minimal external dependencies.
For a large project, bun seems to have become almost a framework like experience? Once you start using all its features, you get locked in and you do everything "the bun way".
Why not use Jellyfin then? It's basically an open source alternative to Plex. You run Jellyfin on your server and in Apple TV use Swiftin (Jellyfin + Swift) for integration.
I've wanted to migrate multiple times. Unfortunately, it failed on multiple places.
Firstly, podman had a much worse performance compared to docker on my small cloud vps. Can't really go into details though.
Secondly, the development ecosystem isn't really fully there yet. Many tools utilizing Docker via its socket, fail to work reliably with podman. Either because the API differs or because of permission limitations. Sure, the tools could probably work around those limitations, but they haven't and podman isn't a direct 1:1 drop in replacement.
> podman had a much worse performance compared to docker on my small cloud vps. Can't really go into details though.
Are you using rootless podman? Then network redirection is done using user more networking, which has two modes: slirp4netns is very slow, pasta is the newer and good one.
Docker is always set up from the privileged daemon; if you're running podman from the root user there should be no difference.
Well, yes, but rootless is basically the main selling point of podman. Once you start using daemons and privileged containers, you can just keep using docker.
No, the main selling point is daemonless. For example, you put podman in a systemd unit and you can stop/start with systemctl without an external point of failure.
Comparing root docker with rootless podman performance is apples to oranges. However, even for rootless pasta does have good performance.
Some tools talk to docker not using the docker CLI but directly through its REST API. Podman also exposes a similar REST API[1]. Is Podman with its API server switched on substantially different from the docker daemon?
Docker daemon runs as root, and runs continuously.
If you're running rootless Podman containers then the Podman API is only running with user privileges. And, because Podman uses socket activation, it only runs when something is actively talking to it.
Sometimes it's possible to not use the Podman API at all. Convert the compose file to quadlet files with the command-line tool podlet and start the container with "systemctl --user start myapp.service". Due to the fork/exec architecture of podman, the container can then be started without using the Podman API.
Yes, either quadlet or handwritten podman CLI in .service files is the way to go. I don't like using generate-systemd because it hides the actual configuration of the container, I see no point in being stateful...
Yes because the API server is stateless, unlike the docker daemon. If you kill it you can still operate on containers, images, etc. by other means, whereas if you kill the docker daemon the CLI stops working too.
SELinux-related permission errors are an endless nuisance with podman and quadlet. If you want to sandbox about anything it's easier to create a pod with full host permissions and necessary /dev/ files mounted, running a simple program that exposes minimal functionality over an isolated container network.
Thats funny, podman had better performance and less resource usage on my resource constrained system. I chalked it up to crun vs runc, though both docker and podman both support configuring alternate runtimes. Plus no deamon..
