IMO, yes. I think it would make people more, rather than less, inclined to comment on a cross-post made in a smaller communities, since then their comment would be more visible.

The main concern I can see being raised is potentially leading to brigading? I’m not sure if that’s much of an issue on Lemmy and I would assume being able to de-federate would mitigate that substantially.

I believe you just need to set the env var OLLAMA_HOST to 0.0.0.0:11434 and then restart Ollama.

What OS is your server running? Do you have an Android phone or an iPhone?

In either case all you likely need to do is expose the port and then access your server by IP on that port with an appropriate client.

In Ollama you can expose the port to your local network by changing the bind address from 127.0.0.1 to 0.0.0.0

Regarding clients: on iOS you can use Enchanted or Apollo to connect to Ollama.

On Android there are likely comparable apps.

I hear more complaints about Windows from Windows users than from people who solely or primarily use other OSes. Unless you count “Okay… so why don’t you do something about it?” as a complaint, that is.

I think that makes you “the guy who really likes to talk about Linux.”

I’m a professional software engineer and I’ve been in the industry since before Kubernetes was first released, and I still found it overwhelming when I had to use it professionally.

I also can’t think of an instance when someone self-hosting would need it. Why did you end up looking into it?

I use Docker Compose for dozens of applications that range in complexity from “just run this service, expose it via my reverse proxy, and add my authentication middleware” to “in this stack, run this service with my custom configuration, a custom service I wrote myself or forked, and another service that I wrote a Dockerfile for; make this service accessible to this other service, but not to the reverse proxy; expose these endpoints to the auth middleware and for these endpoints, allow bypassing of the auth middleware if an API key is supplied.” And I could do much more complicated things with Docker if I needed to, so even for self-hosters with more complex use cases than mine, I question whether Kubernetes is the right fit.

You have it backwards.

• Day 2 Purchase
• Day 1 “Theft”

Chronologically, the “theft” comes first. And you can easily purchase something you previously stole.

Theft is in scare quotes because piracy isn’t theft and I’m assuming OP isn’t going to actually steal someone’s Steam Deck, Switch, or Switch game cartridge… but maybe I’m wrong.

(Also you could “steal” it after purchasing it by buying on one platform and pirating it on another, but that’s a separate matter.)

Just be aware that you need a 2230 M.2, not the much more common 2280 size.

I genuinely don’t understand why people here are taking it so hard that I wish the Immich devs were using semver.

Because you didn’t say that; you said “Breaking changes in a point release? Not cool” and later “I’m basing this off the guidelines at semver.org.”

I’m paraphrasing your comments from memory, to be clear, so apologies if I misquoted you.

It certainly felt to me like you were assuming that this project was using semver and was not following it well, not that you wouldn’t want to use a project that receives this many breaking changes / that doesn’t follow semver. Those complaints both make a lot more sense to me - and I’ve seen many people say similar things about Immich in the past. In fact, it’s a big part of why I haven’t migrated from Photoprism to Immich myself - in this regard they’re complete opposites.

I don’t think there’s any room to argue that announcing a 1.x with a change the developers say is a breaking change, which is what Immich have done, fits within the semver.org guidelines.

That wasn’t the argument.

Following semver is optional. If a project doesn’t explicitly state it is following semver, it shouldn’t be assumed that it is. With regard to Immich in particular, a cursory review of their documentation makes it clear that they are not following semver. Literally, go to https://immich.app/ and read the text at the very top of the page:

⚠️ The project is under very active development. Expect bugs and changes.

Go to the repo and you’ll see the README, which states at the very top:

• ⚠️ The project is under very activedevelopment.
• ⚠️ Expect bugs and breaking changes.

If you can read that, see that they’re on major version 1 with a minor version over 100, and you still think they’re using semver, then that’s on you.

The devs have stated they won’t be using semver until they consider Immich production ready, and that moving to a 1.x version from 0.x was a mistake made some time ago. If you want to think about it as though it is semver, consider the major version to still be 0. See https://github.com/immich-app/immich/discussions/5086#discussioncomment-7593227 for example.

As this project is clearly not following semver, the semver guidelines aren’t applicable and haven’t been violated.

I don’t think there’s any room to argue

Even if semver were applicable, in this case, I would still disagree. The text from semver.org states:

8. Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API.

It doesn’t state that any backward incompatible changes, period, require a major version increase, only changes to the public API. I would personally argue that the deployment configuration is part of the public API, but not all project owners agree with me. Even if they do agree, they might say that this was not a documented deployment configuration and thus not part of the public API, and that it therefore doesn’t necessitate an increase to the major version, but as they knew that people were using that configuration, anyway, they included a note about a potentially breaking change as a courtesy to those users.

Immich isn’t a library (the main use case for semver is dependencies that will be pulled into other projects) and as far as I know they don’t state that they use semver.

To run it with Nginx instead of Traefik, you need to figure out what port Nightscout’s web server runs on, then expose that port, e.g.,

