Bereits seit neun Monaten ist Arch Linux dabei, die i686-Architektur langsam zurückzufahren. Mit dem heutigen 8. November endet nun die Unterstützung für die 32-Bit-Architektur, die bei Entwicklern und Anwendern immer weniger Verwendung findet. Dies teilte die Distribution in den News mit. Arch Linux ist damit nicht alleine, andere Distributionen haben bereits die Unterstützung für 32-Bit ganz oder teilweise eingestellt.
Ein Fork hält i686 am Leben
Für die Anwender bedeutet dies, dass bis zum Ende November Pakete mit i686-Architektur von den Spiegelservern entfernt werden. Später verschwinden sie auch aus dem Paket-Archiv. Das Repository multilib ist davon nicht betroffen. Anwender, die nicht in der Lage sind, auf ihrer Hardware x86_64-Software auszuführen können auf den Community-Fork Arch Linux 32 ausweichen, der zu diesem Zweck erstellt wurde. Die Arch-Linux-Entwickler hatten angesichts der Tatsache, dass es noch Nachfragenach der Plattform gibt, die Community ermuntert, diesen Fork mithilfe der Mutter-Distribution ins Leben zu rufen.
Wechsel ohne große Hürden
Auf deren Webseite findet sich unter dem Menüpunkt Download im Kapitel Transition from the Official Repositories eine Anleitung wie der Wechsel von den offiziellen Repositories auf die des Forks vonstattengeht. Dazu muss lediglich ein passender Spiegelserver eingetragen, ein von einem Arch-Linux-Entwickler signierter Schlüssel installiert und der Wechsel mit pacman -Syuu angestoßen werden. Dabei werden einige Pakete de-aktualisiert, da sie in den offiziellen Repositories in aktuellerer Version vorliegen. Spiegelserver stehen derzeit in Deutschland, USA, Canada und Frankreich bereit.
Anwender, die eine neue Installation wünschen, finden auf der gleichen Seite Downloadlinks für BitTorrent oder direkte Downloads per HTTP. Ein GitHub-Repository enthält die Werkzeuge für die Abbilder und die Webseite. Hilfe wird über eine Mailing-Liste oder live im IRC im Kanal #archlinux-ports auf dem Freenode-Server angeboten.
Jeder moderne Intel-Prozessor bringt eine Management Engine (IME) mit, die beim Booten, zur Laufzeit und im Schlafmodus aktiv ist. Da IME über die permanente 5-V-Versorgung aus dem Netzteil gespeist wird, muss der Rechner nicht einmal eingeschaltet sein. Sie besteht aus einem Microcontroller und einer passenden proprietären Firmware, die sich je nach CPU und OEM unterscheiden kann. Die Firmware ist eine von Intel kryptografisch signierte Binärdatei. ME ist von Intel nicht durchgängig dokumentiert. Somit führt die CPU im Rahmen der ME unbekannten und nicht nachprüfbaren Code aus, auf die der Käufer von Intels CPUs keinerlei Einfluss hat. Betroffen sind die Intel-Core-i-Serien i3, i5, i7 und die Intel Xeon Prozessorfamilien.
Sicherheitstechnisch bedenklich
In frühen Versionen saß der Microcontroller im Netzwerkchip, dann in der Northbridge des Chipsatzes, um bei Intels i7-Architektur Teil der CPU zu werden. Der Controller der ME ist dabei völlig unabhängig von der CPU und stellt einen Computer im Computer dar. Die ME hat ihr eigenes Betriebssystem und verfügt über Flashspeicher, einen internen Bus, einen Web-Server und eine Kryptographie-Engine. ME hat Zugriff auf den Hauptspeicher des Systems und über den Intel Gigabit Ethernet Controller auch auf das Netzwerk. Die FSF bemängelt, dass Anwender keinerlei Kontrolle über die Management Engine haben. Wäre dies, wie bei freier Software der Fall, wäre sie ein mächtiges Subsystem, das zur Sicherheit und Administration des Systems beitragen könnte.
Soviel war bereits seit längerem bekannt. Bekannt war auch, dass IME ein großes Sicherheitsrisiko darstellt. Nicht nur die Free Software Foundation (FSF) hat sich gegen dieses zusätzliche proprietäre Sub-Betriebssystem gewandt, sondern auch die Electronic Frontier Foundation (EFF) und Sicherheitsexperten wie Matthew Garrett. Erst im Mai hatte Intel eine seit neun Jahren bestehende kritische Sicherheitslücke in seiner Active Management Technology (AMT), einer der Komponenten der IME, bekannt gegeben. Da das Schließen dieser Lücke eines Firmware-Updates bedarf, werden viele PCs, bei denen AMT aktiv ist, vermutlich nie einen Fix sehen. Ob AMT passiv oder aktiv eingeschaltet oder aus ist, hängt vom BIOS des jeweiligen Rechners ab.
Minix entdeckt
In letzter Zeit beschäftigte sich ein Team von Google-Sicherheitsexperten mit der IME. Dabei entdeckten sie zu ihrem Erstaunen, dass das versteckte Betriebssystem, das die ME steuert, auf den Namen Minix hört. Dabei handelt es sich um ein frühes unixoides Betriebssystem, das von Andrew S. Tanenbaum 1987 zu Lehrzwecken entwickelt wurde. Seine größte Bedeutung heute ist vermutlich, dass es Linus Torvalds zur Entwicklung von Linux inspirierte. Dank Googles Ronald Minnich wissen wir nun, dass Minix dank Intel das am weitesten verbreitete Unix und möglicherweise sogar das am weitesten »benutzte« Betriebssystem überhaupt ist.
Das enthüllte Minnich vor zwei Wochen auf einem Vortrag auf der Embedded Linux Conference Europe in Prag. Dabei handelt es sich um eine proprietäre Variante von Minix 3. Welche Änderungen hier vorgenommen wurden ist dank des Closed-Source-Status bisher nicht bekannt. Das System hat Zugriff auf die TCP/IP-Netzwerk-Schicht, das Dateisystem, auf Treiber und Web-Server. Es kann zudem die Firmware des Rechners selbst im ausgeschalteten Zustand ändern. Auch kann es selbst-modifizierenden Code einfügen, der selbst in einem stromlosen Rechner erhalten bleibt.
Auf unterster Ebene
Das IME erlangt diesen Zugriff dadurch, dass es im x86-Ring-Modell im niedrigsten Ring -3 läuft und somit noch eine Ebene unter UEFI angesiedelt ist. Um hier mehr Sicherheit zu ermöglichen ruft Minnich Intel dazu auf, anstelle seines proprietären Minix-Derivats ein offenes Linux-System einzusetzen. Im Besonderen sollten zudem der Web-Server und der IP-Stack aus der ME verschwinden. Auch AMD ist keine sichere Bank in dieser Hinsicht. Die neuen Ryzen-Chips enthalten mit dem AMD Platform Security Process ebenfalls »ein schwarzes Loch«. Minnich machte eindrücklich klar, dass er es Ernst meint, wenn er sagte: »Wenn ihr jetzt noch keine Angst habt, dann hab ich das schlecht erklärt. Ich jedenfalls habe Angst.«
Erst kürzlich konnten die Entwickler bei Purism, die auch das freie Smartphone Librem 5 entwickeln, vermelden, dass es ihnen gelungen sei, die IME völlig zu deaktivieren. Wie im hauseigenen Blog nachzulesen ist, hat es Jahre gedauert, bis eine vollständige Lösung gefunden war, die den Start des Systems auf den Notebooks Librem 13 und Librem 15 ohne aktivierte Management Engine erlaubt.
Inzwischen hat sich Andew Tanenbaum, völlig unreflektiert die Tatsache ignorierend, das Minix als Backdoor eingesetzt wird, bei Intel für die Verwendung von Minix bedankt.
Bild: Hacker by The Preiser Project | Flickr | License: CC-BY 2.0
Auf der LibreOffice-Konferenz 2017 in Rom Mitte Oktober war bereits angekündigt worden worauf Anwender von LibreOffice unter KDE Plasma 5 bereits gewartet haben: Ein Plugin, um LibreOffice optisch an die fünfte Ausgabe des Plasma-Desktop anzupassen. Das bestehende Plugin basiert derzeit noch auf Qt4 und wurde in Debian und vermutlich auch andernorts aus diesem Grund bereits entfernt. Viele Anwender beschwerten sich über fehlerhafte Darstellung, wobei mit dem Qt4-Plugin die Tooltips weiß auf weißen Grund dargestellt wurden.
Stadt München an der Entwicklung beteiligt
Die Entwicklerin Katarina Behrens von CIB erzählte in ihrem Vortrag auf der Konferenz, das Plugin werde auch von der Stadt München unterstützt, die zumindest auf absehbare Zeit weiter LibreOffice einsetzen wird. So ist der bei der Stadt München angestellte Entwickler Jan-Marek Glogowski maßgeblich an der Entwicklung beteiligt.
Heute im Git Master eingecheckt
Nun ist es also soweit. Eine erste Version des Plugins, basierend auf dem LibreOffice Visual Component Library (VCL) wurde heute im Git-Master-Zweig des LibreOffice-Repository eingefügt. Noch ist das Plugin in einem sehr frühen Stadium, könnte aber bereits für LibreOffice 6.0, das im Januar oder Februar veröffentlicht werden soll, einsatzbereit sein. Es stellt Unterstützung für Qt5-Zeichenfunktionen und das Mouse-Handling bereit. Zudem soll der Plasma5 Öffnen- und Speichern-Dialog unterstützt werden, wie er etwa im Dateimanager Dolphin zu finden ist.
Ubos ist eine kleine Linux-Distribution, die es auch technisch weniger bedarften Zeitgenossen erlaubt, Daten im Netz unter eigener Kontrolle vorzuhalten. Dazu ermöglicht Ubos den Betrieb von verschiedenen Web-Diensten auf eigener Hardware, wobei ein PC, ein Raspberry Pi oder ähnliches, ein Container oder auf Wunsch die Amazon-Cloud die Daten aufnehmen können. Ubos basiert auf Arch-Linux, das es nach Aussagen des Entwicklers einfach macht, ein für seine Zwecke maßgeschneidertes System zu entwerfen.
Ein Befehl reicht aus
Ubos vereinfacht das Aufsetzen diverser Web-Dienste, indem es den Installationsprozess und die Grundkonfiguration hinter einfachen Befehlen versteckt. So leitet der Befehl # ubos-admin createsite das Aufsetzen eines Dienstes ein. Die Zahl der installierten Dienste wird lediglich von der Hardware beschränkt. Derzeit lassen sich auf diese Weise unter anderem Nextcloud, WordPress, MediaWiki, Mattermost, Selfoss, Known und Webtrees aufsetzen.
Behutsame Entwicklung
Die kürzlich veröffentlichte Version Ubos 12 zeigt das Projekt noch in der Beta-Phase. Die neue Version trennt OS-Updates von App-Updates, sodass es nun einfacher ist, einzelne Komponenten zu aktualisieren. Ansonsten konzentriert sich Ubos 12 hauptsächlich auf die Verbesserung des Build-Prozesses und ermöglicht Entwicklern ein einfacheres Paketieren ihrer Applikationen für Ubos.
Auch als Router einsetzbar
Das Image für den Minirechner Marvell EspressoBin ist nun als Router mit Firewall vorkonfiguriert. Zudem kann der kleine Rechner, einmal eingerichtet, ohne SD-Karte von der Festplatte starten. Datenbanken können mit Ubos 12 jetzt individuell benannt werden. Darüber hinaus enthält Ubos jetzt die nötigen Pakete zum Ansprechen der optionalen Kamera des Raspberry Pi.
Ich hatte bereits 2015 und 2017 ausführliche Grundlagenartikel zu Ubos im Print-Magazin Raspberry Pi Geek veröffentlicht, die das Thema bei Bedarf vertiefen. Images für Ubos liegen derzeit für Raspberry Pi, Marvell EspressoBin uns x86-PCs auf der Downloadseite vor. An gleicher Stelle finden sich Anleitungen um Ubos auf den Amazon Web Services (AWS) oder in einem Container laufen zu lasssen.
Der KDE-Partitionsmanager wird künftig keine Root-Rechte mehr benötigen um Partitionen zu erstellen und zu formatieren. Das erklärte KDE-Entwickler Andrius Štikonas in seinem Blog. Demnach laufen mittlerweile rund 90 Prozent der Funktionalität mit unprivilegierten Anwenderrechten. Das bedeutet laut Štikonas unter anderem mehr Sicherheit und bessere Wayland-Integration. Es wird noch eine Weile dauern, bis alles poliert und fertig für eine Veröffentlichung ist. Der Entwickler betrachtet das Erreichte jedoch bereits jetzt als Meilenstein in der Entwicklung des KDE Partition Managers.
Sfdisk löst langfristig Libparted ab
Anders als die meisten anderen Anwendungen, die KAuth zur Autorisierung benutzen, brauchte der KDE-Partitionsmanager Root für fast jede Funktion in seinem Repertoire. So war es ein nicht unerheblicher Aufwand, den Code der Anwendung entsprechend umzuschreiben. Zum Gelingen trug auch bei, dass jetzt ein zweites Backend zur Verfügung steht. Bisher wurden die meisten Manipulationen an Partitionen von libparted erledigt, einer Bibliothek, die auch bei GNU Parted, QtParted und dem GTK-Gegenstück GParted den Löwenanteil der Arbeit erledigt.
Der KDE-Partitionsmanager kann jetzt auch sfdisk aus den Util-Linux-Paket als Backend verwenden. Das hat den Vorteil, dass sfdisk den Betrieb ohne Root-Rechte von Hause aus unterstützt. So wird sfdisk künftig das primäre Backend für KDEs Partitionierer werden.
Auch Calamares profitiert
Derzeit liegt der Quellcode des Umbaus zum unprivilegierten Betrieb des KDE Partition Manager noch im Repository des Entwicklers, soll jedoch nach Git-Master migrieren sobald das Herzstück KPMcore in Version 3.3 veröffentlicht wurde. Künftig werden nicht nur Anwender von KDE vom neuen Operationsmodus ohne Root beim KDE-Partitionsmanager profitieren, sondern auch die Anwender des Qt-basierten Installer-Frameworks Calamares, das ebenfalls auf dem KDE-Partitionierer setzt.
Zehn Tage vor der Veröffentlichung von Firefox 57 Quantum stellt Mozilla seine frisch überarbeitete Webseite für Erweiterungen vor. Diese offizielle Repository beherbergt die überwiegende Zahl an verfügbaren Add-ons für Firefox für den Desktop und für mobile Plattformen. Die Eingangsseite weist eine Unterteilung in Entdecken, Erweiterungen, Themes und Mehr… auf. Voreingestellt ist der Menüpunkt Entdecken. Übersichtlich werden hier verschiedene Add-on- und Theme-Kategorien vorgestellt. Klickt man auf eine Unterkategorie oder ein einzelnes Add-on, enthüllt die Seite Einzelheiten zum gewählten Objekt. Der Menüpunkt Entdecken wird auch angesprungen wenn im Browser im Erweiterungsmanager bei den Legacy Extensions, also den veralteten Erweiterungen auf Finde einen Ersatz geklickt wird.
Übersichtlicher Neubeginn
Ein Suchfeld oben rechts erlaubt die manuelle Suche nach Add-ons oder Themen. Damit können Anwender recht schnell feststellen, ob Firefox 57 die Erweiterung noch unterstützt. Ist dies nicht der Fall, weist ein roter Balken mit entsprechendem Text darauf hin. Das gilt etwa für das beliebte Add-on Tab Mix Plus. Ein Klick auf Erweiterungen zeigt wiederum eine weitere Unterteilung in Kategorien, die ihrerseits, wenn geöffnet weiter diversifizieren. Über die Suchfunktion kann nach verschiedenen Suchkriterien über drei Dropdown-Menüs die Auswahl eingeschränkt werden. Es besteht unter anderem die Möglichkeit der Sortierung nach Betriebssystem, Erweiterung oder Theme sowie nach Relevanz, Bewertung und Beliebtheit.
Firefox ESR verlängert die Gnadenfrist
Die Renovierung der Seite, die auch unter der Bezeichnung AMO läuft, geht Hand in Hand mit der Veröffentlichung von Firefox 57, der einen vorläufigen Höhepunkt der Runderneuerung des Browsers bildet. Mit Firefox 57 werden erstmal die sogenannten Legacy Add-ons nicht mehr geladen. Zugelassen sind nur noch Add-ons, die auf den WebExtensions-APIs basieren. Anwender, die ein Legacy-Add-on weiter nutzen möchten, können sich mit Firefox ESR eine Gnadenfrist einrichten.
Nachdem Nextcloud, eine Webanwendung zum Filehosting auf einem eigenen Server mit Version 12 die OAuth2-Autorisierung eingeführt hat, bietet nun auch der gleichgelagerte Webdienst ownCloud dieses zusätzliche Sicherheitsmerkmal. Der offene Industriestandard OAuth2 steht ab sofort für alle ownCloud-User zur Verfügung. OAuth2 sorgt für einen sicheren und erleichterten Anmeldeprozess für ownCloud-Clients sowie eine deutliche Erhöhung der Sicherheit bei der Einbindung von ownCloud in Third-Party-Applikationen und Web-Dienste. Durch die Integration müssen künftig keine Passwörter mehr in ownCloud-Desktop-Clients oder ownCloud-Mobile-Apps für iOS und Android gespeichert, sondern nur im automatisch gestarteten Web Browser eingegeben werden.
Server stellt Access-Token aus
Der zugehörige Client erhält anschließend einen einmaligen Access-Token, der in Verbindung mit dem OAuth2-Protokoll den Login ermöglicht. Das Protokoll wird für alle zukünftigen Verbindungen mit dem ownCloud-Server eingesetzt. Sowohl die ownCloud- Clients, als auch verwendete Third-Party-Webapplikationen gelangen dabei aber nie an die tatsächlichen Login-Daten.
Bild: ownCloud
Die 4 Rollen der OAuth2-Autorisierung
OAuth steht für Open Authorization und ist ein offenes Protokoll, das eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Anwendungen erlaubt. Für OAuth2 existieren vier Rollen, die Wikipedia folgendermaßen beschreibt:
Resource Owner: Eine Entität, welche den Zugriff auf eine geschützte Ressource gewähren kann. Ist der Resource Owner eine Person, wird dieser als User bezeichnet.
Resource Server: Der Server, auf welchem die geschützte Ressourcen (Protected Resources) liegen. Er ist in der Lage, auf Basis von Access Tokens, darauf Zugriff zu gewähren. Dieser Token repräsentiert die delegierte Autorisierung des Resource Owners.
Client: Eine Anwendung, welche mit Hilfe des Resource Owner auf geschützte Ressourcen zugreifen möchte. Der Client kann auf einem Server (Web Anwendung), Desktop PC, mobilen Gerät etc. ausgeführt werden.
Authorization Server: Der Server authentisiert den Resource Owner und stellt Access Tokens für den vom Resource Owner erlaubten Anwendungsbereich (Scope) aus.
Das Projekt ownCloud wurde im Januar 2010 von KDE-Entwickler Frank Karlitschek ins Leben gerufen, um eine freie Alternative zu kommerziellen Cloud-Diensten zu schaffen. Im Mai 2016 trennte sich Karlitschek wegen Meinungsverschiedenheiten von ownCloud und rief Nextcloud ins Leben. Seitdem bewegen sich beide Projekte auseinander, was die Zusatzfunktionalitäten betrifft.
Jetzt mal von vorne: LineageOS ist ein Fork von CyanogenMod, das selbst eine Alternative zu Android war. Nachdem die ausgegründete Firma Cyanogen wegen Geschäftsuntüchtigkeit und zu großer Egos gegen die Wand gefahren worden war, entstand LineageOS auf der Basis des Codes von CyanogenMod. Nun wurde LineageOS von Entwicklern des Projekts microG geforked, um die proprietären Google Apps und Bibliotheken (GApps), die Android mitbringt, als Open Source zu implementieren. Dabei werden die Binärpakete der GApps gegen Apps und Bibliotheken mit gleichem oder ähnlichem Verhalten, aber mit freiem Code ersetzt. Die Open-Source-Apps sollen dabei platzsparend und ressourcenschonender zu Werke gehen als die proprietären Gegenstücke. Der Fork hört auf den Namen LineageOS for microG.
Sicher oder nicht?
Da taucht natürlich die Frage auf, warum das als Fork realisiert wird und nicht innerhalb von LineageOS. Die Entwickler von LineageOS lehnen die Implementierung ab, da ein Patch zum signature spoofing nötig ist, um die freien Apps dem System gegenüber als Google Apps auszugeben. Dieser Patch ist nach Aussagen der Lineage-Entwickler nicht sicher. Die Leute von microG behaupten das Gegenteil und sagen LineageOS nach, den eventuellen Konflikt mit Google zu scheuen. Mit den Sicherheitsbedenken gegenüber Signature-Spoofing setzt sich ein Blogeintrag ausführlich auseinander. Der jetzige Fork hat den Patch zu Signature-Spoofing auf Systemdateien beschränkt und damit nach Entwickleraussagen die Sicherheitsprobleme eingedämmt.
Bisher 40 Modelle unterstützt
LineageOS for microG veröffentlicht jeden Tag frische OTA-Updates und bietet native Unterstützung für F-Droid. Das ROM steht derzeit für rund 40 Smartphone-Modelle zum Download zur Verfügung. Die Installation kann nach den Vorgaben im LineageOS-Wiki erfolgen. Allerdings muss zunächst das bestehende System entfernt werden. Wenn keine Daten übernommen werden sollen, reicht hierzu ein Factory-Reset. Ansonsten bietet das Projekt ein Migration-ZIP. Das Projekt wird auf GitHub entwickelt.
Debian-Entwickler Matthias Klumpp berichtet von ersten Versuchen, bereits funktionierende Software-Stacks zu finden, die auf der Test-Hardware für das Librem-5-Smartphone laufen. Dabei setzte er KDEs Plasma Mobile auf einem Entwicklerboard mit der i.MX-6-CPU der Firma NXP ein. Diese CPU, die auf dem ARM-Cortex-A9-Kern basiert, dient derzeit zum Testen, da der Nachfolger i.MX-8 unter anderem wegen Problemen mit dem freien Grafiktreiber Etnaviv noch nicht einsatzbereit ist. Für das fertige Produkt soll jedoch nach Möglichkeit der modernere i.MX-8 zum Einsatz kommen.
KWin läuft auf Wayland
Klumpp setzte ein Standard-Debian aus dem Testing-Zweig (Buster) mit Kernel 4.13 ein. Anfänglich bereitete der Fenstermanager KWin einige Probleme im Zusammenhang mit Wayland. Nach einiger Recherche zusammen mit Plasma-Mobile-Entwickler Bushan Sha wurde der Schuldige schnell entlarvt. Die Bibliothek Epoxy, die für das Zeigermanagement unter OpenGL zuständig ist, war in Debian zu alt. Der Fehler war in einer neueren Version bereits behoben. Mit einer aktuelleren Version startete die Plasma-Shell auf dem Board.
Abgehangene Komponenten
Als Nächstes galt es, die weiteren Plasma-Mobile-Komponenten aus dem Git-Master-Repository zu bauen. Nach kleineren Problemen führte der Befehl kwin_wayland --drm --xwayland plasma-phone zum Erfolg einer startenden Plasma-Mobile-Shell. Damit war klar, das Plasma Mobile mit der gegebenen Hardware initial zum Laufen zu bekommen ist. Von hier zum fertigen Produkt sei es aber noch ein weiter Weg, wie Klumpp erläutert. Unter anderem muss an der Geschwindigkeit der Ausführung gearbeitet werden. Allerdings verwendete Klumpp nicht die neuesten Komponenten, sondern die bereits etwas abgehangenen KWin/Plasma 5.10.5 und KDE Frameworks 5.37.0 auf der Basis von Qt 5.9.1.
KDE Plasma Mobile generell lauffähig
Generell läuft Plasma Mobile aber in Alpha-Qualität auf dem Test-Board. Das auf Qt Quick/QML basierende Application-Framework Kirigami bietet zudem App-Entwicklern bereits jetzt eine benutzbare Basis. Es wurde bereits unter Android getestet und läuft ebenfalls gut auf der Plasma-Mobile-Shell. Weitere Einsichten in die generelle Entwicklungsplanung für KDE Plasma Mobile vermittelt ein aktueller Blogeintrag von Plasma-Entwickler Sebastian Kügler. Die Finanzierung des Librem 5 steht derweil bei 2.155.439 US-Dollar. Das freie Smartphone kann weiterhin vorbestellt werden.
Nachdem Canonical mit Ubuntu 17.10 Artful Ardvark der Umstieg von hauseigenen Desktop Unity zu GNOME gelungen ist, tritt der Ubuntu-Hersteller jetzt dem Advisory Board der GNOME Foundation bei. Die Mitglieder dieses Beratungsgremiums vertreten Unternehmen und Projekte, die das GNOME-Projekt unterstützen. Obwohl der Beirat keine Entscheidungsbefugnis für die GNOME-Stiftung hat, kommunizieren seine Mitglieder mit dem Vorstand und helfen dem Direktorium der Stiftung, die allgemeine Ausrichtung von GNOME und der GNOME-Stiftung zu lenken.
Finanzielle und beratende Unterstützung
Zudem unterstützen die Mitglieder des GNOME Advisory Board das Projekt auch mit Finanzmitteln. Die Beiträge belaufen sich je nach Umsatz des Unternehmens zwischen 11.500 und 23.000 US-Dollar pro Jahr. Die Aufgaben der Mitglieder sind im GNOME-Wiki zusammengefasst. Die 11 Mitglieder sind seit dem 1. 11. 2017 die Unternehmen und Projekte Canonical, Debian, Endless, Free Software Foundation, Google, Linux Foundation, Private Internet Access, Red Hat, Sugar Labs, SUSE und The Document Foundation.
Jamie Bennett, Vize-Präsident der IoT-Entwicklung bei Canonical sagte, der Erfolg von Ubuntu 17.10 Artful Ardvark sei auch der GNOME-Community zu danken. So freue man sich bei Canonical, dem Advisory Board beizutreten und die Zusammenarbeit auf einer neuen Ebene zu intensivieren. Neil McGovern, ehemaliger Debian-Projektleiter und derzeit Direktor der GNOME Foundation, sagte, Canonical bringe sehr viel Erfahrung mit und dass die GNOME Foundation glücklich darüber ist, Canonical mit an Board zu haben.
Gewinn für beide Parteien
Durch den Wechsel vom hauseigenen Desktop Unity zu GNOME bringt Ubuntu Millionen von Anwendern erstmals mit dem GNOME-Desktop in Kontakt. Damit rückt nicht nur Ubuntu wieder näher an die Open-Source-Gemeinschaft, auch GNOME wird durch den Zuwachs an Nutzern und damit auch vieler Bugreports noch besser werden.
