I switched from ollama to llama.cpp and love it. For such an article, it frustrates me that they don't include the common and popular option in the comparison.
I haven't had to adjust or look at my invidious instance configs in a long time, but I do remember that in their docker instructions and I think I configured my container to restart hourly (or maybe I made it every other hour? Daily?). I've had no problems with my invidious instance in a long time, but that may have nothing to do with frequent restarts.
Well written and very thought provoking. I've thought about positive and negative freedom (and other definitions) a lot, but still this article gave me new perspective.
I think Forgejo is in the process of federating via ActivityPub. Codeberg uses Forgejo, but Forgejo is self hostable. I'm looking forward to see how a federated git forge works!
The Hated One has a video explaining his take on what Mullvad has done, and he gives 2 good alternatives to Mullvad. He also has other videos comparing VPN services in terms of privacy. He's very thorough.
I have aPBS server and my friend in a different geographic region has one. I backup to mine and he backs up to his. Mine syncs my backups to a data so l store in his, and his summer backups to a data store in mine. These are our offsite backups.
To be clear, we're syncing our proxmox VM backups. But Proxmox Backup Server also has a client app, so I also back up my workstation to my PBS and it also syncs to the remote PBS.
It's important to me to use devices and services that are local only, but I could only find such robot mowers that are beyond my skillset to build. I have no interest in building and 3d printing and flashing firmware, etc. I just want to buy a device and use it, without my privacy being sold. I'm willing to pay, but I guess there's not enough market for anyone to build/sell that.
Same with vacuums, by the way. I have a dreametech model that's supported by Valetudo, but the instructions to flash it sounded difficult and risky enough that I just use it as is, with my home map (and whatever other data it gleans) going through Dreametech's servers and being sold to whomever.
Sad.
Only minor performance degradation with compression, but does the compression also mean the MOE model can run on a GPU with less VRAM? E.g., I don't think I can run GLM 5.2 on my W7900 (48G) even though the experts only take 40G, but would this compression allow it to run?
I don't understand the joke.
Yeah, my thinking was definitely biased to my environment. I selfhost llama.cpp so even if Hivekeep doesn't require significant resources, whatever LLMs it runs will use my hardware.
agents are activated serially per message, not all firing at once, and the persistent memory is exactly what keeps each context small
It sounds like I need to try it!
I laughed out loud (well giggled out loud) at this one, twice.
Can someone please help me understand where Immich stores assets? I've read the documentation regarding external libraries and storage templates, but am still confused.
I may have lost a significant part of my library: a large number of assets display a blurry thumbnail and show an error message when I try to view them (see screenshots). That seems to indicate that the images used to be there but now only a database reference still exists. I ran find /usr/src/app/uploads -iname "*image_0010*" in the Docker container (an example of my issue is an image file called "IMG_0010.jpg") and no such file exists.
Here's how I mapped the volume in docker-compose.yaml - I think it's correct, but maybe that trailing "/upload" is a problem?
volumes:
- uploads:/usr/src/app/upload
Here's the directory structure inside the Immich Docker container:
|-- cli
|-- server
`-- upload
|-- backups
|-- encoded-video
| `-- 72be7b0f-b367-42d5-ae86-5d5feaa481ad
|-- library
| `-- 72be7b0f-b367-42d5-ae86-5d5feaa481ad
|-- profile
|-- thumbs
| `-- 72be7b0f-b367-42d5-ae86-5d5feaa481ad
`-- upload
`-- 72be7b0f-b367-42d5-ae86-5d5feaa481ad
Inside upload there's a library dir and a second upload dir. What's the difference? They are vastly different sizes so I'm guessing that upload/library/ is the main library and upload/upload/ is for uploads from the app:
root@433fdc9d55c6:/usr/src/app# du -s -h upload/library/ upload/upload/
246G upload/library/
18G upload/upload/
So my questions so far are:
- Is there a problem with how I mapped my Docker volume (e.g., am I causing recursion issues?)
- What's the difference between
upload/library/andupload/upload/?
I also have a more general question about asset location: if I upload images from the Immich app, I presume they're stored somewhere in the upload dir - if so, does that mean that if I wanted all my photos to be in an external library, I would have to refrain from using the Immich app's upload feature (and roll my own method of uploading images to my external library dir)?
Thanks in advance for any help or explanations you can offer!
The Purina for Professionals website's "cookie management" (to opt out of cookies) is heavily dark-patterned. Not only does the popup at the bottom of the page not have cookie management (it has a link that takes you to a page that has a link to take you to cookie management), but the wording is intentionally counter-intuitive to opt out:
The option is called "Do Not Sell or Share My Personal Information", which suggests that by selecting the option, you want them to not sell or share your information. But in parentheses it adds "slide left to opt out of sale/share", which suggests that disabling the option means for them to not sell or share your information.
Which of the 3 buttons does which of the 4 commands listed next to them?
Of the 3 buttons in the red-outlined-box on this Brother printer control panel, which does what function? Grrr!
view more:
next ›