services:
  nightscout:
    ports:
      - 3000:3000

You can remove the labels as those are used by Traefik, as well as the Traefik service itself.

Then just point Nginx to that port (e.g., 3000) on your local machine.

—-

Traefik has to know the port, too, but it will auto detect the port that a local Docker service is running on. It looks like your config is relying on that feature as I don’t see the label that explicitly specifies the port.

I thought Hue bulbs used Zigbee?

The up arrow moves through the letters, e.g., A->B->C. The down arrow moves to the next character in the sequence, e.g., C->CA->CAA. If you click past the correct letter, you’ll have to click all the way through again. And if you submit the wrong letter, you have to start all over (after it takes twenty seconds attempting to connect with the wrong password and then alerts you that it didn’t work, of course).

OP is also in the allegedly ultra rare camp of “successfully configured Jellyfin and lived to tell the tale.” Not what I’d expect of someone unable to configure Plex correctly. I’ve not set up a Plex server myself but my guess is it wasn’t clear that it was misconfigured - it did work previously, after all.

If they’re calling it remote streaming when you’re on the same (local) network, that’s not exactly intuitive. I’d say OP’s phrasing was fair.

Have you tried just setting the resolution to 1920x1080 or are you literally trying to run AAA games at 4K on a card that was targeting 1080p when it was released, 4 and a half years ago?

I think the best way to handle this would be to just encode everything and upload all files. If I wanted some amount of history, I’d use some file system with automatic snapshots, like ZFS.

If I wanted to do what you’ve outlined, I would probably use rclone with filtering for the extension types or something along those lines.

If I wanted to do this with Git specifically, though, this is what I would try first:

First, add lossless extensions (*.flac, *.wav) to my repo’s .gitignore

Second, schedule a job on my local machine that:

1. Watches for changes to the local file system (e.g., with inotifywait or fswatch)
2. For any new lossless files, if there isn’t already an accompanying lossy files (i.e., identified by being collocated, having the exact same filename, sans extension, with an accepted extension, e.g., .mp3, .ogg - possibly also with a confirmation that the codec is up to my standards with a call to ffprobe, avprobe, mediainfo, exiftool, or something similar), it encodes the file to your preferred lossy format.
3. Use git status --porcelain to if there have been any changes.
4. If so, run git add --all && git commit --message "Automatic commit" && git push
5. Optionally, automatically craft a better commit message by checking which files have been changed, generating text like Added album: "Satin Panthers - EP" by Hudson Mohawke or Removed album: "Brat" by Charli XCX; Added album "Brat and it's the same but there's three more songs so it's not" by Charli XCX

Third, schedule a job on my remote machine server that runs git pull at regular intervals.

One issue with this approach is that if you delete a file (as opposed to moving it), the space is not recovered on your local or your server. If space on your server is a concern, you could work around that by running something like the answer here (adjusting the depth to an appropriate amount for your use case):

git fetch --depth=1
git reflog expire --expire-unreachable=now --all
git gc --aggressive --prune=all

Another potential issue is that what I described above involves having an intermediary git to push to and pull from, e.g., running on a hosted Git forge, like GitHub, Codeberg, etc… This could result in getting copyright complaints or something along those lines, though.

Alternatively, you could use your server as the git server (or check out forgejo if you want a Git forge as well), but then you can’t use the above trick to prune file history and save space from deleted files (on the server, at least - you could on your local, I think). If you then check out your working copy in a way such that Git can use hard links, you should at least be able to avoid needing to store two copies on your server.

The other thing to check out, if you take this approach, is git lfs. EDIT: Actually, I take that back - you probably don’t want to use Git LFS.

You can run a NAS with any Linux distro - your limiting factor is having enough drive storage. You might want to consider something that’s great at using virtual machines (e.g., Proxmox) if you don’t like Docker, but I have almost everything I want running in Docker and haven’t needed to spin up a single virtual machine.

Copied from the post:

You may have seen reports of leaks of older text messages that had previously been sent to Steam customers. We have examined the leak sample and have determined this was NOT a breach of Steam systems.​

​

We’re still digging into the source of the leak, which is compounded by the fact that any SMS messages are unencrypted in transit, and routed through multiple providers on the way to your phone.​

​

The leak consisted of older text messages that included one-time codes that were only valid for 15-minute time frames and the phone numbers they were sent to. The leaked data did not associate the phone numbers with a Steam account, password information, payment information or other personal data. Old text messages cannot be used to breach the security of your Steam account, and whenever a code is used to change your Steam email or password using SMS, you will receive a confirmation via email and/or Steam secure messages.​

​

You do not need to change your passwords or phone numbers as a result of this event. It is a good reminder to treat any account security messages that you have not explicitly requested as suspicious. We recommend regularly checking your Steam account security at any time at ​

https://store.steampowered.com/account/authorizeddevices​

​

We also recommend setting up the Steam Mobile Authenticator if you haven’t already, as it gives us the best way to send secure messages about your account and your account’s safety.