I find the intermediary classification a bit unconvincing and perhaps unintentionally misleading. It sounds like a nice framework to look at the world and it does describe the particular domain alright and it allows for drawing useful conclusions. Unfortunately solving the problems it highlights would produce marginal gains because I think intermediaries as described are just a special case of something more general. Firms of any kind are acting as intermediaries in the exchange of the products of people’s labor. The effects are all the same, these intermediaries make the exchange easier at the expense of keeping some of the labor products from one end or the other, but usually both. It seems to me that the problem of the platform intermediaries power is just a special case of the power of firms over labor. Which really reduces to the problem of the power of capital over labor. If we somehow solve the platform intermediaries problem, we leave the general problem unsolved. And then if we don’t think in terms of the general problem, we can’t even solve the special problem because the tools needed are controlled by capital. That is the lawmakers who could change the law are paid by the powerful intermediaries (firms) and not by the people on either end of the intermediaries. If we hope to ever solve any of this I think we have to look at the world through the general lens and focus on ways to reduce the amount of capital accumulated by firms from people’s labor. Fortunately there are well known solutions for that and they’re actionable for most people.

I see. Makes sense.

If you need to serve only one user at the time, ollama +Webui works great. If you need multiple users at the same time, check out vLLM.

Why can’t it serve multiple users? Open Web UI seems to support multiple users.

This is the right way to optimize performance. Write everything in a decent higher level language, to achieve good maintainability. Then profile for hotspots, separate them in well defined modules and optimize the shit out of them, even if it takes assembly inlining. The ugly stays its own box and you don’t spend time optimizing stuff that doesn’t need optimization.

There’s a WIP VirtIO driver in a PR but it’s not done yet. VMware’s own VMSVGA is open source if I remember correctly. I wonder if they’ll adapt it to KVM and if they do, whether that’ll be usable in KVM without VMware.

If we get VirtIO 3D acceleration in Windows guests from this, I’d be really happy.

While not entirely wrong, I’d take anything out of free market fundamentalists mouths like the ones at Mises with a gain of salt.

You could use a systemd unit file:

[Unit]
Description=docker_compose_systemd-sonarr
After=docker.service 
Requires=docker.service

[Service]
TimeoutStartSec=0

WorkingDirectory=/var/lib/sonarr

ExecStartPre=-/usr/bin/docker compose kill --remove-orphans
ExecStartPre=-/usr/bin/docker compose down --remove-orphans
ExecStartPre=-/usr/bin/docker compose rm -f -s -v
ExecStartPre=-/usr/bin/docker compose pull
ExecStart=/usr/bin/docker compose up

Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

You’d place your compose file in the working dir /var/lib/sonarr. Depending on what tag you’ve set for the image in the compose file, it would be autoupdated, or stay fixed. E.g. lscr.io/linuxserver/sonarr:latest would get autoupdated whereas lscr.io/linuxserver/sonarr:4.0.10 would keep the container at version 4.0.10. If you want to update from 4.0.10, you’d have to change it in the compose file.

And there are breaking changes in this Jellyfin release.

Sounds a bit like the drug dealer’s business model.

I think federated non-profit video platforms won’t work on large scale without P2P.

Not noticeable with always-on Tailscale with the default split-tunnel mode. That is when Tailscale is only used to access Tailscale machines and everything else is routed via the default route.

Google’s fine. They’re using ARM cores that are built on Samsung’s shittier manufacturing process. Next year they’re going TSMC which should improve power consumption dramatically. The lauded Dimensity 4000 also uses ARM cores, just newer and built on TSMC’s process. By the same token, newer Google SoCs should experience similar performance as they update the cores and manufacturing.

Alternative Title: “Bluesky happy to use the standard playbook so long as there’s still bozos willing to contribute free labor for their profit.”

TFTFY

That’s funny but I’m not gonna argue on it. It’s easier to give another example. If you want to get informed try finding laws that depend on firm size and be convinced if you do.

Wrong as in not sound. An argument can be valid assuming its assumptions are true. The argument is the model, which really is a set of arguments. Its assumptions which are taken axiomatically are as you say impossible, therefore they are not true (which I called wrong). So the argument is not sound. I’m not saying anything different than what you said really, just used informal language. ☺️

For a firm that already have their own core designs that simply use the ARM instruction set, it might be easier to adapt to RISC-V. For a firm that licenses ARM cores on the other hand…

Are you telling me that the axioms behind the simplistic model are wrong?? shocked-pikachu.jpg

Jesus

How do Signal stop forks from connecting to their servers?