Lohnt sich in der heutigen Zeit noch ein Tastaturlernprogramm? Man kann doch einfach in ein Mikro sprechen - fertig. Falls aber doch: Ist der Klassiker "Tipp10" eine gute Wahl? Schauen wir mal, was das Programm so kann.

Für die Neuauflage meines Scripting-Buchs habe ich mich zuletzt mit dem Senden und Empfangen von E-Mails per SMTP und IMAP beschäftigt. Dieser Blog-Beitrag stellt das Standardmodul imaplib vor. Damit können Sie per IMAP Postfächer abrufen und verwalten. Die Anwendung ist ein wenig umständlich, aber dafür können Sie wirklich praktisch alles machen, was das Protokoll IMAP vorsieht.

Kurz erklärt: IMAP und Authentifizierung

IMAP (Internet Message Access Protocol) ist das Standardprotokoll zum Abrufen und Verwalten von E-Mails auf einem Mailserver. Die Verbindung erfolgt normalerweise über Port 993 mit SSL/TLS. Im Unterschied zu POP3 verbleiben die Nachrichten auf dem Server und lassen sich in Ordnern organisieren – IMAP eignet sich daher besonders gut für die automatisierte Verarbeitung.

Klassische Unix/Linux-Mailserver erlauben die Anmeldung mit Benutzername und Passwort. Bei Google-Konten ist das anders: Gmail erfordert entweder App-Passwörter (16-stellige Codes, die Sie nach Aktivierung der Zwei-Faktor-Authentifizierung unter myaccount.google.com/apppasswords erstellen) oder OAuth2. App-Passwörter sind dabei die einfachere Variante für Scripts.

Passwörter sollten nie direkt im Scriptcode stehen. Die Beispiele hier lesen die Zugangsdaten aus Umgebungsvariablen, die wiederum aus einer Datei credentials.env geladen werden:

# credentials.env  (chmod 600; in .gitignore aufnehmen!)
IMAP_HOST=mail.example.com
IMAP_USER=username
IMAP_PASS=topSecret

In Python laden Sie die Datei am einfachsten mit python-dotenv:

from dotenv import load_dotenv
load_dotenv("credentials.env")

Das Modul installieren Sie mit pip install python-dotenv oder – wenn Sie uv verwenden – mit uv add python-dotenv.

imaplib: Verbinden, suchen und herunterladen

imaplib ist seit Python 2 Bestandteil der Standardbibliothek und deckt den vollständigen IMAP-Befehlssatz ab. Das folgende Beispiel-Script stellt die Verbindung zur Inbox her, lädt die zehn neuesten E-Mails herunter und zeigt die wichtigsten Metadaten tabellarisch an – mit * als Indikator für noch ungelesene Nachrichten:

* 13-05 17:53  papa.xxx@xxx...     AW: Halbjahresabrechnungen
  12-05 20:48  kundenxxx@xxx...    Terminanfrage Sendungszustel...
  12-05 04:02  info@weltxxx...     Japan, Korsika oder Sansibar ...
  11-05 20:51  noreply@xxx...      OpenAI Dev News: Realtime 2.0...
  05-05 18:58  cron@webxxx         Invitation updated: iprot dev 
  04-05 08:28  externexxx@fhxxx... Vertrag bereit zur Abbrechnung

imaplib.IMAP4_SSL stellt die Verbindung zum IMAP-Server auf Port 993 her. select öffnet einen Ordner, search liefert eine Liste von Nachrichten-IDs als leerzeichen-getrennte Byte-Zeichenkette, fetch lädt die Rohdaten einer einzelnen oder mehrerer Nachrichten.

Der Parameter readonly=True bei select stellt sicher, dass das Abrufen der Nachrichten keine Nebeneffekte hat – insbesondere werden keine Nachrichten als gelesen markiert. Das ist wichtig, weil IMAP-Server den Status einer Nachricht bereits beim Öffnen verändern können.

search(None, "ALL") liefert eine aufsteigend sortierte Liste aller Nachrichten-IDs im Postfach. Mit split()[-10:] extrahieren Sie die zehn neuesten. Diese IDs werden, getrennt durch Kommas, zu einem einzigen fetch-Aufruf zusammengefasst. Als Fetch-Attribute übergeben Sie FLAGS für den Lesestatus sowie BODY.PEEK[HEADER.FIELDS (...)], um nur die benötigten Header-Felder abzurufen. PEEK verhindert dabei, dass der Server die Nachrichten automatisch als gelesen kennzeichnet.

Jede Zeile der Server-Antwort ist ein Tupel aus Metadaten und rohen Header-Bytes. ParseFlags wertet die Metadaten aus und gibt die IMAP-Flags als Tupel zurück. Wenn \Seen fehlt, gilt die Nachricht als ungelesen. message_from_bytes wandelt die Header-Bytes in ein auswertbares Objekt um.

parsedate_to_datetime macht aus einem RFC-2822-Datum ein datetime-Objekt, das dann mit strftime nach eigenen Vorstellungen formatiert werden kann. parseaddr zerlegt das From-Feld in ein (Name, Adresse)-Tupel. MIME-kodierte Header-Zeichenketten wie =?utf-8?q?...?= entschlüsselt decode_header aus dem Modul email.header.

Die Ergebnisse werden zunächst in einer Liste gesammelt, da die Reihenfolge der Server-Antwort nicht zwingend der Reihenfolge der angefragten IDs entspricht. reversed dreht die Liste beim Ausgeben um, sodass die neueste Nachricht zuerst erscheint.

# Beispieldatei fetch-imap.py
import os, email, imaplib
from email.header import decode_header, make_header
from email.utils import parsedate_to_datetime, parseaddr
from dotenv import load_dotenv

# IMAP-Konfigurationsparameter lesen
load_dotenv("credentials.env")
HOST = os.environ["IMAP_HOST"]
USER = os.environ["IMAP_USER"]
PASS = os.environ["IMAP_PASS"]

# RFC-2047-Header (=?utf-8?q?...?=) dekodieren
def decode_mime(value: str | None) -> str:
    return str(make_header(decode_header(value or "")))

# Zeichenkette auf max_len verkürzen
def truncate(text: str, n: int) -> str:
    return text if len(text) <= n else text[: n - 3] + "..."

