[-] archomrade@midwest.social 3 points 9 hours ago

Biden winning this campaign against Trump in bis current condition is looking about as likely as Biden choosing to step down and Stewert stepping into electoral politics

[-] archomrade@midwest.social 6 points 9 hours ago

You think the people panicking about Biden's declining acuity and pushing for a swap of candidates have forgotten about Trump?

I think the people urging we ignore his declining performance in service of keeping him on the top of the ticket are doing the most harm to the democratic campaign given the threat posed by trump. Democrats can't afford a nominee that might fall asleep in the middle of cross-examination. If the one thing dems need is someone who can argue the case against Trump, the bare minimum qualification is the ability to stay on message, and Biden simply doesn't have it anymore. He can barely finish a complete thought anymore.

[-] archomrade@midwest.social 0 points 12 hours ago

idk what to tell you, the article you linked shows alt candidates having similar support as biden in head-to-heads. I'm not sure in what world that means Biden has majority support. They can't all have near-majority support

if 75% of the democratic electorate would prefer a different candidate, then in a ranked-choice election 75% of democratic voters would likely be putting him as second or third choice, not their first.

[-] archomrade@midwest.social 1 points 19 hours ago

Lmao, those polls are asking how people would vote in hypothetical head-to-heads - as in:

the current situation is one brought on by an imperfect implementation of democracy.

But I guess since this says each hypothetical polled resulted in near the same chances, that means all of the alternatives have 'near-majority support', right?

[-] archomrade@midwest.social 5 points 1 day ago

On what basis are you making the claim that Biden has near-majority support here? Because if it's simply the fact he's the candidate that was produced by our shit system, it seems like you're just begging the question.

[-] archomrade@midwest.social 6 points 1 day ago

This is the third or fourth time I've seen you hide behind "the opinions of the electorate" as a defense of status-quo positions, except this time it's pretty clearly not the opinion of the electorate that Biden is the preferred candidate to go up against trump.

[-] archomrade@midwest.social 4 points 1 day ago

Despite insisting otherwise, PugJesus is a through-and-through centrist who prefers the convenience FPTP offers to those who don't want things to fundamentally change.

It is the only reason he would be insisting on the head-to-head interpretation of "near-majority support" and only agrees to popular progressive positions when there is a systemic hurdle that prevents that position from coming to fruition.

[-] archomrade@midwest.social 3 points 1 day ago

75% of democratic voters would prefer a different candidate to Biden, I wouldn't consider that a near-majority support.

[-] archomrade@midwest.social 2 points 1 day ago

Anyone still planning on voting Biden at this point can only justify it on the basis he's not Trump, and wouldn't decide not to vote without Biden on the ticket

A quality he shares with every other American with the exception of Trump himself.

The democrats only stand to gain votes by swapping him out. 75% of democrats would prefer a different candidate.

5
[-] archomrade@midwest.social 3 points 4 days ago

Trump doesn't have to be cogent to win his supporters over, he just has to be violent.

Just like how Biden doesn't have to be lucid to keep the loyalty of his supporters, he just has to not be Trump.

6
7
152

I can finally start the healing

-38
33
submitted 3 weeks ago* (last edited 3 weeks ago) by archomrade@midwest.social to c/politicalmemes@lemmy.world

Edited for legibility

174
No war but class war (midwest.social)
-27
4
Oh fuck, it's a tankie! (midwest.social)
142
163
Just a reminder (midwest.social)
10
submitted 1 month ago* (last edited 1 month ago) by archomrade@midwest.social to c/selfhosted@lemmy.world

edit: a working solution is proposed by @Lifebandit666@feddit.uk below:

So you’re trying to get 2 instances of qbt behind the same Gluetun vpn container?

I don’t use Qbt but I certainly have done in the past. Am I correct in remembering that in the gui you can change the port?

If so, maybe what you could do is set up your stack with 1 instance in, go into the GUI and change the port on the service to 8000 or 8081 or whatever.

Map that port in your Gluetun config and leave the default port open for QBT, and add a second instance to the stack with a different name and addresses for the config files.

Restart the stack and have 2 instances.


Has anyone run into issues with docker port collisions when trying to run images behind a bridge network (i think I got those terms right?)?

I'm trying to run the arr stack behind a VPN container (gluetun for those familiar), and I would really like to duplicate a container image within the stack (e.g. a separate download client for different types of downloads). As soon as I set the network_mode to 'service' or 'container', i lose the ability to set the public/internal port of the service, which means any image that doesn't allow setting ports from an environment variable is stuck with whatever the default port is within the application.

Here's an example .yml:

services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=[redacted]
      - WIREGUARD_PRIVATE_KEY=[redacted]
      - WIREGUARD_ADDRESSES=[redacted]
      - SERVER_COUNTRIES=[redacted]
    ports:
      - "8080:8080" #qbittorrent
      - "6881:6881"
      - "6881:6881/udp"
      - "9696:9696" # Prowlarr
      - "7878:7878" # Radar
      - "8686:8686" # Lidarr
      - "8989:8989" # Sonarr
    restart: always

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: "qbittorrent"
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=CST/CDT
      - WEBUI_PORT=8080
    volumes:
      - /docker/appdata/qbittorrent:/config
      - /media/nas_share/data:/data)

Declaring ports in the qbittorrent service raises an error saying you cannot set ports when using the service network mode. Linuxserver.io has a WEBUI_PORT environment variable, but using it without also setting the service ports breaks it (their documentation says this is due to CSRF issues and port mapping, but then why even include it as a variable?)

The only workaround i can think of is doing a local build of the image that needs duplication to allow ports to be configured from the e variables, OR run duplicate gluetun containers for each client which seems dumb and not at all worthwhile.

Has anyone dealt with this before?

[-] archomrade@midwest.social 165 points 1 year ago

A point of caution:

A large company absolutely could come in and absorb the majority of lemmy traffic and build proprietary code and features on top of the main protocol, eventually making the open source protocol obsolete and supplanting it as a paid/closed-source service. It has been done repeatedly by tech companies, and it is the main reason many people distrust Meta's interest in joining the fediverse.

For all the reasons you just mentioned, we should fight tooth and nail against that from happening, but we should at least be aware of the threat.

view more: next ›

archomrade

joined 1 year ago