Das KDE-Team arbeitet an einer eigenen Distribution namens KDE Linux – parallel zu dem bereits bestehenden KDE Neon.

Das KDE-Team arbeitet an einer eigenen Distribution namens KDE Linux – parallel zu dem bereits bestehenden KDE Neon.

Der Enterprise Policy Generator richtet sich an Administratoren von Unternehmen und Organisationen, welche Firefox konfigurieren wollen. Mit dem Enterprise Policy Generator 7.0 ist nun ein Update erschienen.

Download Enterprise Policy Generator für Firefox

Die Enterprise Policy Engine erlaubt es Administratoren, Firefox über eine Konfigurationsdatei zu konfigurieren. Der Vorteil dieser Konfigurationsdatei gegenüber Group Policy Objects (GPO) ist, dass diese Methode nicht nur auf Windows, sondern plattformübergreifend auf Windows, Apple macOS sowie Linux funktioniert.

Der Enterprise Policy Generator hilft bei der Zusammenstellung der sogenannten Enterprise Policies, sodass kein tiefergehendes Studium der Dokumentation und aller möglichen Optionen notwendig ist und sich Administratoren die gewünschten Enterprise Policies einfach zusammenklicken können.

Neuerungen vom Enterprise Policy Generator 7.0

Allgemeine Verbesserungen

Der Enterprise Policy Generator erfordert jetzt Firefox 128 oder höher. Die mindestens erforderliche Firefox-Version wird außerdem nicht länger für Richtlinien angezeigt, welche vor Firefox 128 implementiert worden sind.

Ein Fehler wurde behoben, der dazu führte, dass der Wert für die OverrideFirstRunPage-Richtlinie nach dem Exportieren und erneuten Importieren der Konfiguration als „undefined“ angezeigt wurde.

Unter der Haube wurde eine Verschachtelung von CSS eingeführt, um die Wartbarkeit des Designs zu verbessern. Außerdem wurde die JavaScript-Methode zum Ausblenden der leeren Kategorien nach dem Filtern durch eine CSS-Lösung ersetzt.

Erweiterte Unterstützung von Unternehmensrichtlinien

Die Preferences-Richtlinie wurde um Unterstützung für die Einstellungen mathml.disabled, privacy.baselineFingerprintingProtection, privacy.fingerprintingProtection, security.csp.reporting.enabled, security.pki.certificate_transparency.disable_for_hosts, security.pki.certificate_transparency.disable_for_spki_hashes, security.pki.certificate_transparency.mode, svg.context-properties.content.enabled, svg.disabled, webgl.disabled, webgl.force-enabled und xpinstall.enabled erweitert, die Unterstützung für die obsolete Einstellung security.osclientcerts.assume_rsa_pss_support wurde entfernt.

Die DisableBuiltinPDFViewer-Richtlinie wurde mit einer neuen Beschreibung wieder eingeführt, da das Verhalten in Firefox 140 geändert worden ist. Die Unterstützung für diese Richtlinie wurde ursprünglich in Enterprise Policy Generator 6.0 entfernt, da die PDFjs-Richtlinie eingeführt wurde, um das gleiche Verhalten zu erzielen. Die Richtlinien DisableBuiltinPDFViewer und PDFjs schließen sich gegenseitig aus.

Einige Beschreibungen für die EnableTrackingProtection-Richtlinie zur Konfiguration des Schutzes vor Aktivitätenverfolgung wurden aktualisiert. Außerdem wurde die Richtlinie um Unterstützung für die Optionen SuspectedFingerprinting, BaselineExceptions, ConvenienceExceptions sowie Category erweitert.

Die Permissions-Richtlinie wurde um die Option ScreenShare erweitert, um die Konfiguration von Anfragen zur Bildschirmfreigabe zu unterstützen.

Die SanitizeOnShutdown-Richtlinie wurde aktualisiert, indem die obsoleten Optionen Downloads und OfflineApps entfernt worden sind, ein Kompatibilitätshinweis für die Option FormData hinzugefügt worden ist und Reihenfolge sowie Beschreibungen der Optionen verbessert worden sind.

Die Option temporarily_allow_weak_signatures der ExtensionSettings-Richtlinie war bisher nur als globale Option verfügbar, nicht jedoch für einzelne Erweiterungen.

Die DisableFirefoxAccounts-Richtlinie wurde durch die Richtlinie DisableAccounts ersetzt und bestehende Konfigurationen wurden migriert.