# Verbindung zum IMAP-Server
with imaplib.IMAP4_SSL(HOST) as imap:
    imap.login(USER, PASS)
    imap.select("INBOX", readonly=True)  # nichts ändern!

    # IDs aller Nachrichten ermitteln -> Byte-String für fetch()
    _, data = imap.search(None, "ALL")
    id_set = b",".join(data[0].split()[-10:])  # max. 10

    # IDs der ungelesenen Nachrichten
    _, unseen_data = imap.search(None, "UNSEEN")
    unseen = set(unseen_data[0].split())

    # relevante Spalten abfragen (IMAP-Syntax); PEEK, damit
    # das Seen-Flag nicht gesetzt wird
    fields = "(FLAGS BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT)])"
    _, rows = imap.fetch(id_set, fields)

    # Daten/Spalten dekodieren und formatieren
    messages = []
    for row in rows:
        if not isinstance(row, tuple):
            continue
        meta, raw_headers = row
        # Sequence-Nummer am Beginn der Metadaten (b'4 (FLAGS ...')
        seq     = meta.split()[0]
        is_new  = seq in unseen
        msg     = email.message_from_bytes(raw_headers)
        dt      = parsedate_to_datetime(msg["Date"])
        date    = dt.strftime("%d-%m %H:%M")
        addr    = parseaddr(decode_mime(msg.get("From", "")))[1]
        sender  = truncate(addr, 20)
        raw_sub = decode_mime(msg.get("Subject", "(no subject)"))
        subject = truncate(raw_sub, 40)
        messages.append((is_new, date, sender, subject))

    # in umgekehrter Reihenfolge ausgeben, die neueste Mail zuerst
    for is_new, date, sender, subject in reversed(messages):
        flag = "*" if is_new else " "
        print(f"{flag} {date}  {sender:<20}  {subject}")

Was imaplib sonst noch kann

Das obige Beispiel kratzt nur an der Oberfläche. imaplib deckt den vollständigen IMAP-Befehlssatz ab:

• Vollständige Nachrichten laden: Mit fetch können Sie nicht nur Header, sondern auch den kompletten Nachrichtentext inklusive Anhänge abrufen.
• Filtern: search akzeptiert IMAP-Suchkriterien wie FROM, SUBJECT, SINCE oder UNSEEN, um gezielt nach bestimmten Nachrichten zu suchen.
• Flags setzen: store setzt oder entfernt Flags wie \Seen, \Flagged oder \Deleted.
• Löschen: expunge löscht die als \Deleted markierten Nachrichten endgültig.
• Ordner verwalten: copy verschiebt Nachrichten zwischen Ordnern, list gibt alle verfügbaren Mailboxen zurück, create und delete legen neue Ordner an oder entfernen sie.

Kurz gesagt: Von der einfachen Posteingangsübersicht bis zur vollautomatisierten Mailbox-Verwaltung ist alles drin.

Alternativen zu imaplib

Wer die etwas sperrige API von imaplib als mühsam empfindet, kann auf IMAPClient ausweichen. Die Bibliothek ist ein High-Level-Wrapper um imaplib, der insbesondere den Umgang mit Nachrichten-IDs, Flags und Ordnern deutlich angenehmer macht. Das folgende Mini-Beispiel zeigt die Verbindung und das Abrufen der Betreffzeilen aller ungelesenen Nachrichten:

from imapclient import IMAPClient

with IMAPClient(HOST) as client:
    client.login(USER, PASS)
    client.select_folder("INBOX", readonly=True)
    messages = client.search("UNSEEN")
    for uid, data in client.fetch(messages, "ENVELOPE").items():
        print(data[b"ENVELOPE"].subject.decode())

IMAPClient installieren Sie mit pip install imapclient bzw. uv add imapclient.

Wer IMAP in einem asyncio-Kontext benötigt, greift zu aioimaplib – einer vollständig async-fähigen Bibliothek, da imaplib synchron blockiert. Und imbox ist eine sehr einsteigerfreundliche Abstraktion, die E-Mails als Python-Objekte mit direkt zugänglichen Attributen wie .subject oder .attachments liefert. Der Nachteil: weniger Kontrolle bei komplexen Operationen.

Quellen und Links

• imaplib – Dokumentation (docs.python.org)
• Introduction to IMAP (nickb.dev)
• python-dotenv
• IMAPClient
• aioimaplib
• imbox

Die Linux Foundation hat zusammen mit Industriepartnern wie Amazon Web Services, Anthropic, Cisco, Ericsson, Google, IBM, JPMorganChase, Microsoft, GitHub, NVIDIA, OpenAI, Red Hat oder der Rust…

Das Recht auf Reparatur soll für weniger Elektroschrott sorgen. Ein neuer Paragraf im BGB setzt es in deutsches Recht um.

OpenAI startet eine Preview-Phase für seine Modelle ChatGPT-5.6 Sol, Terra und Luna auf Weisung der US-Regierung für speziell ausgesuchte, besonders vertrauenswürdige Kunden.

Open Hardware and Free Software: Teufel Mynd, a case study

The FSFE's volunteer and open hardware passionate, Nicole Faeber read about the Teufel Mynd speaker announced as an "Open Source Project", so she decided to put it to the test. We, the FSFE, bought one and she dug in. Curious what she found? Read along with us!

Open hardware and Free Software are about more than tinkering: they give users the freedom to inspect, modify, and truly understand the technology they rely on every day. Open hardware means the design of a device is publicly available: anyone can study how it's built, improve it, or manufacture it themselves. Free Software goes hand in hand with this: it guarantees that the code running on your devices can be use, study, share, and improve by anyone. Together, they ensure that whoever owns a device gets to decide what runs on it, free from manufacturer lock-in or hidden restrictions.

This article has not been sponsored by Teufel in any way. We bought the device to test from our own money and did all research on our own.

In May 2025 the German audio hardware maker company Teufel announced a new product, the Mynd Bluetooth speaker box. The speaker in itself is yet another Bluetooth speaker box, the remarkable feature of it is that it was announced as an "Open Source Project" with "high repairability and sustainability", with all mechanical and electronics design files as well as the firmware source code published as "open source". So they mean the Mynd to be a Free Software and open hardware product.

So we wanted to put this to a test!

TL;DR - A Quick Summary

The Teufel Mynd project is a pretty impressive example of an Open Source Hardware project. All the mechanical and electronics design files are made public under a permissive license granting the four freedoms - to study, to share, to modify and to distribute modified versions of it. The data is complete enough to recreate the whole hardware, the mechanical enclosure as well as the electronics PCBs.

There are only two caveats:

1. The loudspeakers themselves are, at least very likely, Teufel proprietary and Teufel does not sell them as spare parts.
2. The firmware for the Bluetooth module along with some DSP and USB type-C controller firmware are not Free Software. But at least the files are provided as binary blobs so one can build a complete firmware update file.

So the project fulfills the Open Source Hardware Definition.

Let's dive into the details!

Repairability

Many current consumer electronic devices these days are not repair friendly. Cost pressure and ease of mass production make the non-repairable options, like glue instead of screws, very appealing to manufacturers.

The Mynd is very different in this regard. The case is held together by screws, not glue. The parts are pieced together tightly with proper rubber seals, not glue strips. The screws are clearly visible and marked, not hidden away under some sticker label or warranty seal. The different screw sizes and types are documented on the bottom of device itself. Also the starting point to pry the casing parts apart after taking out the screws is marked on the case. So opening the device is really made as easy as possible, no guessing, the steps for dis- and reassembly are clear and pretty much self explanatory.

There is just one caveat, availability of spare parts. So far Teufel only offers the battery pack and carrying belts as spare parts, not the Printed Circuit Boards (PCBs) or speaker chassis themselves. Maybe it is possible to convince the Teufel service center to buy these, but Teufel's general policy for spare parts says: "Please note: We do not ship circuit diagrams, toner, or electronic components such as circuit boards, capacitors, and resistors". For the average customer, this limits repairability.

Open Hardware

As promised in the product announcement, Teufel made all hardware design files publicly available on GitHub. All these files are, where applicable, licensed under the Creative Commons "Attribution-ShareAlike 4.0 International" license which allows the four freedoms: Use, study and modify, redistribute the original and modifications.

This is pretty remarkable!

3D CAD, the casing

All components of the case are split into separate 3D CAD files and are available in 3DM, STL and STP format. In total there are 11 different parts that make up the case / chassis. Here we have the main case STP file opened in FreeCAD:

So yes, everything is there, the full case and all its parts! Can you remake it, like 3D print? Well, let's see, here is the front grill STL file opened in the Cura 3D printer slicer:

This is looking pretty good! Since the Mynd speaker box is quite big you of course need a large 3D print room, the front grill is 26cmx18cm. But the problem is in the details. The 3D CAD design has not been optimised for 3D printing but rather for injection mold production so this makes 3D printing difficult and we can see the issue when looking at the print plate from underneath:

All the red parts are free floating, i.e. these do not touch the print surface and will create issues while printing. With some luck and a good printer these will still come out OK but they may also end up quite ugly. Another a bit problematic part are the "knobs" on the top side which hold the front grill tight in rubber gaskets of the speaker fixture:

These little knobs also have some overhangs which can create issues while printing.

So is the CAD design indeed "open hardware"? Yes! It is open licensed and you can use Free Software tools like FreeCAD or Cura slicer to tinker with it, even try to reproduce parts e.g. using 3D printing. The 3D printing limitations (overhangs etc.) are not a detriment to the open hardware nature, nothing requires open hardware to be easily reproducible.

Electronics, schematics and PCBs

Next let's have a look at the electronics design, also for this all relevant files are available in the same hardware GitHub repository under the same "Attribution-ShareAlike 4.0 International" license. Again the files are made available in three file formats: Altium Designer, KiCAD and PDF. The PDF files are PDF exports of the schematics and the printed circuit board (PCB) layout. The Altium Designer and KiCAD formats are the much more interesting ones since these contain the editable schematics and PCB layout! Since we only use Free Software we cannot use the Altium files, so we focus on the KiCAD version for now - I assume that the original design was made using Altium and was then exported to KiCAD.

Excursion: Electronics making

To design and finally make a piece of electronics, a number of pieces are needed. First you need to have some idea what you are going to make, of course. Based on this you need to start choosing components for your design - which chips to use, which power supply these need, how this needs to be designed with which parts etc. So from a very early stage the component selection is a critical first step, we'll also come back to this a little later.

Next you need to start to draft your electronics design, i.e. how all the components are connected to each other. This is done in the so called schematics. Every single connection of each of the components is made here. The schematics usually does not look similar to the final PCB, it is a rather abstracted view on the hardware and focuses on the parts choice and the connection between the parts.

Once the schematics is somewhat ready the next phase is a real time sink, creating a PCB layout from the schematics. Tools like Altium or KiCAD assist with it, they know the physical sizes and constraints of the components and visualize it for you. But in the end the engineer has to properly place them on the virtual PCB. Placing is not only a matter of just putting them somewhere but you also need to know electrical constraints and keep routing the connections in mind. Creating a PCB from known schematics can take days and weeks and needs a lot of experience. Adding to that there may be mechanical constraints as well, e.g. known maximum PCB sizes or shapes that need to be taken into account.

Once the schematics and PCB layout is done the PCB can be ordered from a PCB manufacturer and all electronic components can be ordered from the various distributors. In many cases you need to order from more than one distributor because not even the large ones carry all components - and fingers crossed everything is in stock!

Once PCBs arrive and all parts are at hand you can finally start to assemble the PCB and power it up for the first time: Good luck the "magic smoke" stays within the parts!

The main board

So let's have a look at the main PCB as an example:

The Teufel engineers created a full KiCAD project for each PCB that can be directly and completely opened in KiCAD with all parts - schematics, footprints, 3D components and the full PCB design. Here is one page of the main PCB schematics for the main microcontroller:

Schematics

The schematics only show a limited level of detail, some details necessary for actually making a device are not shown. For example the component with designator "C22C" right of the microcontroller unit (MCU), in the schematics you can only see that it is a capacitor with 100nF capacity. But the actual specification needed contains a lot more information, which is also contained in the KiCAD project:

So here you can see that it is rated for maximum voltage of 50V, has a temperature coefficient of X7R, a tolerance of +/-10% and that the physical so called "footprint" is 0603, which means a surface mount device (SMD) 6mil long and 3mil wide - 'mil' is 100th of an inch, a common size in PCB design, so about 1.6mm in length and 0.8mm wide. A pretty small component. Each and every component needs to be specified this way.

For a capacitor one usually can find components with the same specification from different manufacturers which makes component sourcing a bit easier. Some distributors allow importing a Bill Of Material (BOM) into their shop system and will offer best matches. For some other components there can be a variety of choices with very similar specifications which can make picking the right one complicated. In this case an exact manufacturer part number comes to the rescue:

In this example there is the main PCBs microntroller unit, specified with its exact manufacturer and the manufacturer's part number, ready for ordering.

Speaking of ordering, it is also quite common, especially for commercial projects, to also specify an ordering source within the project, so that later on a BOM can be exported and handed over to e.g. a purchasing person or department for ordering all the components. In the KiCAD Mynd project there are no ordering sources.

So, are the electronics design schematics open hardware? Yes! It is licensed under an open license providing the four freedoms. All necessary information to understand the schematics is included as well as all information to make a PCB from the schematics.

PCB layout

And now to the real fun part, the PCB layout. I won't go into the details here because there would be too much to cover. Just to give an idea here is the main PCB view in KiCAD's PCB editor:

This is a 4-layer PCB, i.e. it has four layers of copper traces, top, bottom and two in between. This PCB alone carries 561 components! Many of them small SMD components, the smallest being some 0402 resistors (4mil x 2mil = ~1mm x ~0.5mm). And to make things even worse, there are components placed on both sides of the PCB which makes soldering even more complicated. In KiCAD there is an awesome feature to create an interactive 3D view of the designed PCB, here is the Mynd Main PCB front and back:

In total there are nine (9) PCBs in the Mynd speaker box, the main and amplifier PCBs being the largest and most complex. In total there are 1047 components on these 9 PCBs, about 87 different types of components. Just managing the supply and stock of 87 different component types is, I can tell from experience, a major effort.

Is the PCB layout open hardware? Yes! You have the four freedoms and the hardware design details are complete enough to rebuild the whole thing! From parts specification to PCB specification (so called "stack up") everything is there. The only issue one might run into trouble with is finding ordering sources for all the components, but that's probably outside of the scope of open hardware anyway.

Make it yourself?

Well, I have not tried, but looking at the design files, mechanical and electronics, I think building the Mynd speaker hardware from scratch should be possible. I have not found any information missing, except maybe ordering sources for the components. Placing and soldering all over 1000 components on the nine PCBs will be a major effort and with components down to 0402 will be difficult to place by hand, some pick & place setup would be very helpful along with proper SMD reflow soldering equipment. But the important part here is that there is no information missing in the design files, it's all there.

3D printing the case could be possible as well, with some additional effort to accommodate for 3D printing instead of injection molding. The result will very likely look and feel differently, but it could work.

What will definitely become a problem are the Teufel specific custom parts, i.e. the speaker chassis themselves. Other parts like the rubber gaskets and rubber seals these are also in the 3D design files but will be hard to e.g. 3D print properly.

The firmware

And now to the final part, there is also some software involved! The main MCU, a STM32 microcontroller, runs some software as well as is the module used for the Bluetooth connectivity and sound generation. The source code and build scripts were also made available by Teufel. The parts created by Teufel, i.e. the application software running on that STM32 MCU, are licensed under the MIT license. But for building it, some more dependencies are needed, like some software development kit (SDK) bits from ST-Micro (Apache 2.0, BSD 3-clause, MIT, proprietary ST SLA), bits and pieces of FreeRTOS (MIT) and some more proprietary binary only parts for the Bluetooth module, the audio DSP and, last but not least, the USB type-C port controller - yes, also these things have their own firmware these days.

So apart from the blobs everything is Free Software, which is pretty cool! The blobs though are a bit of a bummer. But is this Teufel's fault? Or does this make the whole project less "open hardware"?

My personal take on such blobs is this: While I dislike proprietary blobs in general, because they limit our freedoms to use the hardware as we like, I can at least accept certain blobs, e.g. in the case where chip+blob form a kind of union so that I can basically view the two together as just a single piece of hardware. I still don't like it, because it is hidden software, but at least I can somewhat accept it. We have this kind of situation in many cases and are somewhat OK with it - the WiFi firmware in our WiFi cards, the firmware in the touchpad controller of our laptops etc. The list is long, very long. How to properly address and fix this is another story we need to come back to another time.

The firmware package can be built using the free GNU GCC cross compiler for ARM and build the firmware for the STM32 MCU. The firmware blobs for the DSP, Bluetooth module and the USB type-C controller do not get built and it is also not documented how to program these. But at least the binaries are there.

So is the firmware Free Software? Concerning the MCU firmware, yes, it is. All firmware? No, there are certain blobs.

Especially sad is that the Bluetooth part is completely binary only in the Bluetooth firmware blob, so all pairing, Bluetooth audio protocol (A2DP with SBC) etc. is hidden in that blob and can not be changed - I would have been curious if SBC-XQ (higher quality audio codec) or TWS (True Wireless Stereo) could be added to that Bluetooth firmware.

Final verdict

So, is it open hardware?

Mechanical design / parts: Yes! Everything is documented properly, some special components are not available off the shelf and need alternative sources, especially the speakers. It would be great if Teufel would also supply these through their spare parts shop.

Electronics design: Yes! The KiCAD files contain everything one needs to completely recreate and especially repair the electronics. Some components may be difficult to source though (like the Bluetooth module).

Firmware: The Teufel made parts are Free Software, some third party firmware parts are not (USB type-C controller, DSP, Bluetooth module).

With all that it also qualifies nicely for the Open Source Hardware Definition by the Open Source Hardware Association (OSHWA).

Overall I think the Teufel engineers did an extremely good job here! They definitely set the bar and have given a great example of how one can make open and sustainable consumer hardware. For some first hand insights there is a nice interview with the engineers published on the Prototype Fund website (in German).

Will the openness detriment their business? I am fairly sure it won't. Yes, maybe competitors can learn a bit about high quality engineering, but on the other hand this isn't rocket science either. Will they loose business because people will now rather build it themselves instead of buying a ready made device from Teufel? I doubt that. While I am quite convinced that one could build a complete Mynd device from the open specifications, it would take many many work hours - the logistics for the over 1000 electronic components, populating the PCBs, 3D printing or otherwise making the enclosure etc. - this is a serious undertaking and will take weeks along with dozens of person hours. A good hacking experience, for sure! But economically definitely not worth it, better go and support the company that made it with a purchase.

Outlook

Open Hardware not only means better repairability and with it better sustainability. It also means possible enhancements too! For example the Bluetooth module in the factory Mynd only supports the rather mediocre SBC audio codec. But since the electronics are made modular and the rest of the system is documented so well, why not think about replacing this limiting Bluetooth module by something else? By something more capable?

Why not replace it with an ESP32 based module plus high quality audio codec chip? Would not be the first ESP32 based audio device.

