home.social

#zimablade — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #zimablade, aggregated by home.social.

  1. Hat jemand Erfahrungen mit lokaler #LLM Inferenz auf Mini Systemen wie #raspberrypi oder #zimablade ?

    Ziel wäre ein kleines Modell wie Llama 7b in Verbindung mit einem #obsidianmd vault zu nutzen. Sozusagen ein:e mini Archivar:in um den Vault sinnvoll zu vernetzen. Das Ganze mit so wenig overhead wie möglich und CPU-basiert🤔

    #selfhost #homelab #ai #ki

  2. ZimaBlade 7700 DIY NAS Kit

    To me, a single board computer is defined not only by parts living on one circuit board, but with the added modifier that neither

    interfacinglinux.com/2025/12/0

    #10GIG #Jellyfin #NAS #OMV #REVIEW #ZimaBlade

  3. Noch einmal #Nextcloud

    Die #WebDAV implementierung auf Linux ist offenbar sehr mangelhaft.
    Eine per WebDAV über #GOA #GnomeOnlineAccounts gemountete Nextcloud hat massive Performance-Probleme. Videos lassen sich kaum bis nicht abspielen. Große Dateien öffnen... dauert. Drag&Drop von #Thunar oder #Nautilus in den #Firefox... brachte sogar meinen Firefox zum Absturz. Auf #Chromium ist es nicht besser.

    Auch manuell per davfs eine Nextcloud-Freigabe mounten macht es nicht besser.

    Ich schob bisher der Nextcloud die "Schuld" in die Schuhe. PHP und auf einem #Zimablade... ist halt nicht so performant...

    Aber per sshfs/sftp gemountet ist es doch rasend schnell... fast wie von lokal.

    Und dann entdeckte ich auf der Suche nach Lösungen, dass die Linux-Implementierung von WebDAV einfach grottig ist und ich nicht allein mit dem Problem mit Nextcloud bin.

    Ich will die Verzeichnisse nämlich nicht syncen - wie mit der Nextcloud-App - sondern ich will sie remote mounten.

    Also stieß ich bei der Recherche auf diesen tollen Artikel
    muetsch.io/fixing-slow-nextclo…
    Hier nutzt er die Fähigkeit von #rclone eine WebDAV Freigabe zu mounten.

    Das einzige was mir an der Lösung nicht gefällt ist die system-systemd Lösung.
    Also hab ich es auf eine Unit für den user-systemd umgebaut.
    Einrichten von rclone wie im Artikel, nur folgendes File erstellen:

    sudo editor /etc/systemd/user/rclone-nextcloud.service
    Und mit folgendem Inhalt befüllen

    [Unit]
    Description=RClone mount for Nextcloud
    Documentation=man:rclone(1)
    After=network-online.target
    Wants=network-online.target
    AssertPathIsDirectory=/home/%u/SHARED/nextcloud
    
    [Service]
    Type=simple
    ExecStart=/usr/bin/rclone mount nextcloud: %h/SHARED/nextcloud \
        --config=%h/.config/rclone/rclone.conf \
        --vfs-cache-mode full \
        --vfs-cache-max-age 1h \
        --vfs-cache-max-size 1G \
        --buffer-size 16M \
        --dir-cache-time 72h \
        --umask 002 \
        --uid %U \
        --gid %G \
        --daemon-timeout 30s
    ExecStop=/bin/fusermount -u %h/SHARED/nextcloud
    TimeoutStartSec=60
    TimeoutStopSec=20
    KillMode=process
    Restart=on-failure
    RestartSec=30
    StartLimitInterval=300
    StartLimitBurst=3
    
    [Install]
    WantedBy=default.target

    Speichern und als USER (!!!!) folgendes ausführen:
    systemctl --user daemon-reload && systemctl --user enable --now rclone-nextcloud.service

    Und dann in seinem Homeverzeichnis/SHARED/ nachsehen. Da sollte sich dann ein Ordner befinden, wo man den Inhalt seiner Nextcloud wiederfindet.

    Ich hab gerade 30 Videos mit in Summe ~50GB Daten auch hinkopiert (mit Drag & Drop in Nautilus) und die Daten waren ratzfatz drüben auf der Nextcloud!!
    Ja sogar totem spielt die Videos tadellos ab. Über GOA gemountet muss ich da erstmal 1-2 Minuten warten und dann zeigt er mir nur einzelne Frames statt eines Videos...

  4. Ich hab hier #NextcloudAIO auf einem #Zimablade laufen.
    Und ich hab eine spezielle Anforderung... selbstgewählt natürlich.

    Ich hab mir mal ein Script geschrieben, dass alle möglichen Dateinamen von Kameras frisst und ggfs. aus dem Dateinamen ein Erstellungsdatum auslesen kann, so keines in den #EXIF Daten des Bildes festgelegt ist.

    Am Ende der Behandlung mit dem Script steht dann ein Erstellungsdatum in den Exif-Daten und der Dateiname folgt der Konvention YYYYMMDD-HHMMSS.<dateierweiterung>

    Die Idee dahinter war, dass die Bilder auch bei einem Shell-Dateilisting in der richtigen zeitlichen Reihenfolge aufgelistet werden, und dass auch Bilder/Videos in denen keine Metadaten zur Erstellung gespeichert sind, diese bekommen und in div. Zeitleisten in Nextcloud auch richtig geordnet aufscheinen.

    Sonst ist mir das nämlich zuviel Chaos.

    Gut. Das Script hab ich schon lange im Einsatz und funktionierte auf meiner alten Nextcloud (bare-metal) und auf einem NAS gut und machte, was es soll.

    Mit incron habe ich den Upload-Ordner (Bei der Nextcloud meistens SofortUpload benannt) überwacht und das Script sprang dann bei jedem neuen File dort an und verschob es umbenannt in ein Verzeichnis + Subdir nach YYYY/YYYY_MM

    Ab und zu einmal hängte sich incrond auf... war nicht schön, aber handlebar.

    Zweite Herausforderung bei der #Nextcloud:
    Wenn ich im Filesystem direkt herumpfusche, kriegt die Nextcloud das nicht mit. Die Files bleiben so lange unsichtbar, bis ich mit occ files:scan wieder alles neu einlese.
    Das dauert aber laaaaaaaange. Denn ich habe viiiiiiiele Files.

    Alternativ kann ich mit dem config-Parameter 'filesystem_check_changes' => 1, auch ein Verzeichnis beim öffnen von der Nextcloud indizieren lassen... nicht schön, denn das haut die ohnedies nicht überragende Performance der Nextcloud ziemlich zusammen. Und zwar immer. Egal ob nun files neu eingelesen werden müssen, oder nicht.

    Au0erdem hat incrond ein Problem. Dazu gibts schon länger einen Bugreport von mir, der aber schon über ein Jahr nicht behandelt wurde... wenn ich ein Verzeichnis lösche, haut es incrond auf und es stürzt ab. Außerdem ist die Performance beim rekursiven Überwachen schlecht... es stürzt manchmal aus unerfindlichen Gründen ab.

    Also bin ich auf inotifywait gekommen. Das scheint viel stabiler als incron zu sein (baut aber auf der selben Kernel-Schnittstelle auf).
    Jetzt hab ich mein Script so angepasst, dass ein Script den Upload-Ordner überwacht, und für jedes hochgeladene File einen batch-Job erstellt, damit das Bild dann mit meinem Script behandelt wird, wenn die Last am Serverchen niedrig ist... so bleibt die Nextcloud immer erreichbar, auch wenn ich viele Bilder gleichzeitig hochlade.
    Ein zweites Script überwacht dann das "files" Verzeichnis aller User auf Änderungen und schreibt den Dateinamen samt Pfad eines hinzugekommenen Files oder das Parent-Verzeichnis eines entfernten Files/Verzeichnisses in verschiedene Stapel-Files. Da diese Filenamen auch mehrfach vorkommen können, brauchts dann noch einen Cronjob:
    Diese list diese Stapelfiles aus, macht ein sort|uniq drauf und schreibt das Ergebnis in ein Tempfile und trunkated gleichzeitig das Stapelfile, welches damit wieder vom Script neu befüllt werden kann.
    Dann führt es mit docker exec im Nextcloud-Container der Nextcloud AIO ein occ files:scan bzw. occ groupfolders:scan mit einer --path= Angabe aus um wirklich nur die veränderten Verzeichnisse und Files einzulesen. Das geht VIEL schneller, als regelmäßig den gesamten Inhalt zu scannen. Und es haut mir die Performance am Frontend nicht zusammen, wenn ich mehrere Verzeichnisse nacheinander aufrufe.

    Klingt kompliziert?
    Ist es auch.
    Aber momentan scheint es zu funktionieren.

    #scripting #bash #docker

  5. Algu té o ha provat el mini-ordinador "Zimablade", el model amb 4 nuclis...

    Estic plantejant-me un d'aquests per a trastejar i fer cosetes a l'aula.

    #ZimaBoard #zimablade #linux #professor #miniordinadors #preguntes

  6. Algu té o ha provat el mini-ordinador "Zimablade", el model amb 4 nuclis...

    Estic plantejant-me un d'aquests per a trastejar i fer cosetes a l'aula.

    #ZimaBoard #zimablade #linux #professor #miniordinadors #preguntes

  7. Algu té o ha provat el mini-ordinador "Zimablade", el model amb 4 nuclis...

    Estic plantejant-me un d'aquests per a trastejar i fer cosetes a l'aula.

    #ZimaBoard #zimablade #linux #professor #miniordinadors #preguntes

  8. Algu té o ha provat el mini-ordinador "Zimablade", el model amb 4 nuclis...

    Estic plantejant-me un d'aquests per a trastejar i fer cosetes a l'aula.

    #ZimaBoard #zimablade #linux #professor #miniordinadors #preguntes

  9. CasaOS: персональное облако на домашнем сервере

    Представьте, что можно управлять всеми приложениями, трансляциями фильмов и музыки, бэкапами, дисковым хранилищем, устройствами умного дома — с домашнего сервера. Это есть личное или персональное облако, то есть аналог публичных облачных сервисов, но на своём сервере, дома или на VPS. Например, система CasaOS изначально создавалась для одноплатника ZimaBoard (на фото), который позиционируется как мини-NAS. Главная ценность — отшлифованный UI с системными гаджетами для домашнего сервера, отобранный список приложений в каталоге, полезных именно для личного облака, и установка всех программ в докер-контейнерах в один клик. Плюс минимальные системные требования, поддержка старых ПК и одноплатников, включая Intel NUC и Raspberry Pi.

    habr.com/ru/companies/ruvds/ar

    #ruvds_статьи #CasaOS #персональное_облако #личное_облако #ZimaBoard #ZimaOS #личный_сервер #одноплатники #умный_дом #mini_NAS #ZimaBlade #персональный_NAS #ZimaCube #самохостинг #домашний_сервер

  10. Oh my gosh, this ZimaBlade computer somehow manages to be even better in person than the pictures suggested. Look at how cute and cool this is! 😎

    The plan is to put OpenBSD on this and migrate my whole home setup over. The big draw (besides the price and appearance) is the "Apollo Lake" Celeron with a miserly 6 Watt TDP, just like the fanless PC it will be replacing!

    #ZimaBlade #IceWhale