Die DisablePrivateBrowsing-Richtlinie wurde entfernt und in bestehenden Konfigurationen zur PrivateBrowsingModeAvailability-Richtlinie migriert.

Entwicklung unterstützen

Wer die Entwicklung des Add-ons unterstützen möchte, kann dies tun, indem er der Welt vom Enterprise Policy Generator erzählt und die Erweiterung auf addons.mozilla.org bewertet. Auch würde ich mich sehr über eine kleine Spende freuen, welche es mir ermöglicht, weitere Zeit in die Entwicklung des Add-on zu investieren, um zusätzliche Features zu implementieren.

Der Beitrag Enterprise Policy Generator 7.0 für Firefox veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Das Uutils-Projekt re-implementiert die GNU Coreutils in Rust.

Das Uutils-Projekt re-implementiert die GNU Coreutils in Rust.

Die Aufgabenstellung ist sehr speziell, und dementsprechend wird dieser Beitrag vermutlich nur wenig Leute interessieren. Aber egal: Ich habe mich drei Tage damit geärgert, vielleicht profitieren ein paar Leser von meinen Erfahrungen …

Die Zielsetzung ist bereits in der Überschrift beschrieben. Ich besitze einen Mini-PC mit AMD 8745H-CPU und 32 GiB RAM. Die CPU enthält auch eine integrierte GPU (Radeon 780M). Auf diesem Rechner wollte ich das momentan sehr beliebte Sprachmodell gpt-oss-20b ausführen. Dieses Sprachmodell ist ca. 11 GiB groß, umfasst 20 Milliarden Parameter in einer etwas exotischen Quantifizierung. (MXFP4 wurde erst 2024 standardisiert und bildet jeden Parameter mit nur 4 Bit ab. Die Besonderheit besteht darin, dass für unterschiedliche Teile des Modells unterschiedliche Skalierungsfaktoren verwendet werden, so dass die Parameter trotz der wenigen möglichen Werte einigermaßen exakt abgebildet werden können.)

Das Sprachmodell wird von der Firma OpenAI kostenlos angeboten. Die Firma gibt an, dass die 20b-Variante ähnlich gute Ergebnisse wie das bis 2024 eingesetzt kommerzielle Modell o3-mini liefert, und auch KI-Experte Simon Willison singt wahre Lobeshymnen auf das Modell.

PS: Ich habe alle Tests unter Fedora 42 durchgeführt.

Warum nicht Ollama?

Für alle, die nicht ganz tief in die lokale Ausführung von Sprachmodellen eintauchen wollen, ist Ollama zumeist die erste Wahl. Egal, ob unter Windows, Linux oder macOS, viele gängige Sprachmodelle können damit unkompliziert ausgeführt werden, in der Regel mit GPU-Unterstützung (macOS, Windows/Linux mit NVIDIA-GPU bzw. mit ausgewählten AMD-GPUs).

Bei meiner Hardware — und ganz allgemein bei Rechnern mit einer AMD-iGPU — ist Ollama aktuell aber NICHT die erste Wahl:

ROCm: Ollama setzt bei NVIDIA-GPUs auf das Framework CUDA (gut), bei AMD-GPUs auf das Framework ROCm (schlecht). Dieses Framework reicht alleine vermutlich als Grund, warum AMD so chancenlos gegen NVIDIA ist. Im konkreten Fall besteht das Problem darin, dass die iGPU 780M (interner ID gfx1103) offiziell nicht unterstützt wird. Die Empfehlung lautet, ROCm per Umgebungsvariable zu überzeugen, dass die eigene GPU kompatibel zu einem anderen Modell ist (HSA_OVERRIDE_GFX_VERSION=11.0.2). Tatsächlich können Sprachmodelle dann ausgeführt werden, aber bei jeder Instabilität (derer es VIELE gibt), stellt sich die Frage, ob nicht genau dieser Hack der Anfang aller Probleme ist.

Speicherverwaltung: Auch mit diesem Hack scheitert Ollama plus ROCm-Framework an der Speicherverwaltung. Bei AMD-iGPUs gibt es zwei Speicherbereiche: fix per BIOS allozierten VRAM sowie dynamisch zwischen CPU + GPU geteiltem GTT-Speicher. (Physikalisch ist der Speicher immer im RAM, den sich CPU und GPU teilen. Es geht hier ausschließlich um die Speicherverwaltung durch den Kernel + Grafiktreiber.)