Why stop at an ESP32? There is a discussion going on in the GitHub Mynd hardware repository about replacing the proprietary Bluetooth module with a Raspberry Pi Zero 2 W based module! This would not only enable other Bluetooth audio codecs but then you would also get a complete Linux system into your Mynd, with its own media playback capabilities! Prototypes already seem to exist.

This is the brilliance of Free Software and open hardware, the limit is your imagination, it is in your hands.

Happy hacking!

Do you care about sustainability, repairability and Free Software? Did you do research about which products work best with Free Software? Have you ever tried to tinker with them? We would love to hear your experiences. Please, share your knowledge with us. We want to know which products work better when you want to be in control of your devices! Moreover, if you are a skilled Free Software enthusiasts who would like to volunteer to also analyse devices, please get in touch with us, so we can work together towards our goal that so we can work together towards our goal that everyone can install or remove any software on any of our devices.

Support FSFE

Urlaub ist herrlich, um einfach mal abzuschalten. Doch nach ein paar Tagen der puren Erholung packt mich meistens wieder der Drang, etwas Kreatives oder Produktives zu tun. Ein gutes Buch lesen? Schon erledigt. Rätseln? Nun ja, dieses Jahr hatte ich mir Sudoku als Endgegner ausgesucht – was mich am Ende ehrlicherweise mehr angestrengt als erfreut hat. Immerhin war ich an anderer Stelle produktiv und habe die Auffrischung meines A2-Fernpiloten-Kompetenznachweises erfolgreich hinter mich gebracht.

Doch der Tech-Spleen lässt einen auch im Urlaub nicht ganz los. Mir ging da nämlich eine Sache durch den Kopf: Letztes Jahr hat Prof. Klaus Knopper auf den Chemnitzer Linux-Tagen einen extrem spannenden Vortrag zum Thema lokale KI gehalten. Konkret ging es um Ollama auf dem Raspberry Pi. Warum also nicht die freie Zeit nutzen, um das Ganze mal aus der Ferne auf dem heimischen RasPi zu installieren und selbst auszuprobieren?

Was ist Ollama?

Für alle, die den Begriff noch nicht gehört haben, hilft ein kurzer Blick in die Wikipedia:

Ollama ist eine Open-Source-Software zur lokalen Ausführung von Large Language Models (LLMs) auf Desktop-Computern. Die Plattform ermöglicht die lokale Nutzung frei verfügbarer KI-Modelle und unterstützt die Integration mit weiteren lokalen Werkzeugen, die über eine Kommandozeilenschnittstelle oder eine Programmierschnittstelle (API) angebunden werden können. Ollama ist für macOS, Linux und Windows verfügbar.

Installation

Gesagt, getan. Die Installation auf dem Raspberry Pi – in meinem Fall ein Raspberry Pi 5 mit 8 GB RAM – erfolgt denkbar einfach über das Terminal mit folgendem Befehl:

curl -fsSL https://ollama.com/install.sh | sh

Am Ende des Installationsvorgangs spuckt das System noch den dezenten Hinweis aus, dass keine NPUs oder Grafikkarten von Nvidia gefunden wurden, die die Ausführung des Large Language Models beschleunigen könnten. Das war beim RasPi natürlich zu erwarten, hält uns aber nicht auf.

Damit wir der KI überhaupt Fragen stellen können, muss im Anschluss ein passendes und vor allem schlankes Modell installiert werden. Für diesen ersten Test habe ich mich für llama 3.2 (ca. 2 GB) entschieden:

ollama run llama3.2:3b

Der Praxistest: Was taugt die lokale KI?

Nachdem das Modell geladen war, wollte ich es natürlich wissen. Ich habe der lokalen KI eine klassische Frage gestellt:

Welche Linux-Distribution würdest du einem Anfänger empfehlen?

Eine gute Frage!

Als Anfänger ist es wichtig, eine Linux-Distribution zu wählen, die leicht zu installieren und zu bedienen ist. Hier sind einige beliebte Optionen:

1. Ubuntu: Ubuntu ist eine der bekanntesten und am weitesten verbreiteten Linux-Distributionen. Sie bietet eine intuitive Benutzeroberfläche und eine riesige Gemeinschaft von Benutzern, die ihr helfen können, wenn
   etwas nicht funktioniert.
2. Linux Mint: Linux Mint basiert auf Ubuntu und ist für ihre einfache und benutzerfreundliche Oberfläche bekannt. Sie ist auch sehr sicher und bietet viele zusätzliche Funktionen wie eine verbesserte
   Sicherheitsfunktion und eine integrierte Diskografie.
3. Debian: Debian ist eine weitere beliebte Linux-Distribution, die für ihre Stabilität und Sicherheit bekannt ist. Sie bietet eine riesige Auswahl an Software und ist ein beliebter Kandidat für Entwickler und
   Systemadministratoren.
4. Fedora: Fedora ist eine Linux-Distribution, die von der Open Source Initiative verwaltet wird. Sie bietet eine aktuelle und sichere Version von Linux und ist ein beliebter Kandidat für Entwickler und
   Systemadministratoren.

Meine Empfehlung wäre Ubuntu. Sie ist eine großartige Option für Anfänger, da sie leicht zu installieren und zu bedienen ist. Außerdem bietet sie eine riesige Gemeinschaft von Benutzern, die ihr helfen können, wenn
etwas nicht funktioniert.

Ich hoffe, das hilft! Wenn du noch weitere Fragen hast, stehe ich gerne zur Verfügung.

Das Ergebnis kann sich absolut sehen lassen. Die Antwort hätte ich so oder so ähnlich wahrscheinlich auch gegeben. Ich bin wirklich nachhaltig beeindruckt, was der kleine Einplatinen-Computer hier ganz ohne Cloud-Anbindung zu leisten vermag.

Fazit

Eine lokale und ethische KI auf dem eigenen Raspberry Pi ist auf jeden Fall einen Blick wert. Wer seine Daten nicht ungeschützt den großen Hyperscalern in die Cloud blasen möchte, findet hier eine fantastische Alternative. Im Sinne der digitalen Souveränität ist diese Lösung für kleinere, alltägliche Aufgaben auf jeden Fall hervorragend geeignet.

Der Beitrag Urlaub mit dem Lama erschien zuerst auf intux.de.

Neben dem CLI-Paketmanager Pacman bietet Arch Linux mit Octopi und Pamac auch grafische Alternativen. Seit einigen Monaten macht Shelly als moderne grafische Alternative von sich reden.

