Schlagwort: IMHO
Veröffentlicht am 17. April 2015 7. Mai 2015
COPRs: Ein zweischneidiges Schwert
Als vor nicht all zu langer Zeit COPRs (Cool Other Peoples Repositores) Einzug in das Fedora Repository hielten, war die Freunde gros, das man endlich ein Pendant zu den PPAs aus dem Untuntu-Universum habe.
Inzwischen hat man jedoch immer öfter den Eindruck, das COPRs als eine Art Zwischenschicht zwischen Rawhide und Stable missbraucht werden. Als jüngstes Beispiel könnte man das mit dem Kernel 4.0 eingeführte Live-Patching nennen. Einerseits wird bekanntgegeben, das Live-Patching standardmäßig im Fedora-Kernel deaktiviert ist, im gleichen Atemzug wird jedoch auf ein use on your own risk COPR verwiesen, wo man Kernel mit aktiviertem Live-Patching bekommen kann.
COPRs sind durchaus nützlich und hilfreich, wenn es darum geht, Dritten Pakete zur Verfügung zu stellen, die (noch) nicht in den offiziellen Fedora Repositories enthalten ist oder um neuere Versionen der in Fedora enthaltenen Software zum Testen bereit zu stellen. Ich halte es jedoch falsch, COPRs für das Entwickeln und Testen neuer Features zu verwenden. Dafür war bislang Rawhide zuständig und so sollte es auch bleiben. Ansonsten war Fedora die längste Zeit die Distribution, die man sich installiert hat, wenn man möglichst nahe am Puls der Linux-Entwicklung sein wollte und wird immer mehr zu einem Debian auf rpm-basis.
Linux is doch kein copy cat! – ein GTK-Theme Rant
Eigentlich bin ich ein Mensch, der nur ungern die standardmäßig verwendeten Themes von Gnome (adwaita) oder Xfce (greybird) nutzt, da ich meinen Desktop gerne etwas individueller haben möchte.
Allerdings ist mir im Moment ehrlich gesagt nur noch nach Heulen zumute, wenn ich so durch die Liste der Themes bei (gnome|xfce)-look.org oder DeviantArt blättere: Im Grunde gibt es dort momentan nur noch 3 Arten von Themes: Flat-Design, Windows-like und OSX-like.
Aus dem Grund möchte ich den Designern am liebsten nur noch so laut es geht ins Gesicht brüllen:
THIS IS LINUX AND NO F***ING WINDOWS, ANDROID OR OSX!!!111
Wenn ich möchte, das mein Desktop wie ein Windows oder OSX aussieht, dann installiere ich mir das Original und vergewaltige meinen Linux-Desktop nicht mit dem Versuch, das Look&Feel einer anderen Plattform zu imitieren! Und wenn ich Android-Optik haben möchte, dann greife ich zum Android-Smartphone oder -Tablet!
Ganz allgemein muss man aber feststellen, das subjektiv betrachtet die Kreativität der GTK-Theme-Designer seit GTK 3.0 beträchtlich nachgelassen hat und irgendwie sämtliche Themes gleich aussehen und sich – überspitzt formuliert – nur der Name des Autors ändert. Wo sind die farbenfrohen Themes aus den Zeiten von GTK 2 geblieben? GTK 3 Themes sind, wenn sie nicht gerade das Look&Feel anderer Plattformen imitieren, fast nur in schwarz oder dunklem Grau gehalten und sehen sich alle irgendwie sehr ähnlich. Fast so, als würde Designer B das Design von Designer A kopieren und nur noch ein wenig modifizieren, damit nicht sofort auffällt, das er kopiert hat.
Nicht minder frustrierend ist auch der Umstand, das wenn man mal ein ansehnliches GTK-Theme gefunden hat, dies meist nicht mehr gepflegt wird und mit aktuellen Versionen von GTK nicht mehr vernünftig – oder manchmal sogar gar nicht mehr – funktioniert.
Vielleicht ist es an der Zeit, Plattformen wie gnome-look.org und xfce-look.org (vorübergehend) abzuschalten, um diesem Trauerspiel endlich ein Ende zu bereiten …
IMHO: Fedora (Desktop) als rolling-release?
Warum denn nicht?!?
Mit Fedora.next wird Fedora bekanntlich in die 3 „Produkte“ Desktop, Server und Cloud aufgeteilt und jedes dieser Produkte kann eigene Release-Zyklen haben.
Und wenn man ehrlich ist, ist Fedora bereits mehr oder weniger ein Semi-Rolling-Release, da Komponenten wie z.B. der Kernel oder PulseAudio auch innerhalb des Releases auf die jeweils aktuellen Releases aktualisiert werden.
Vor diesem Hintergrund finde ich, das man den Gedanken, zumindest das Desktop-Produkt von Fedora auf ein Rolling-Release umzustellen, ruhig mal völlig unvoreingenommen diskutieren sollte. Zumal zu erwarten ist, das Fedora Server und Cloud über kurz oder lang von Fedora Desktop abweichende Release-Zyklen bekommen werden. Oder welcher Admin ist so wahnsinnig und macht alle 6 Monate ein Upgrade seiner Server auf die aktuelle Fedora Version? 😉
Würde man Fedora Desktop auf ein rolling-release umstellen, würde man damit auch gleichzeitig einiges an Ressourcen in der Qualitätssicherung freimachen und könnte diese freien Ressourcen dann für die QA von Cloud und Server verwenden. Die QA von Fedora Desktop würde sich dann nur noch darauf beschränken, die regelmäßig (alle 6 Monate?) aktualisierten Installationsmedien zu überprüfen, welche dann auf Basis der Stable- und Updates-Repositories erzeugt werden.
Konkret könnte ein Rolling-Release von Fedora Desktop dann so aussehen, das Rawhide als so etwas wie Debian-Unstable fungiert, wo neue Pakete oder größere Upgrades (z.B. Gnome 3.12 -> 3.14) lagern, bis sie stabil genug für Updaes-Testing sind und dann entweder nach einer gewissen Zeit oder aufgrund vorher definierter Kriterien weiter nach Updates-Testing und von dort wie bislang auch in das Updates-Repository wandern.
Das bislang für neue Releases notwendige Branchen und der damit verbundene QA-Aufwand würde somit, wie bereits erwähnt. zumindest für das Desktop-Produkt entfallen, da Fedora Desktop Releases im Grunde nur noch Snapshots des Stable- und Updates-Repositories sind, die dementsprechend weniger QA-Aufwand erfordern.
Abschließend noch eine kleine Umfrage:
Sollte eine Umstellung von Fedora Desktop auf rolling-releases zumindest ergebnisoffen diskutiert werden?
habe keine Meinung dazu
Sicherlich gäbe es noch einige andere Gründe, die für ein rolling-release von Fedora Desktop sprechen, aber es würde sicher den Umfang diese Beitrages sprengen, wenn hier auf jedes mögliche Argument eingegangen wird. Wenn Ihr jedoch noch einige Argumente für (oder gegen) ein rolling-release von Fedora Desktop habt, schreibt sie doch einfach in die Kommentare.
IMHO: Was fehlt: silent updates
Seit einigen Versionen beherrscht PackageKit in Kombination mit Gnome so genannte „Offline-Updates“, was nichts anderes bedeutet, als das Updates während des Bootvorgangs in einer speziellen Umgebung installiert werden.
Wenn man diesen Gedanken jedoch konsequent zu ende denkt, können die Offline-Updates nur der erste Schritt auf dem Weg zu stillen Updates, die man auch etwas vulgär „halt die Klappe und mach einfach Modus“ nennen könnte, gewesen sein. Dieser zweite Schritt ist jedoch eigentlich schon mehr als überfällig.
Oder um es mit den Worten von David Sieg zu sagen:
… Jetzt mal ehrlich: Wen interessiert, dass libcurl, libfoo und libArsch aktualisiert wurden?
Das sind doch wieder Informationen, die nur Arch-, Gentoo- und andere Wirrköpfe brauchen…
Die meisten Benutzer dürfte es in der Tat kaum interessieren, welche Pakete gerade aktualisiert werden sollen. Sie wollen einfach ein stabiles und sicheres System, mit dem sie arbeiten können und nicht mit für sie belanglosen Informationen, wie eben der, welche Updates verfügbar sind, belästigt werden.
Microsoft hat das erkannt und bietet diese stillen Updates, bei dem die Updates im Hintergrund heruntergeladen und beim nächsten Herunterfahren des Systems installiert werden, schon seit einiger Zeit an. Warum tut sich Linux dann bitte so schwer damit seinen Nutzern so etwas anzubieten?
Oder ist Linux im Grunde noch immer ein System von Freaks für Freaks?
abrt = Zeitverschwendung(?)
Ich weiss jetzt nicht, ob das nur mir so geht, aber ich habe immer wieder den Eindruck, das die Benutzung von Fedoras abrt (automatic bug reporting tool) im Grunde reine Zeitverschwendung ist, weil es anscheinend Paket-Maintainer gibt, die solche automatisch erzeugten Bugreports konsequent ignorieren. Und um es mal ganz deutlich zu sagen: das finde ich zum kotzen!
Da lädt man also teilweise mehrere MBs an Daten zu den Retrace-Servern hoch, damit die daraus einen Retrace erzeugen und schreibt anschließend (sofern möglich) eine möglichst präzise Beschreibung, wie es zu dem Absturz kam, nur, damit dann der verantwortliche Maintainer einem den (virtuellen) ausgestreckten Mittelfinger zeigt, weil ihn solche Bugs anscheinend nicht interessieren.
Und um ehrlich zu sein, habe ich auch weder Zeit noch Lust, den Maintainern ständig hinterher zu rennen, damit sie sich mal um die von mir gemeldeten Bugs kümmern. Sobald der Bug im Bugtracker angelegt ist, habe ich meinen Teil fürs erste getan und der Ball liegt bei dem Maintainer, der sich gefälligst darum zu kümmern hat.
Bugs jedoch zu ignorieren, bis sie irgendwann automatisch geschlossen werden, weil die Fedora Version, für welche die Bugreports angelegt wurden, EoL ist, ist auf jeden Fall ein ganz schlechter Stil!
Veröffentlicht am 15. Juni 2013 18. Juni 2013
IMHO: Gnome Classic Mode: Die Gnome-Shell ist auf dem Desktop gescheitert
Mit der Version 3.8 hat das Gnome-Projekt den seit Gnome 3.0 existierenden Fallback-Mode durch den so genannten Classic-Mode ersetzt, der dem Gnome 2.x Desktop ähnelt.
Offiziell begründet man beim Gnome-Projekt den Classic-Mode damit, das der Fallback-Mode zu wartungsintensiv und kaum genutzt worden sei. Viel Wahrscheinlicher dürfte jedoch sein, das man bei Gnome zu der Erkenntnis gekommen ist, das die Gnome-Shell auf dem Desktop gescheitert ist und das man hofft, mit dem Classic-Mode Benutzer, die zu anderen Desktops gewechselt sind, wieder zu Gnome zurück holen zu können.
Ob dieses Ansinnen von Erfolg gekrönt ist, wird sich noch zeigen müssen. Da jedoch Red Hat bereits hat verlauten lassen, das man bei RHEL 7 standardmäßig den Classic-Mode als Desktop nutzen will, dürften wohl viele „Gnome-Flüchtlinge“ zumindest kurzzeitig wieder zu Gnome zurückkehren ob sie jedoch bei Gnome bleiben hängt auch davon ab, wie es mit dem Classic-Mode in Zukunft weitergeht.
Nichts desto trotz wären die Gnome-Entwickler gut beraten, einerseits den Classic-Mode nicht so stiefmütterlich zu behandeln, wie sie es beim Fallback-Mode getan haben und andererseits sollten sie sich ernsthaft Gedanken machen, ob die an eine Tablet-Oberfläche erinnernde Gnome-Shell tatsächlich die richtige Arbeitsoberfläche für Notebooks und Desktop-PCs ist, da sie Arbeitsabläufe erzwingt, die im Berufsalltag wohl sehr oft als nicht intuitiv empfunden werden dürften.
IMHO: Testet Eure Updates, bevor ihr sie veröffentlicht!
Es ist heute zum zweiten mal binnen weniger Tage passiert, das ein kaputtes Update in updates-testing gelandet ist. Bei ersten mal hat es LibreOffice erwischt, das aufgrund von nicht bzw. nicht ordentlich kommunizierten Änderungen am harfbuzz-Paket nicht mehr benutzbar war.
Heute dann das accountsservice Update, welches permanente SELinux-Fehlermeldungen verursacht und dadurch das System extrem ausbremst, da SELinux quasi am durchdrehen ist.
Ja, mir ist bekannt, das Updates in updates-testing fehlerhaft sein können und ja, ich weiß auch, das sich Fedora 19 offiziell noch in der Entwicklung befindet. Aber wenn ich mir das Problem mit dem accountsservice Paket anschaue, dann beschleicht mich der Verdacht, das da jemand das Update entweder gar nicht oder nicht vernünftig getestet hat, bevor er es nach updates-testing hochgeladen hat. Ich unterstelle einfach mal, dass das Problem mit SELinux aufgefallen wäre, wenn das Update vorher lokal vernünftig getestet worden wäre.
Vernünftiges Testen heißt in diesem Fall für mich, dass das Update z.B. in einer virtuellen Maschine mit Fedora 19 installiert wird und das vor der Installation des Updates erst einmal ein Update des Systems gemacht wird und das SELinux bei dem System im enforcing Modus läuft.
Das Systeme durch ein Update, auch wenn es „nur“ in updates-testing liegt, nahezu unbenutzbar werden, kann und darf in meinen Augen nicht passieren! Und ich denke, diesen Anspruch darf man als Anwender durchaus stellen, auch und gerade weil Fedora eine so genannte bleeding-edge Distribution ist.
Vorherige Seite Seite 1 Seite 2 Seite 3 Nächste Seite
Social-Network Präsenzen
StatusNet
KeepassX 2 (1.081) Paket-Review
rpmFusion