Ollama alloziert zwar den GTT-Speicher, aber maximal so viel, wie VRAM zur Verfügung steht. Diese (Un)Logik ist am besten anhand von zwei Beispielen zu verstehen. Auf meinem Testrechner habe ich 32 GiB RAM. Standardmäßig reserviert das BIOS 2 GiB VRAM. Der Kernel markiert dann 14 GiB als GTT. (Das kann bei Bedarf mit den Kerneloptionen amdttm.pages_limit und amdttm.page_pool_size verändert werden.) Obwohl mehr als genug Speicher zur Verfügung steht, sieht Ollama eine Grenze von 2 GiB und kann nur winzige LLMs per GPU ausführen.

Nun habe ich im BIOS das VRAM auf 16 GiB erhöht. Ollama verwendet nun 16 GiB als Grenze (gut), nutzt aber nicht das VRAM, sondern den GTT-Speicher (schlecht). Wenn ich nun ein 8 GiB großes LLM mit Ollama ausführen, dann bleiben fast 16 GiB VRAM ungenutzt! Ollama verwendet 8 GiB GTT-Speicher, und für Ihr Linux-System bleiben gerade einmal 8 GiB RAM übrig. Es ist zum aus der Haut fahren! Im Internet gibt es diverse Fehlerberichte zu diesem Problem und sogar einen schon recht alten Pull-Request mit einem Vorschlag zur Behebung des Problems. Eine Lösung ist aber nicht Sicht.

Ich habe mich mehrere Tage mit Ollama geärgert. Schade um die Zeit. (Laut Internet-Berichten gelten die hier beschriebenen Probleme auch für die gehypte Strix-Halo-CPU.)

Next Stop: llama.cpp

Etwas Internet-Recherche liefert den Tipp, anstelle von Ollama das zugrundeliegende Framework llama.cpp eben direkt zu verwenden. Ollama greift zwar selbst auf llama.cpp zurück, aber die direkte Verwendung von llama.cpp bietet andere GPU-Optionen. Dieser Low-Level-Ansatz ist vor allem bei der Modellauswahl etwas umständlicher. Zwei Vorteile können den Zusatzaufwand aber rechtfertigen:

• Die neuste Version von llama.cpp unterstützt oft ganz neue Modelle, mit denen Ollama noch nicht zurechtkommt.

• llama.cpp kann die GPU auf vielfältigere Weise nutzen als Ollama. Je nach Hardware und Treiber kann so eventuell eine höhere Geschwindigkeit erzielt bzw. der GPU-Speicher besser genutzt werden, um größere Modelle auszuführen.