Die Linux Foundation reagiert mit der Akrites Initiative auf wachsende Risiken für offene Software. KI findet Schwachstellen heute so schnell, dass klassische Sicherheitsprozesse kaum mithalten. Die Beteiligten warnen, dass moderne Modelle Lücken in Minuten aufspüren. Früher dauerte das oft viele Wochen. Diese Entwicklung trifft Bereiche wie Energie, Verkehr, Gesundheit und Finanzdienste. Gleichzeitig sinkt die Hürde […]

Der Beitrag Akrites Initiative: Neue Allianz will Open‑Source‑Sicherheit stärken erschien zuerst auf fosstopia.

Dieser Artikel richtet sich an jene, die sich für das Thema Kernel Live Patching (KLP) interessieren.

Im ersten Teil des Artikels stelle ich dar, wann KLP in meinen Augen keine gute Lösung darstellt und man auf den Einsatz nach Möglichkeit verzichten sollte. Wissend, dass es manchmal nicht anders geht, beschreibe ich im zweiten Teil am Beispiel von RHEL 9, wie KLP eingerichtet und genutzt werden kann.

Transparenzhinweis: Ich arbeite als Technical Account Manager (TAM) für die Firma Red Hat, welche die Distribution Red Hat Enterprise Linux (RHEL) herausgibt. Dieser Artikel spiegelt meine persönliche Meinung wider, welche mit der meines Arbeitgebers übereinstimmen kann, dies jedoch nicht in jedem Fall muss.

Der Userspace wird in diesem Artikel ausgeklammert, um den Umfang nicht zu sprengen. Ich werde diesen in einem folgenden Artikel aufgreifen.

Warum bzw. wann man Kernel Live Patching nicht nutzen sollte

Folgende Gründe sollten nicht zur Nutzung von KLP führen, sondern auf andere Weise adressiert werden:

• Angst vor dem Serverneustart
• Eine Softwarearchitektur, die Serverneustarts nicht vorsieht/zulässt
• Ungeklärte Abhängigkeiten in vernetzten Systemen
• Der Glaube, mit KLP nie wieder neustarten zu müssen

Angst ist in der IT ein ganz schlechter Ratgeber. Hier sollte unbedingt die Ursache und nicht das Symptom behandelt werden. Denn Serverneustarts können auch noch aus folgenden Gründen passieren bzw. notwendig werden:

• Der Server verliert vorübergehend die Stromversorgung
• Eine Kernel Panic bringt das System zum Absturz
• Ein nicht mehr reagierendes System muss durch einen Reset neugestartet werden
• Umzug der Hardware an einen neuen Standort

Dies sind nur vier Gründe, die mir sofort in den Sinn kommen. Wenn wir länger darüber nachdenken, fallen uns bestimmt noch viele weitere ein (ergänzt diese gern in den Kommentaren). Wichtig ist zu verstehen, dass Serverneustarts aus verschiedenen Gründen passieren und per se nicht schlimm sind.

Wenn die Softwarearchitektur keine Neustarts einzelner Komponenten zulässt, hat man ein ganz anderes Problem, welches dringend adressiert werden sollte. Soetwas wie 100%-tige Verfügbarkeit gibt es nicht. Hier ist in meinen Augen zu klären, ob es wirklich an der Anwendung oder eher an nicht verhandelten Wartungsfenstern liegt. KLP ist hier keine Lösung, da die Häufigkeit von Neustarts nur reduziert bzw. das Problem in die Zukunft verschoben wird.

Viele Sysadmins sind faul und das ist gut so. Motiviert es diese Personengruppe doch, manuelle Tätigkeiten zu automatisieren und sich die Arbeit zu erleichtern. Diese Faulheit darf allerdings nicht dazu führen, dass man sich vor der Analyse komplexer und vernetzter Systeme drückt. Abhängigkeiten können analysiert und in den meisten Fällen aufgelöst werden. Sind sie bekannt, kann man sie im Patchprozess berücksichtigen und den Vorgang inkl. Neustarts automatisieren. Auch in diesem Fall verzögert KLP das Unvermeidliche nur.

Kernel Live Patching kümmert sich, wie der Name schon sagt, nur um den Kernel. Was ist mit dem Userspace? Auch hier gibt es sicherheitskritische Bibliotheken und Anwendungen, wie z.B. openssl, gnutls oder die glibc, welche bei erkannten Schwachstellen zeitnah abgesichert werden müssen, um die Sicherheit des Systems nicht zu gefährden.

Neustarts sind per se nicht schlecht. Wer seine Server regelmäßig neustartet, gewinnt Vertrauen, dass diese auch wieder hochfahren und ihre Dienste korrekt erbringen. Schlummernde Probleme werden schneller erkannt und türmen sich nicht zu einem Störfall auf, der nur darauf wartet, im ungünstigsten Moment zu passieren. Und im Optimalfall sind die Dienste so entworfen worden, dass der Ausfall/Neustart eines einzelnen Servers nicht automatisch zu einer Nichtverfügbarkeit des Dienstes führt.

Ich möchte mein Plädoyer für Serverneustarts an dieser Stelle beenden und mich zwei Szenarios zuwenden, in denen KLP die Schmerzen des IT-Betriebs lindern kann.

Wann Kernel Live Patching Sinn macht

Für besonders geschäftskritische IT-Dienste existieren häufig Service-Level-Agreements (SLA), die eine sehr hohe Verfügbarkeit garantieren. Verstöße gegen diese SLA werden von den Stakeholdern meist nicht toleriert und sind in manchen Fällen mit Vertragsstrafen belegt. Zwar gilt auch hier, dass das Problem eher in der Softwarearchitektur liegt, doch hilft dies den Sysadmins nicht, die mit dem Betrieb beauftragt sind. Sie müssen irgendwie damit umgehen, bis eine bessere Lösung gefunden wird. Hier kann KLP eine Notlösung sein, um Sicherheitsrisiken im Betrieb zu reduzieren und SLA-Verstöße zu vermeiden.

Angelehnt an die SLA spielt die Zeit, die ein Server für einen Neustart benötigt, eine Rolle. Während die meisten VMs in Sekunden oder 1-2 Minuten neustarten, dauert dieser Vorgang bei Hardwareservern manchmal deutlich länger. Im Feld werden hier vereinzelt Zeiten zwischen 10-20 Minuten beobachtet (pro Server). Müssen mehrere Server für einen IT-Dienst sequentiell neugestartet werden, summieren sich die Zeiten schnell auf und machen größere Wartungsfenster erforderlich. KLP kann helfen, die Anzahl der langen Wartungsfenster zu reduzieren.

