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..
It should as it isn't running Windows app through wine but via a dedicated VM (managed by a docker container). Anything that can be ran in a qemu vm, should work fine.
Seems to be an evaluation license... that said, you can run recent versions of windows unregistered for pretty much as long as you want... they disable some UI enhancements, like changing the desktop, but it tends to function.
Not sure on older versions... MS used to generate new evaluation ISOs every few months with a hard fuse in them... Can't speak for recently since it's been years since I've needed to test for old IE versions. If you choose to customise, I'd suggest going with one of the "lite" modified versions of Windows 10... since this will reduce the default surface a lot without the bridge to some of what Win11 added while jumping the shark.
Fairly sure it requires you to have your own copy of Windows; it doesn’t provide one for you. Otherwise it would be a massive licensing violation / piracy. If you look at similar projects like WinApps, that’s how they work.
In part that’s an interesting question. Some of the processors on the Ugreen line are Xeons, so they should support ECC, but I’m not sure the MB does.
But you don’t really need ECC for ZFS. That’s a kind of myth that has been debunked several times. Sure, it’s always good, but ZFS works just fine without it.
(I’m on my phone so it’s dificult to find a good source for the claim, but if you search a bit, you’ll find some good blog posts talking about it).
Well, that's the thing. I've also found some posts saying it's a myth and you'd be fine, but the ratio of posts recommending ECC to posts debunking the myth is like 10:1.
The important key point is that you will not lose anything by using ZFS without ECC compared to using any other file system without ECC. The myth is that you specifically need ECC if you’ll be using ZFS, not that ECC is a really good idea for any file system.
Bottles has certain sandboxing capabilities on top of wine. Plus, Bottles can download and manage various wine versions, separate from your distro's offerrings. It's pretty neat. Of course, technically, you could do almost everything it offers manually via scripting and your own wrappers, but that can be said about almost any software. Heck, C and C compilers are nothing else than syntax sugar for writing assembly.
To expand on this, at least historically, Wine unfortunately didn't progress in a straight line, often new versions came with additional features or bug fixes which made some applications run or run better, while others ran worse.
Obligatory question, are you planning on adding support for additional countries?
reply