Die GitHub-Projektseite beschreibt mehrere Installationsvarianten: Sie können llama.cpp selbst kompilieren, den Paketmanager nix verwenden, als Docker-Container ausführen oder fertige Binärpakete herunterladen (https://github.com/ggml-org/llama.cpp/releases). Ich habe den einfachsten Weg beschritten und mich für die letzte Option entschieden. Der Linux-Download enthält genau die llama.cpp-Variante, die für mich am interessantesten war — jene mit Vulkan-Unterstützung. (Vulkan ist eine 3D-Grafikbibliothek, die von den meisten GPU-Treibern unter Linux durch das Mesa-Projekt gut unterstützt wird.) Die Linux-Version von llama.cpp wird anscheinend unter Ubuntu kompiliert und getestet, dementsprechend heißt der Download-Name llama-<version>-bin-ubuntu-vulkan-x86.zip. Trotz dieser Ubuntu-Affinität ließen sich die Dateien bei meinen Tests aber problemlos unter Fedora 42 verwenden.

Nach dem Download packen Sie die ZIP-Datei aus. Die resultierenden Dateien landen im Unterverzeichnis build/bin. Es bleibt Ihnen überlassen, ob Sie die diversen llama-xxx-Kommandos direkt in diesem Verzeichnis ausführen, das Verzeichnis zu PATH hinzufügen oder seinen Inhalt in ein anderes Verzeichnis kopieren (z.B. nach /usr/local/bin).

cd Downloads
unzip llama-b6409-bin-ubuntu-vulkan-x64.zip
cd build/bin
./llama-cli --version

  loaded RPC backend from ./build/bin/libggml-rpc.so
  ggml_vulkan: Found 1 Vulkan devices:
  ggml_vulkan: 0 = AMD Radeon 780M Graphics (RADV PHOENIX) (radv) ...
  loaded Vulkan backend from ./build/bin/libggml-vulkan.so
  loaded CPU backend from ./build/bin/libggml-cpu-icelake.so
  version: 6409 (d413dca0)
  built with cc (Ubuntu 11.4.0-1ubuntu1~22.04.2) for x86_64-linux-gnu

Für die GPU-Unterstützung ist entscheidend, dass auf Ihrem Rechner die Bibliotheken für die 3D-Bibliothek Vulkan installiert sind. Davon überzeugen Sie sich am einfachsten mit vulkaninfo aus dem Paket vulkan-tools. Das Kommando liefert fast 4000 Zeilen Detailinformationen. Mit einem Blick in die ersten Zeilen stellen Sie fest, ob Ihre GPU unterstützt wird.

vulkaninfo | less

  Vulkan Instance Version: 1.4.313
  Instance Extensions: count = 24
    VK_EXT_acquire_drm_display  : extension revision 1
    VK_EXT_acquire_xlib_display : extension revision 1
    ...
  Layers: count = 1
     VK_LAYER_MESA_device_select
     Devices: count = 2
       GPU id = 0 (AMD Radeon 780M Graphics (RADV PHOENIX))
       GPU id = 1 (llvmpipe (LLVM 20.1.8, 256 bits))
  ...

Erste Tests

Um llama.cpp auszuprobieren, brauchen Sie ein Modell. Bereits für Ollama heruntergeladene Modelle sind leider ungeeignet. llama.cpp erwartet Modelle als GGUF-Dateien (GPT-Generated Unified Format). Um die Ergebnisse mit anderen Tools leicht vergleichen zu können, verwende ich als ersten Testkandidat immer Llama 3. Eine llama-taugliche GGUF-Variante von Llama 3.1 mit 8 Milliarden Parametern finden Sie auf der HuggingFace-Website unter dem Namen bartowski/Meta-Llama-3.1-8B-Instruct-GGUF:Q4_K_M.

Das folgende Kommando lädt das Modell von HuggingFace herunter (Option -hf), speichert es im Verzeichnis .cache/llama.cpp, lädt es, führt den als Parameter -p angegebenen Prompt aus und beendet die Ausführung dann. In diesem und allen weiteren Beispielen gehe ich davon aus, dass sich die llama-Kommandos in einem PATH-Verzeichnis befinden. Alle Ausgaben sind aus Platzgründen stark gekürzt.

llama-cli -hf bartowski/Meta-Llama-3.1-8B-Instruct-GGUF:Q4_K_M \
  -p 'bash/Linux: explain the usage of rsync over ssh'

  ... (diverse Debugging-Ausgaben)
  Running in interactive mode.
  - Press Ctrl+C to interject at any time.
  - Press Return to return control to the AI.
  - To return control without starting a new line, end your input with '/'.
  - If you want to submit another line, end your input with '\'.
  - Not using system message. To change it, set a different value via -sys PROMPT

> bash/Linux: explain the usage of rsync over ssh

  rsync is a powerful command-line utility that enables you to 
  synchronize files and directories between two locations. Here's 
  a breakdown of how to use rsync over ssh: ...

> <Strg>+<D>

         load time =  2231.02 ms
  prompt eval time =   922.83 ms /  43 tokens (46.60 tokens per second)
         eval time = 31458.46 ms / 525 runs   (16.69 tokens per second)

Sie können llama-cli mit diversen Optionen beeinflussen, z.B. um verschiedene Rechenparameter einzustellen, die Länge der Antwort zu limitieren, den Systemprompt zu verändern usw. Eine Referenz gibt llama-cli --help. Deutlich lesefreundlicher ist die folgende Seite:

https://github.com/ggml-org/llama.cpp/discussions/15709

Mit llama-bench können Sie diverse Benchmark-Tests durchführen. Im einfachsten Fall übergeben Sie nur das Modell in der HuggingFace-Notation — dann ermittelt das Kommando die Token-Geschwindigkeit für das Einlesen des Prompts (Prompt Processing = pp) und die Generierung der Antwort (Token Generation = tg). Allerdings kennt llama-bench die Option -hf nicht; vielmehr müssen Sie mit -m den Pfad zur Modelldatei übergeben:

llama-bench -m ~/.cache/llama.cpp/bartowski_Meta-Llama-3.1-8B-Instruct-GGUF_Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf

  model                         size     test   token/s (Tabelle gekürzt ...)
  -----------------------  ---------  -------  --------
  llama 8B Q4_K - Medium    4.58 GiB    pp512    204.03
  llama 8B Q4_K - Medium    4.58 GiB    tg128     17.04

Auf meinem Rechner erreicht llama.cpp mit Vulkan nahezu eine identische Token-Rate wie Ollama mit ROCm (aber ohne die vielen Nachteile dieser AMD-Bibliothek).

AMD-Optimierung

Bei meinen Tests auf dem schon erwähnten Mini-PC mit AMD 8745H-CPU mit der iGPU 780M und 32 GiB RAM funktionierte llama.cpp mit Vulkan viel unkomplizierter als Ollama mit ROCm. Ich habe die VRAM-Zuordnung der GPU wieder zurück auf den Defaultwert von 2 GiB gestellt. Per Default steht llama.cpp auf meinem Rechner dann ca. der halbe Arbeitsspeicher (2 GiB VRAM plus ca. 14 GiB GTT) zur Verfügung. Vulkan kann diesen Speicher ohne merkwürdige Hacks mit Umgebungsvariablen korrekt allozieren. Das reicht ohne jedes Tuning zur Ausführung des Modells gpt-20b aus (siehe den folgenden Abschnitt). So soll es sein!

Wenn Sie noch mehr Speicher für die LLM-Ausführung reservieren wollen, müssen Sie die Kerneloptionen pages_limit und pages_pool_size des AMDGPU-Treibers verändern. Wenn Sie 20 GiB GGT-Speicher nutzen wollen, müssen Sie für beide Optionen den Wert 5242880 angeben (Anzahl der 4-kByte-Blöcke):

# neue Datei /etc/modprobe.d/amd.conf
# 20 * 1024 * 1024 * 1024 / 4096 = 20 * 1024 * 256 = 5242880
options ttm pages_limit=5242880
options ttm page_pool_size=5242880

Danach aktualisieren Sie die Initrd-Dateien und führen einen Neustart durch:

sudo update-initramfs -u                   # Debian und Ubuntu
sudo dracut --regenerate-all --force       # Fedora, RHEL, SUSE

sudo reboot

sudo dmesg | grep "amdgpu.*memory"

  amdgpu: 2048M of VRAM memory ready   (<-- laut BIOS-Einstellung)
  amdgpu: 20480M of GTT memory ready   (<-- laut /etc/modprobe.d/amd.conf)

Modellauswahl

Mit llama.cpp können Sie grundsätzlich jedes Modell im GPT-Generated Unified Format (GGUF) ausführen. Auf der Website von HuggingFace stehen Tausende Modelle zur Wahl:

https://huggingface.co/models?pipeline_tag=text-generation&library=gguf

Die Herausforderung besteht darin, für die eigenen Zwecke relevante Modelle zu finden. Generell ist es eine gute Idee, besonders populäre Modelle vorzuziehen. Außerdem werden Sie rasch feststellen, welche Modellgrößen für Ihre Hardware passen. Die höhere Qualität großer Modelle bringt nichts, wenn die Geschwindigkeit gegen Null sinkt.

gpt-oss-20b

Eine llama.cpp-kompatible Version finden hat ggml-org auf HuggingFace gespeichert. Sofern ca. 15 GiB freier VRAM zur Verfügung stehen (unter AMD: VRAM + GTT), führt llama.cpp das Modell problemlos und beachtlich schnell aus. Beachten Sie, dass es sich hier um ein »Reasoning-Modell« handelt, das zuerst über das Problem nachdenkt und diesen Denkprozess auch darstellt. Danach wird daraus das deutlich kompaktere Ergebnis präsentiert.

llama-cli -hf ggml-org/gpt-oss-20b-GGUF -p 'bash: explain array usage'

  ...

llama-bench -m ~/.cache/llama.cpp/ggml-org_gpt-oss-20b-GGUF_gpt-oss-20b-mxfp4.gguf

  model                         size     test   token/s
  -----------------------  ---------  -------  --------
  gpt-oss 20B MXFP4 MoE    11.27 GiB    pp512    305.68
  gpt-oss 20B MXFP4 MoE    11.27 GiB    tg128     27.93

Server-Betrieb

Die Kommandos llama-cli und llama-bench dienen in erster Linie zum Testen und Debuggen. Sobald Sie sich einmal überzeugt haben, dass llama.cpp grundsätzlich funktioniert, werden Sie das Programm vermutlich im Server-Betrieb einsetzen. Das entsprechende Kommando lautet llama-server und ist grundsätzlich wie llama-cli aufzurufen. Falls Sie llama-server unter einem anderen Account als llama-cli aufrufen, aber schon heruntergeladene Modelle weiterverwenden wollen, übergeben Sie deren Pfad mit der Option -m:

llama-server -c 0 -fa on --jinja -m /home/kofler/.cache/llama.cpp/ggml-org_gpt-oss-20b-GGUF_gpt-oss-20b-mxfp4.gguf

Sie können nun unter http://localhost:8080 auf einen Webserver zugreifen und das gestartete Modell komfortabel bedienen. Im Unterschied zu Ollama hält llama.cpp das Modell dauerhaft im Arbeitsspeicher. Das Modell kann immer nur eine Anfrage beantworten. Die Verarbeitung mehrere paralleler Prompts erlaubt --parallel <n>.

Es ist unmöglich, mit einem Server mehrere Modelle parallel anzubieten. Vielmehr müssen Sie mehrere Instanzen von llama-server ausführen und jedem Dienst mit --port 8081, --port 8082 usw. eine eigene Port-Nummer zuweisen. (Das setzt voraus, dass Sie genug Video-Speicher für alle Modelle zugleich haben!)

Falls auch andere Rechner Server-Zugang erhalten sollen, übergeben Sie mit --host einen Hostnamen oder eine IP-Nummer im lokalen Netzwerk. Mit --api-key oder --api-key-file können Sie den Server-Zugang mit einem Schlüssel absichern. Mehr Details zu den genannten Optionen sowie eine schier endlose Auflistung weiterer Optionen finden Sie hier:

https://github.com/ggml-org/llama.cpp/tree/master/tools/server

Was bringt die GPU? Nicht viel …

Jetzt habe ich drei Tage versucht, gpt-oss per GPU auszuführen. Hat sich das gelohnt? Na ja. Mit -ngl 0 kann die Token Generation (also das Erzeugen der Antwort per Sprachmodell) von der GPU auf die CPU verlagert werden. Das ist natürlich langsamer — aber erstaunlicherweise nur um 25%.

llama-bench -ngl 0 -m ~/.cache/llama.cpp/ggml-org_gpt-oss-20b-GGUF_gpt-oss-20b-mxfp4.gguf

  model                         size     test   token/s
  -----------------------  ---------  -------  --------
  ...
  gpt-oss 20B MXFP4 MoE    11.27 GiB    tg128     21.15

Warum ist der Unterschied nicht größer? Weil die 780M keine besonders mächtige GPU ist und weil die Speicherbandbreite der iGPU viel kleiner ist als bei einer dezidierten GPU mit »echtem« VRAM.

Zur Einordnung noch zwei Vergleichszahlen: MacBook Pro M3: 42 Token/s (mit GPU) versus 39 Token/s (nur CPU)

Quellen/Links

Sprachmodell gpt-oss

• https://huggingface.co/openai/gpt-oss-20b
• https://huggingface.co/ggml-org/gpt-oss-20b-GGUF
• https://simonwillison.net/2025/Aug/5/gpt-oss
• https://github.com/ggml-org/llama.cpp/discussions/15095

Ollama

• https://ollama.com
• https://github.com/ollama/ollama/blob/main/docs/gpu.md#overrides
• https://github.com/ollama/ollama/issues/12062
• https://github.com/ollama/ollama/pull/6282

llama.cpp

• https://github.com/ggml-org/llama.cpp
• https://github.com/ggml-org/llama.cpp/discussions/15709
• https://huggingface.co/models?pipeline_tag=text-generation&library=gguf
• https://community.frame.work/t/igpu-vram-how-much-can-be-assigned/73081/7
• https://github.com/ggml-org/llama.cpp/tree/master/tools/server

Die Raspberry-Pi-Entwickler offerieren bereits zwei SSDs für ihren Minicomputer. Zu denen gesellt sich ab sofort ein Modell mit 1 TByte Speicherplatz. Berappen muss man dafür rund 77 Euro.

Die Raspberry-Pi-Entwickler offerieren bereits zwei SSDs für ihren Minicomputer. Zu denen gesellt sich ab sofort ein Modell mit 1 TByte Speicherplatz. Berappen muss man dafür rund 77 Euro.

Derzeit sehen sich Unternehmen und Behörden mit einer besonders heiklen Bedrohungslage konfrontiert: Mehrere schwerwiegende Sicherheitslücken in Android, Linux und im Sitecore-CMS werden nach…

Nach über drei Jahren Entwicklungszeit steht nun der nächste große Schritt bevor: Am Donnerstag, den 25. September soll die Beta-Version des neuen COSMIC Desktops erscheinen,gemeinsam mit der Beta von Pop!_OS 24.04 LTS. Das gab der Hardwarehersteller System76 über den firmeneigenen X Kanal bekannt. Der COSMIC-Desktop wird vollständig in Rust entwickelt und stellt einen radikalen Bruch mit dem […]

Der Beitrag System76 kündigt Beta von COSMIC-Desktop und Pop!_OS 24.04 an erschien zuerst auf fosstopia.

Nachdem Mozilla den Browser Firefox für 32-Bit-Linux-Systeme lange bereitgestellt hat und nach eigenem Bekunden noch lange nachdem die meisten anderen Browser und Betriebssysteme die…

Anthropic, das KI-Unternehmen hinter dem beliebten Chatbot Claude, wird 1,5 Milliarden Dollar zahlen, um eine Sammelklage von Buchverlagen und Autoren zu befrieden, deren Bücher unrechtmäßig für…

Mit der neuen Version 2025.9 bekommt Home Assistant, die kostenlose und quelloffene Software zur Hausautomation unter anderem ein neues Dashboard.

Das KDE-Projekt bringt mit KDE-Linux die neue Referenz für den eigenen Desktop und die KDE-Apps. Im Gegensatz zu KDE neon dient Arch Linux als Basis. Das System ist als immutable ausgelegt und neue Software kann über Flatpak, Snap oder AppImages installiert werden.

Das Debian‑Projekt hat das erste Point-Release für seine stabile Version Debian 13, Codename „Trixie“, herausgebracht. Es liefert umfangreiche Fehlerkorrekturen und Sicherheitsupdates, die die Systemstabilität deutlich erhöhen. Wichtig ist: Dieses Update stellt keine neue Version dar, sondern aktualisiert bestehende Pakete. Sie brauchen Ihre alten „Trixie“-Installationsmedien nicht wegzuwerfen. Besteht bereits ein „Trixie“-System, genügt ein klassisches Update über einen aktuellen Debian‑Mirror, um auf den […]

Der Beitrag Debian 13 „Trixie“: Erstes Point-Relese bringt Fehlerkorrekturen und beseitigt Sicherheitslücken erschien zuerst auf fosstopia.

Firefox bietet eine Integration gleich mehrerer KI-Chatbots. Der Microsoft Copilot ist bislang nicht dabei. Dies ändert sich mit Firefox 143.

Seit Firefox 135 integriert Mozillas Browser mehrere KI-Chatbots. Dabei stehen Google Gemini, ChatGPT, Anthropic Claude sowie Le Chat Mistral zur Verfügung. Die Chatbots können direkt über die Sidebar genutzt werden.

Mit Firefox 143 kommt eine weitere Option hinzu: Microsoft Copilot. Über einen Eingriff in about:config war es zuvor bereits möglich, Microsoft Copilot als Chatbot in Firefox zu integrieren. Mit Firefox 143 wird diese Option ganz offiziell unterstützt, ohne dass der Nutzer die Unterstützung erst manuell freischalten muss.

Der Beitrag Firefox 143 erhält Microsoft Copilot als Chatbot erschien zuerst auf soeren-hentzschel.at.

Es ist wieder so weit. Ich tausche für zwei Wochen den Chefsessel im heimatlichen Büro gegen den Fahrradsattel.

Anders als die meisten Browser und Linux-Distributionen läuft Firefox nach wie vor auf Linux-Systemen mit 32-Bit-CPU. Mit Firefox 144 wird Mozilla die Unterstützung beenden.

Mozilla hat angekündigt, die Unterstützung von Firefox auf Linux-Systemen mit 32-Bit-CPU zu beenden. Die meisten Linux-Distributionen und Browser unterstützen solche Systeme schon seit langer Zeit nicht mehr. Firefox 144 wird die letzte Firefox-Version sein, welche auf betroffenen Systemen läuft. Wenn am 11. November 2025 Firefox 145 erscheinen wird, wird für Linux-Nutzer eine 64-Bit-CPU vorausgesetzt. Firefox ESR 140, die Firefox-Version mit Langzeit-Unterstützung, wird weiterhin und bis mindestens September 2026 auf Linux-Systemen mit 32-Bit-CPU laufen.

Der Beitrag Firefox: Unterstützung für 32-Bit Linux wird eingestellt erschien zuerst auf soeren-hentzschel.at.

Die Rust Foundation, die sich der Förderung der Programmiersprache Rust und ihrer globalen Community widmet, hat das  Rust Innovation Lab gegründet.

Canonical treibt die Integration von Rust in das Herz des Ubuntu-Systems weiter konsequent voran. Mit Ubuntu 25.10, Codename „Questing Quokka“, ersetzt die Distribution gleich zwei zentrale Systemkomponenten durch moderne Rust-Alternativen: Sowohl das Befehlszeilentool sudo als auch die traditionellen Coreutils stammen künftig aus Rust-Projekten. Bereits Anfang des Jahres hatte Canonical angekündigt, sudo-rs und uutils, eine Rust-basierte Neuimplementierung der GNU Coreutils, zur Standardlösung zu […]

Der Beitrag Ubuntu 25.10 bricht mit der Tradition: Rust ersetzt zentrale Systemwerkzeuge erschien zuerst auf fosstopia.

Mit dem Supercomputer JUPITER wird der erste Rechner der Exascale-Klasse in Europa offiziell in Betrieb genommen.

Es gibt verschiedene Möglichkeiten, Flatpaks zu entdecken und zu installieren. Das reicht vom Terminal GNOME Software und KDE Discover bis hin zu Flathub. Jetzt kommt mit Bazaar ein reiner Flatpak-Shop hinzu.

Mozilla hat die Unterstützung von Firefox für die veralteten Betriebssysteme Windows 7, Windows 8, macOS 10.12, macOS 10.13 sowie macOS 10.14 offiziell um weitere sechs Monate bis März 2026 verlängert.

Im September 2024 hatte Mozilla die Verlängerung der Unterstützung von Firefox ESR 115 für die veralteten Betriebssysteme Windows 7, Windows 8, macOS 10.12, macOS 10.13 sowie macOS 10.14 bis März 2025 angekündigt. Firefox 116 und höher kann auf diesen Betriebssystemen nicht genutzt werden. Nach einer Verlängerung bis September 2025 folgte nun eine weitere Verlängerung der Lebenszeit von Firefox ESR 115 bis März 2026.

Die letzte geplante Version wäre damit Firefox ESR 115.33. Ob es darüber hinaus eine weitere Verlängerung geben wird, wird kurz vor Erreichen des geplanten Support-Endes bekannt gegeben werden. An der Unterstützung von Firefox ESR 128 ändert dies nichts: Firefox ESR 128 hat offiziell sein Lebensende erreicht, bestehende Nutzer von Firefox ESR 128 werden ab dem 16. September automatisch auf Firefox ESR 140 migriert.

Nach aktuellem Stand nutzen noch 7,9 Prozent der Firefox-Nutzer Windows 7 oder Windows 8, verglichen mit 9,1 Prozent, die es zum Zeitpunkt der letzten Support-Verlängerung waren. Ein halbes Jahr zuvor waren es noch 10,5 Prozent, ein Jahr davor 13,7 Prozent und ein Jahr davor noch 19,1 Prozent. Microsoft selbst hatte die Unterstützung bereits im Januar 2020 eingestellt. Firefox-Konkurrent Google Chrome bietet seit Februar 2023 keine Updates mehr für diese Betriebssysteme an.

Tipp: Release-Termine von Firefox im Jahr 2025

Für Nutzer des E-Mail-Programms Thunderbird hat diese Entscheidung keine Auswirkungen. Thunderbird hat die Unterstützung für Windows 7, Windows 8, macOS 10.12, macOS 10.13 und macOS 10.14 bereits eingestellt.

Der Beitrag Firefox: Unterstützung für veraltete Betriebssysteme bis März 2026 verlängert erschien zuerst auf soeren-hentzschel.at.

Bevor bei Sparfuchs Mike Schilli ein neues Gadget in den Haushalt kommt, überwacht er dessen Stromverbrauch mit einem Go-Programm und entscheidet mittels aufschlussreicher Graphen, ob es bleiben…

Die EPFL (École polytechnique fédérale de Lausanne), die ETH Zürich und das Schweizerische Supercomputing-Zentrum CSCS haben ein von ihnen entwickeltes Sprachmodell namens Apertus vorgestellt.