Es gibt Systeme, für deren Start ein manueller Eingriff durch Sysadmins notwendig ist. Dies kann z.B. die Eingabe eines BIOS-, Grub-, LUKS- oder UEFI-Passworts sein. Dies ist aufwändig und lästig, lässt sich aber leider nicht in allen Fällen wegautomatisieren. Auch hier erscheint es legitim, die Anzahl der manuellen Eingriffe durch den Einsatz von KLP zu minimieren.

Kernel Live Patching für RHEL 9 konfigurieren

Um mich für die Konfiguration vorzubereiten, habe ich folgende drei Quellen studiert:

• Chapter 9. Applying patches with kernel live patching
• Kernel Live Patch Support Cadence Update (Login erforderlich)
• Kernel Live Patch life cycles (Login erforderlich)

Die wichtigsten Erkenntnisse daraus sind für mich:

• Nicht jeder RHEL-Kernel erhält Live-Patches
• An jedem 1. März, Juni, September und Dezember (jedes Quartal) wird für jedes unterstützte RHEL-Release ein Kernel festgelegt, welcher Live-Patches erhält
• Für jeden dieser Kernel verspricht Red Hat bis zu einem Jahr lang Updates für CVEs, die nach Red Hats Ermessen als critical oder important kategorisiert wurden (siehe Severity Ratings)

Dass Red Hat für ausgewählte Kernel-Releases ein Jahr lang Live-Patches bereitstellt, lässt nicht den Schluss zu, nur noch einmal pro Jahr neustarten zu müssen. Denn:

• CVEs der Kategorien moderate und low werden gar nicht adressiert
• Man erhält keinerlei Bugfixes und keinerlei Produktverbesserungen (Red Hat Enhancement Advisories (RHEA))

Die Planung eines Neustarts wird jedoch ggf. vereinfacht.

Konfiguration von Kernel Live Patching für ein Labor-System

Ich habe ein Labor-System mit RHEL 9 auserkoren, welches als Hypervisor für einige Libvirt/KVM-VMs genutzt wird.

Dieses läuft aktuell mit dem Kernel 5.14.0-687.15.1.el9_8.x86_64, welcher laut Kernel Live Patch life cycles kein Kernel ist, für den KLP angeboten wird. Es ist also zuerst der kernel-5.14.0-687.10.1 zu installieren. Anschließend folge ich der Dokumentation, um den Live-Patch-Stream für diesen Kernel zu aktivieren (siehe folgender Codeblock).

~]$ sudo dnf search kernel-5.14.0-687.10.1.el9_8
Updating Subscription Management repositories.
Last metadata expiration check: 0:04:34 ago on Tue 23 Jun 2026 11:31:09 AM CEST.
================ Summary Matched: kernel-5.14.0-687.10.1.el9_8 ================
kpatch-patch-5_14_0-687_10_1.x86_64 : Initial empty kpatch-patch for
                                    : kernel-5.14.0-687.10.1.el9_8.x86_64
~]$ sudo dnf install kpatch-patch-5_14_0-687_10_1.x86_64

Wie im obigen Codeblock zu sehen, handelt es sich dabei um den initialen und leeren kpatch-patch. Das System hat also noch keinen Fix erhalten, sondern ist lediglich darauf vorbereitet.

Im jetzigen Zustand würde DNF das System bei einem Update jedoch auf die letzte verfügbare Kernelversion aktualisieren, welche keine Live-Patches erhält. Da dies von mir nicht gewünscht ist, aktiviere ich einen Filter, der zukünftig nur noch KLP-fähige Kernel anzeigt. Der folgende Codeblock zeigt den Zustand vor der Aktivierung des Filters, die Aktivierung selbst und den Zustand danach.

~]$ sudo dnf kpatch status
Updating Subscription Management repositories.
Last metadata expiration check: 0:04:36 ago on Tue 23 Jun 2026 11:43:44 AM CEST.
Kpatch update setting: auto-update
Kpatch filter setting: no-filter
Dependencies resolved.
Nothing to do.
Complete!

~]$ sudo dnf kpatch auto-filter
Updating Subscription Management repositories.
Kpatch filter setting: auto-filter

~]$ sudo dnf kpatch status
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Kpatch update setting: auto-update
Kpatch filter setting: auto-filter
Dependencies resolved.
Nothing to do.
Complete!

Zum Abschluss ein Neustart und mein System läuft mit dem richtigen Kernel 5.14.0-687.10.1.el9_8.x86_64.

Aufräumarbeiten

Aktuell sind auf meinem System noch Kernel-Pakete installiert, die für KLP nicht vorgesehen sind, aber bei einem dnf update aktualisiert werden würden:

~]# dnf list --installed kernel*
Updating Subscription Management repositories.
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Installed Packages
kernel.x86_64              5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel.x86_64              5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel.x86_64              5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64         5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64         5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64         5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-devel.x86_64        5.14.0-611.38.1.el9_7 @rhel-9-for-x86_64-appstream-rpms
kernel-devel.x86_64        5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-appstream-rpms
kernel-devel.x86_64        5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-appstream-rpms
kernel-headers.x86_64      5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-appstream-rpms
kernel-modules.x86_64      5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel-modules.x86_64      5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-modules.x86_64      5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64 5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64 5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64 5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-tools.x86_64        5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-tools-libs.x86_64   5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms

Um aufzuräumen, habe ich alle überflüssigen Pakte entfernt, bis nur noch der KLP-fähige Kernel vorhanden ist:

~]# dnf list --installed kernel*
Updating Subscription Management repositories.
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Installed Packages
kernel.x86_64                5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64           5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms
kernel-modules.x86_64        5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64   5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms

Verhalten bei zukünftigen Updates

