Nice, congrats on getting it to work! :) Native Debian packages are also nice. It can just get difficult if you want the latest stuff.
stuner
I used the docker compose template from https://hub.docker.com/_/drupal and mostly changed the image:
Compose file
# Drupal with PostgreSQL
#
# Access via "http://localhost:8080"
# (or "http://$(docker-machine ip):8080" if using docker-machine)
#
# During initial Drupal setup,
# Database type: PostgreSQL
# Database name: postgres
# Database username: postgres
# Database password: example
# ADVANCED OPTIONS; Database host: postgres
version: '3.1'
services:
drupal:
# image: drupal:10-apache
# image: drupal:10.3.7-apache-bookworm
# image: drupal:10.3.6-apache-bookworm
image: drupal:11.0.5-apache-bookworm
# image: drupal:10-php8.3-fpm-alpine
ports:
- 8080:80
volumes:
- /var/www/html/modules
- /var/www/html/profiles
- /var/www/html/themes
# this takes advantage of the feature in Docker that a new anonymous
# volume (which is what we're creating here) will be initialized with the
# existing content of the image at the same location
- /var/www/html/sites
restart: always
environment:
PHP_MEMORY_LIMIT: "1024M"
postgres:
image: postgres:16
environment:
POSTGRES_PASSWORD: example
restart: always
The details for the v11 image are here: https://hub.docker.com/layers/library/drupal/11.0.5-apache-bookworm/images/sha256-0e41e0173b4b5d470d30e2486016e1355608ab40651549e3e146a7334f9c8f77?context=explore
Yes, the docker images don't use the sury.org php packages (they use the php docker image).
"11.0.5-apache-bookworm" also seems to work, maybe you can try that version?
I wanted to recommend using a Docker container but I ran into the same issue with the default config for "drupal:10-apache" (aka "drupal:10.3.7-apache-bookworm"). Opening "node/add/article" results in the OOM error. Downgrading to "drupal:10.3.6-apache-bookworm" resolved the issue. Looks like a Drupal regression to me. Maybe you can also try an older version of Drupal 11?
If you don't want to reinstall the OS, you can probably use Clonezilla: https://clonezilla.org/show-live-doc-content.php?topic=clonezilla-live/doc/03_Disk_to_disk_clone
Maybe you need to update the drive ids for your bootloader (grub) afterwards, not sure about that.
Edit: Maybe the advanced "-g auto" option does that for you.
IMHO the OSI is right, the designation "open source" should be reserved for those models that are actually open source (including training data). And apparently there are a few models that actually meet this criterion: "Though none are confirmed, the handful of models that Bdeir told MIT Technology Review are expected to land on the list are relatively small names, including Pythia by Eleuther, OLMo by Ai2, and models by the open-source collective LLM360." (https://www.technologyreview.com/2024/08/22/1097224/we-finally-have-a-definition-for-open-source-ai/)
Perhaps it would also be useful to have a name for models that release their weights under an OSI license, maybe "open weight"? However, this model would not even meet that... (same for Llama).
i.e. it's most definitely not open source.
It seems that 18.04 was the last release for 32-bit x86 (i386): https://askubuntu.com/questions/1376090/latest-version-of-ubuntu-for-i386-architecture-32-bit
But you could just go for Debian which still supports it.
It's an Apple Silicon Mac Mini. Do you have a particular reason to think the new one is less efficient?
I do think it can achieve that while waiting for network packets (see e.g. https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested).
But in terms of money savings it would rarely make sense, as you need to make it back during the time you run the system. If we assume 6 years lifetime then it would only make sense to pay $120 more. But yes, I'd also go for a system that runs regular Linux :)
It sounds like the criterion is "is newer microcode available". So it doesn't look like a marketing strategy to sell new CPUs.