Durch den konfigurierten kpatch-Filter werden bei zukünftigen Updates nur Kernel aufgeführt, die KLP-fähig sind. Wird ein KLP veröffentlicht, erscheint dieser als kpatch-patch in der Ausgabe von dnf up`. Der folgende (gekürzte) Codeblock zeigt dies beispielhaft.

~]# dnf up
Updating Subscription Management repositories.
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Dependencies resolved.
===================================================================================
 Package       Arch   Version               Repository                        Size
===================================================================================
Upgrading:
…
kpatch-patch-5_14_0-687_10_1 x86_64 1-1.el9_8 rhel-9-for-x86_64-baseos-rpms   22 k
…

Mit dem Befehl aus dem nächsten Codeblock kann kontrolliert werden, welche KLP aktuell installiert sind und welche CVEs sie adressieren.

~]# kpatch list
Loaded patch modules:
kpatch_5_14_0_687_10_1_1_1 [enabled]
	CVE-2026-43037

Installed patch modules:
kpatch_5_14_0_687_10_1_1_1 (5.14.0-687.10.1.el9_8.x86_64)

Obige Ausgabe bestätigt, dass ein KLP aktiv ist, der die kritische Schwachstelle CVE-2026-43037 schließt.

Fazit

KLP funktioniert und ist einfach einzurichten. Es ist nicht in jedem Fall die richtige Lösung und löst nicht alle Probleme, kann jedoch in manchen Fällen die Schmerzen im IT-Betrieb lindern.

Der Userspace wurde ausgeklammert, um den Umfang dieses Artikels nicht zu sprengen. Dies hebe ich mir für einen folgenden Artikel auf.

Die MZLA Technologies Corporation hat mit Thunderbird 20 ein Update für die Android-Version seines E-Mail-Clients veröffentlicht.

Download Thunderbird für Android

Die MZLA Technologies Corporation hat Thunderbird 20 für Android veröffentlicht und bringt damit eine Reihe von kleineren Verbesserungen und Fehlerbehebungen.

Der Beitrag Thunderbird 20 für Android veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mit Common Voice stellt Mozilla den weltweit größten öffentlichen Datensatz menschlicher Stimmen bereit – kostenlos und für jeden nutzbar. Mozilla hat Version 26 seines Datensatzes veröffentlicht.

Der Markt für Spracherkennung wird von den ganz großen Namen kommerzieller Anbieter dominiert: Amazon, Apple, Google, Microsoft. Darum hat Mozilla im Jahr 2017 das Projekt Common Voice gestartet. Mit Common Voice bietet Mozilla eine kostenlose Alternative an, zu der jeder beitragen kann und die jedem zur Verfügung steht. Damit möchte Mozilla Innovation und Wettbewerb in der Sprachtechnologie auf Basis von Maschinenlernen fördern.

Mozilla Common Voice 26

Der nun veröffentlichte Datensatz Common Voice Scripted Speech 26 beinhaltet für die deutsche Sprache 1.490 Stunden an Daten und ist 34,77 GB groß. In Summe waren 20.529 Menschen am deutschsprachigen Datensatz beteiligt. Der Datensatz Common Voice Spontaneous Speech 4 für spontane Sprache kommt für Deutsch auf 1,2 Stunden an Daten und ist 33,36 MB groß, beigetragen von 28 Personen.

Insgesamt deckt Mozilla Common Voice mit der neuen Version, die wieder Unterstützung für vier neue Sprachen bringt, 294 Sprachen mit insgesamt 42.893 aufgenommenen Stunden ab, was Mozilla Common Voice zum vielfältigsten mehrsprachigen Sprachkorpus der Welt macht. Die Anzahl der unterstützten Sprachen für spontane Sprache ist von 72 auf 78 Sprachen gewachsen.

Zum Download der Mozilla Common Voice Datensätze
Zu Mozilla Common Voice beitragen

Der Beitrag Mozilla veröffentlicht Common Voice 26 erschien zuerst auf soeren-hentzschel.at.

Solo ist ein Website-Builder von Mozilla. Nun steht Solo 2.3 bereit.

Jetzt Website-Builder Solo von Mozilla testen

Die Neuerungen von Solo 2.3

Mozilla hat den Prozess, eine neue Domain zu kaufen, überarbeitet. Bezahlte Pläne beinhalten ab sofort bereits eine kostenlose Domain. Und die Domain-Verwaltung inklusive der DNS-Records und Verlängerungen ist jetzt über das Account-Menü zugänglich.

Websites können nun automatisch bei Bing indiziert werden, um die Sichtbarkeit in den Suchergebnissen zu verbessern.

Neue Layout-Optionen für den Header unterstützen mehr Navigationslinks, zentrierte Logos und größere Logo-Grafiken.

Das Duplizieren von Seiten wurde in den Seiteneinstellungen hinzugefügt. Außerdem können jetzt auch Abschnitte dupliziert oder auf andere Seiten verschoben werden.

Im Blog gibt es nun eine Auswahl für das Datumsformat und im Bereich „Bewertungen” sind Sterne-Bewertungen möglich.

Die Ladegeschwindigkeit veröffentlichter Websites wurde verbessert und es gab diverse Fehlerkorrekturen und Verbesserungen unter der Haube.

Außerdem wurde ein Partnerprogramm gestartet, worüber man Prämien durch das Anwerben neuer Solo-Kunden verdienen kann.

Der Beitrag Website-Builder: Mozilla bringt Solo 2.3 erschien zuerst auf soeren-hentzschel.at.

Nach dem Exportverbot für Anthropics Spitzenmodelle Mythos 5 und Fable 5 weist die US-Regierung nun auch den Konkurrenten OpenAI an, sein neuestes Modell ChatGPT-5.6 vorerst nur handverlesenen…

Der Linux-Anbieter Suse und das spanische Unternehmen Openchip & Software Technologies haben eine Absichtserklärung zur Entwicklung eines europäischen Technologie-Stacks unterzeichnet.

Manche Wissenschaftler glaubten nicht mehr daran, dass sich der Trend zu immer weiterer Verkleinerung der Bauelemente auf Computerchips noch länger aufrechterhalten ließe.

Speech-to-Text ist ein wichtiger Teil von Spracherkennung, besonders wenn es um Barrierefreiheit geht. Canonical will mit Ubuntu 26.10 eine lokale Implementierung ausliefern.

Brave hat mit Brave Origin einen interessanten Browser im Angebot, der auf überflüssige Extras verzichtet und sich klar auf Privatsphäre und Geschwindigkeit konzentriert. Linux‑Nutzer können ihn kostenlos verwenden und sofort starten. Wer macOS oder Windows nutzt, wird jedoch mit einmalig 59,99 $ zur Kasse gebeten. Origin entfernt viele Zusatzfunktionen des normalen Brave Browsers. Dazu zählen […]

Der Beitrag Brave Origin zeigt sich als schlanker Browser ohne Ballast erschien zuerst auf fosstopia.