http://raphaelhertzog.com/2011/04/27/towards-debian-rolling-my-own-debian-cut-manifesto/
Hi devil,
wird CUT wirklich so eingeführt wie hier beschrieben (http://cut.debian.net/snapshots/implementation_plan/)? Wäre eine gute Sache.
Es gibt momentan soweit ich weiß frühe-alpha-Qualität ein-Mann-debian-cut-isos aus testing. Ein eigenes rolling gibt es noch nicht und ich würde auch nicht drauf wetten, dass das bald kommt. Vielleicht lasse ich mich zu einem späteren Zeitpunkt aber auf eine "Es kommt überhaupt irgendwann" Wette ein - allerdings hab ich mich noch nicht für Bet oder Lay entschieden... ;) Dafür ist vieles einfach zu ungewiss...
Das Problem von rolling ist ja auch - wenn unstable gößtenteils zugefroren ist, wo sollen den dann updates herkommen? Gibts dann auch ein unstable-rolling?
Die Manpower- und Securitydiskussion will ich da schon gar nicht anfangen...
P.S.: CUT ist bei weitem keine Erfindung der Neuzeit - das ist mindestens so alt wie testing selbst...
Und an einen netten Aprilscherz erinnert es mich: "Coming (not so) soon: CUU - Constantly Usable Ubuntu" ;)
Der 3 (4) stufige Ansatz von debian zur Erreichung einer stabilen Distribution ist doch schon recht genial und erfolgreich - wenn man dann Wert auf stable legt. Die einzigen User, die in den Hintern gekniffen sind, sind die User von sid und Testing, wenn grad mal Freeze ist. Wo soll denn das Material für rolling herkommen, wenn es teilweise nicht mal experimental erreicht, weil die Pakete nicht mal für experimental gepackt werden?
Die einzige Möglichkeit, dass ein wenig zu entschärfen, wäre eine Schiene rechts neben experimental, wo die Quellen aus der Entwicklung quasi nativ reinfließen. Wenn man sich aber die Klimmzüge anschaut, die notwendig sind, um aus "funktionierenden" Quellen ein debian-konformes Paket zu bauen, halte ich es für recht unwahrscheinlich, dass da eine Änderung passieren wird. Die Manpower, die für so was notwendig wäre, hat man während den Perioden, wo es nicht friert. Da braucht man diesen Mechanismus nicht. Ist aber grade Winter, sind die Ressourcen gebunden, da bringt dieser Mechanismus nichts, weil die Leute daran arbeiten, die Pakete stabil zu bekommen. Catch 22.
Die in meinen Augen sinnvollste "Lösung" wäre eigentlich eine Distribution, die konsequent auf Rolling als Endprodukt angelegt wäre. Das ist dann aber nicht mehr debian, weil das eigentliche Ziel - eine stabile Distribution - gleich mal mit über Bord gehen würde. Wie will man jetzt also ernsthaft ein Quadrat zum Kreis machen?
Das wäre nicht rechts neben experimental, das wäre direkt darunter und würde "autobuild" heißen. Die befinden sich aber aus gutem Grunde nicht auf offizieller Debianinfrastuktur sondern in privaten Archiven. X-Server hat sowas z.B., Ubuntu spielt unter dem Namen "Daily-Builts" damit rum und von iceweasel und kde kennt ja fast jeder das externe Repo was wieder nicht soooo aktuell ist, weil viele viele da am Tropf hängen. Den das bereitstellen eines debian Paketes (vor allem außerhalb von ftpmaster) ist relativ einfach (mit etwas übung vielleicht): Aber wer kümmert sich den um anfallende Fehler?
Ich nutze hier quasi instant builds von APT (soll heißen, nach einem make ist es automatisch "mein" apt-*), das funktioniert meistens (nicht immer), aber um User die das nutzen möchte ich mich nun beim besten Willen nicht kümmern. Wers so aktuell haben will, der muss den weg des selberbauens gehen. Dann kann ich mir immerhin auch halbwegs sicher sein, dass der Aspirant kleinere Problem selber lösen kann und seine Fehlermeldungen mir auch was bringen... Tut mir leid, aber den allermeisten hier würde ich das nicht zumuten wollen, selbst experimental wäre da schon an der Schmerzgrenze... Und den Anspruch hab ja nicht nur ich. Das Label "debian" und alles darumherum hat ja schließlich seinen guten Ruf, den machen autobuild/experimental nicht besser...
Und wenn man doch zu sehr an Upstreamtracking denkt: Immer an udev denken, jedesmal wenn da upstream "zu dicht" getrackt wird wird sich beschwert ;)
Ich sagte es schon öfter: Die eierlegende Wollmilchsau gibts (leider) nicht... auch nicht in debian.
Mit rechts neben experimental meinte ich die schon häufiger diskutierte Möglichkeit, den Pfeil der Stabilität nach rechts auszudehnen. Es ist imho relativer Schwachsinn, dass in der Freeze-Phase Pakete, die eigentlich ins unstable gehören in experimental geparkt werden. In meinen Augen gehören ins experimental nur Pakete, die wirklich experimental sind. In anderen Worten: Pakete, die eigentlich ins unstable gehören, da aber wegen eines freezes nicht reinkönnen, gehören in irgendein anderes Aufschlag-Repo. Und das nicht nur zu freeze-Zeiten, sondern permanent.
Wurde in den Listen hoch und runter diskutiert im bedenkenswertem dafür und dagegen. Es wäre möglich, es würde nicht mehr Arbeit bedeuten und einigen Leuten ob der Einordnung besser gefallen. Nicht mehr und nicht weniger. Das ist aber nur ein Etikett, ich habe keinerlei Probleme damit, Pakete, von denen ich meine, sie unbedingt fahren zu müssen, aus experimental zu holen. Ich kann aber auch die Sachen, die ich kaputtmache, im allgemeinen selbst wieder reparieren. Daher ist mir das Repository egal. An der Qualität der Pakete ändert die Einordnung nichts. Und das Grundproblem würde bestehen bleiben: Wer packt in den Zeiten des Freezes eigentlich aktuelle Sachen? Stimmt - keiner!
Also löse ich das für mich ganz pragmatisch: Wenn ich spielen will, nehme ich Arch. Wenn ich arbeiten will, nehme ich debian. Auf einen Computer passen doch mehr als ein Linux. Dann ist die Freude doch viel größer, wenn einige Neuigkeiten wirklich in debian ankommen. Vor allem, und das ist mir relativ wichtig - die funktionieren dann auch, von den in der letzten Zeit passierten Kleinigkeiten abgesehen, auch zuverlässig. Für die Kleinigkeiten ist das ja auch unstable.
@Agaida, Etiketten haben auch ihre Wirkung, siehe den udev Maintainer, der "unstable" unbedingt wörtlich nehmen will.
So wie ich den Blog verstanden habe, interessiert sich der Author nicht für CUT, was nach den debconf Vorträgen nur als getestetes Installations Testing Repo gemeint war, und er schlägt eigentlich genau das vor was wir wollen: ein floating Repo, was auch in EisZeiten neue Sachen aufnimmt, die jetzt ins Experimental kamen.
Das wäre schön - die Frage nur ist: Wer soll das leisten. Auch wenn es mir persönlich teilweise auf den Sack geht, das Ziel von debian ist die stable. Dem ordnet sich alles unter. Testing und unstable sind das, wofür der udev-Maintainer sie benutzt hat. Wenn man die Definition der Repos betrachtet, dann sind die genau für so was da. Kein Mensch hat je davon geredet, dass sid immer einsetzbar und stabil sein muss. Das wäre ein Entwicklungshemmnis ohne gleichen.
Und in diesem Fall hat sid seinen Zweck erfüllt. Etliche Entwickler, für die ja sid gedacht ist, haben sich ernsthaft bemüht, schnell eine Lösung zu finden, hat ja auch geklappt. :twisted: Die Gruppe derjenigen, die ausdrücklich vor dem Einsatz von Sid gewarnt wurde, schaute mehr oder weniger hilflos in die Röhre. Mit testing wäre das nicht passiert. (Auf jedem Fall nicht in dem Ausmass).
Es wäre zwar schön gewesen, diesen Vorfall zu vermeiden, aber so wie ich in den letzten Jahren debian verstanden habe, war da nichts, was man dem Mann vorwerfen kann.
In diesem Sinne sind die Intentionen des Autors ja schön und gut - die Eingangsfrage bleibt aber. Das selbe Spiel erlebe ich, seit ich Arch benutze. Jeder Anfänger wird gewarnt, sich von testing oder unstable fernzuhalten. Wir reden nicht mal vom AUR. Und dann schau Dir bitte an, was der geneigte Ubuntu-Umsteiger als echter Elite-Hacker tut. Nach dem Freischalten von testing und unstable, so vorhanden, folgt die automatische Installation von yaourt. Das ist wie ein Pavlowscher Reflex.
Der Rest vom Lied ist bekannt. Die Pakete sind mal wirklich und richtig aktuell. Wenn man Glück hat, kann man diese Aktualität dann auch die eine oder andere Stunde geniessen. Dann ist die Installation, mit noch nicht einmal Basiswissen, schwierige Situationen zu meistern, schon vor der Beendigung der grundlegenden Einrichtung irreparabel zerschossen. Einfach immer wieder geil. Und glaube mir, ich weiss, wovon ich rede. Einer dieser Trottel war vor ziemlich genau zwei Jahren meine Wenigkeit. Nach dem 2. Totalverlust durch Blödheit habe ich aber angefangen zu lernen und vor allem den Wert einer Datensicherung kennen gelernt.
Die Frage bleibt auch, wohin mit dem Zeug ausser experimental. Bei notwendigen Nachbesserungen auch während des Freezes muss testing und sid konsistent sein, wollen die Repos nicht den Sinn verlieren. Es kommt zwar nicht oft vor, dass sich im Freeze Pakete gravierend ändern, aber der normale Weg bei Änderungen muss erhalten bleiben, um die Qualität des späteren stable zu erreichen und auch zu bewahren. Deswegen die von mir wieder ein mal aufgekochte Idee eines Repos zwischen experimental und sid. (Auch in Nicht-Freeze-Zeiten)
Bei Arch sieht das anders aus. Das ist eine Developer-Distribution. Die Buben entwickeln die so, wie sie wollen und benutzen sie auch selbst. Deswegen sollte da schon eine gewisse Stabilität drin sein. Man will sich ja nicht selbst ins Knie schießen. Große Rücksichten auf die Community wird da aber nicht genommen: Wenns knallt, dann ist das halt so und wird schnellstmöglich repariert. Und vor allem ausser core, extra und community wird ausdrücklich gewarnt. Da gilt dann: Du hast es kaputt gemacht - mach es gefälligst wieder ganz. Im Zweifel spiel Deine Datensicherung ein. Hast Du keine aktuelle - Pech gehabt, das übt fürs nächste Mal.
Bitte stell Dir dieses Szenario vor und versuch Dir vorzustellen, wie wirklich glücklich die Mehrheit der Aptosid-User über solche Ansinnen wäre.
@DonKult: Nachdem ich das geschrieben habe, würde ich für mich auf lay tippen.
Quote from: "agaida"Wenn man die Definition der Repos betrachtet, dann sind die genau für so was da. Kein Mensch hat je davon geredet, dass sid immer einsetzbar und stabil sein muss.
Es geht mir auf den Sack, dass der Maintainer des empfindlichsten udev Pakets sich nicht bequemt, seine Neuerungen mal zwei Tage in experimental zu lagern. Dann würden ein paar es ausprobieren und unsere ganzen Nutzer mit Null cli Erfahrung säßen nicht genau einmal im Jahr total auf dem Trockenen. Frag mal DonKult, wie genau er Sachen prüft. Apt ist auch oft erst einmal in experimental. Und dann ist apt nichtmal so kritisch, denn da bootet der Pc wenigstens noch! (Neben udev und dem Kernel ist es klar das kritischte Paket ...)
QuoteJeder Anfänger wird gewarnt, sich von testing oder unstable fernzuhalten.
Hier wurde Jahrelang auf sidux.com Anfängern Debian unstable ans Herz gelegt ...
QuoteDeswegen die von mir wieder ein mal aufgekochte Idee eines Repos zwischen experimental und sid.
So habe ich RH verstanden: in Nicht-Freeze-Zeiten zwischen Testing und Stable, im Freeze zwischen Experimental und Unstable. Das würde ich allerdings "Floating" nennen.
Es würde in der Stabilität mit einem nichtLTS Ubuntu Release vergleichbar sein (sogar besser!), und viele Desktop Benutzer wieder zu Debian ziehen können. Die sind durch die langen Freezes natürlich so nicht zu halten, was ich mit meinem Aufruf "Debian Releases einstellen" auf debianforum.de vor einem Jahr meinte ...
hier teil 2 der ideen von Raphael Hertzog: http://raphaelhertzog.com/2011/04/28/no-freeze-of-debian-development-what-does-it-entail/
greetz
devil
Hallo Alf, hallo Ralph,
was Rolling Releases unter Debian angeht, sollte ehrlich gesagt werden, dass das Rollen ein reiner Nebeneffekt ist. In Sid kommt alles nach Lust und Laune herein, einigen Maintainern ist Konsistenz in Sid schnuppe, wie dem von udev, andere bemühen sich um Konsistenz.
Auch wenn PCLinuxOS einige Mängel hat, rollt es nach einem anderen Konzept. Aktuelle Programmversionen werden gerade auf Konsistenz hin laufend in das System integriert. Eine Fehlermeldung bei einem Update kommt dort meistens nur dann zustande, wenn bei Aktualisierungen noch nicht alle neuen Versionen zur Verfügung stehen oder wenn die Gruppe um Texstar mal richtig Mist gebaut hat :-)
Wenn ein Debian rollen würde wie ein PCLinuxOS, wäre das eine sehr gute Sache, ich meine damit eine Distribution, die das Debianformat, dpkg und alle guten Werkzeuge von Debian verwendet, aber rollt wie PCLinuxOS.
Viele Grüße,
Holger
@holgerw: Wäre bestimmt eine feine Sache, aber irgendwo halt ziemlich sinnfrei. <einschleim> Eine Sache wär natürlich Klasse, richtig rollend mit apt-get </einschleim>. Das Rollen ist ein sehr angenehmer Nebeneffekt - das ist klar. Richtig rollend würde einen anderen Satz Pakete bedeuten, mit apt als Paketmanagement, bestimmt machbar - aber warum. pacman und emerge sind doch schon erfunden, samt Distribution drumrum.
Das spannende an debian ist doch, dass man eine Arbeit einmal macht, in verschiedenen Stufen der Entwicklung. D.h. ich habe die gleichen Quellen und Werkzeuge auf meinen Produktionsmaschinen, Desktop und den Testgeräten. Das ist eine enorme Arbeitserleichterung und der eigentliche Grund dafür, dass ich debian fahre. (Ausser, dass es Spass macht und die Aktualität und die Stabiliät für mich wirklich völlig zufriedenstellend sind) Was ich auf dem Desktop teste und schraube, kann ich 1:1 auf den Servern umsetzen, natürlich dann in stable oder nur minimal weniger. Ich war kurz davor, dass mit Arch zu probieren, aber so verzweifelt und wahnsinnig war ich dann doch nicht.
Hallo Alf,
Dein letzter Beitrag ist aus Sicht eines ambitionierten IT-lers geschrieben, ich schreibe aus Sicht eines ambitionierten Anwenders und auch zur Not für die einfachen Anwender :-)
Und PCLinuxOS geht schon sehr in die Richtung, es auch einfachen Anwendern zu ermöglichen, zeitnah an die aktuellen Versionen von freien Softwareprojekten zu kommen. KDE stellt regelmäßig neue Versionen zur Verfügung, mit jeder neuen Version von Digikam kommen Verbesserungen, und ich möchte eine Distribution, die das Zeugs einfach zeitnah integriert.
Ich sehe bei diesen Diskussionen ein wenig die Gefahr, dass die Werkzeuge einer Distribution und auch die Distribution mehr in den Mittelpunkt rücken, als das, was diese Werkzeuge und eine Distribution eigentlich machen sollen, nämlich mir freie Software bequem zur Verfügung zu stellen, mit der ich dann arbeiten kann. Dafür bin ich bei Fehlfunktionen meiner Lieblingsprogramme auch gerne bereit, Entwicklern Fehler zu melden.
Viele Grüße,
Holger
@holgerw: ich glaube, ich verstehe Dich da schon sehr gut, da gibt es einen einfachen Weg zu Paketen, die alle halbe Jahre aktuell sind. Diese aktuellen Pakete werden auch nicht bei debian entwickelt und maintainiert. Das ist der angesprochene Zweig ausserhalb der normalen Entwicklung.
Richtig: Es ist Ubuntu ;) Nur meiner bescheidenen Meinung nach der einzige Weg, vorbei an den Debian-Gepflogenheiten zu arbeiten. Alles, was einem nicht passt, macht man selbst, den Rest übernimmt man. Ist zwar nicht rollend, das ist nicht das Konzept, aber mit ähnlich viel Macht ud Kraft müsste man an so was rangehen. Dann hätte es die Chance auf Erfolg. Vielleicht erinnerst Du die noch an mein Aufschlag-Posting "Der lange Weg zu Aptosid". Es gab und gibt Gründe, warum ich mit Ubuntu nicht unbedingt zufrieden bin, daran hat sich auch nichts Wesentliches geändert.
Ich denke nur mal, dass echt rollend so in debian nicht zu realisieren sein wird, weder jetzt noch in absehbarer Zeit. Ich sehe da auch, abgesehen von den Problemen mit der zur Verfügung stehenden Kraft, auch ernsthafte Stabilitätsprobleme in solchem Unterfangen. Auch hier macht es Ubuntu vor. Einfach, fehlerfrei, aktuell und stabil ist ein Ü-Ei, bei dem man realistischerweise momentan einen Punkt streichen muss. Bei mir ist das der Punkt einfach. Ubuntu nimmt den Punkt stabil. Und streicht man einfach, wird es recht rasch technisch.
Schön wäre es aber rollend in einfach und stabil trotzdem.
Hallo Alf,
auch wenn ich ein wenig auf PCLinuxOS herumreite, sehe ich bei der Distribution folgende Vorteile:
Es greift zeitnah aktuelle Versionen freier Softwareprojekte auf und integriert sie, daher ist es ein richtiges rollendes Linux.
Es ist zwar eine rpm Distribution, nutzt aber apt-get und synaptic.
Jeder unerfahrene Anwender kann es mit synaptic aktuell halten, auch unter laufendem Xserver.
Es wirkt auf mich ziemlich robust, ich habe trotz der Alktualisierung kompletter KDE Versionen unter laufendem KDE noch keine bösen Überraschungen erlebt.
Der Hauptentwickler Texstar und ungefähr weitere 20 Leute bekommen PCLinuxOS hin.
Die mir aufgefallenen Nachteile möchte ich aber auch nicht verschweigen:
Es gibt noch keine 64 Bit Untersdtützung.
Bei der sauberen Lokalisierung hapert es manchmal, das bekommen allerdings Leute, die konsequent englische Lokalisierung nutzen, gar nicht mit, und mit dem nochmaligen Aufruf von Addlocale und der Auswahl Deutsch ist das meist behoben.
apt-get mit rpm ist ziemlich lahm.
Es gibt keine geschnürten Debug Pakete wie unter Debian oder openSUSE.
Unter dem Strich habe ich eine für viele einfache Anwender geeignete rollende Distribution für den Desktop.
Kubuntu 11.04 gefällt mir allerdings auch gut, ich habe zur Zeit auf meinem Desktop PC openSUSE 11.04 und Kubuntu 11.04 installiert.
Viele Grüße,
Holger
Zu PCL: Ich fands damals nicht so prickelnd, wie hier auch schon aufgefallen sein wird, hab ich es auch nicht unbedingt so mit einfach;) Das ist irgendwie für mich nicht das Kriterium.
Vom aktuellen Ubuntu bin ich allerdings auch recht angetan, meine Dislikes sind aber auch geblieben und sind, egal welche Oberfläche plymouth, network-manager, der Installer, die Update-Routine und root. Eigentlich alles schöne Sachen, wenn sie denn funktionieren. Da sie es nicht immer und zuverlässig tun, fliegen die halt und Gaida ist zufrieden. Zum kotzen find ich allerdings, dass ich bei Plymouth 2 Pakete neubauen muss, um es final entsorgen zu müssen. Das ist dann nicht mehr anwender- und schon gar nicht einsteigerfreundlich. 2. Negativpunkt ist der Installer und/oder die Update-Routine. Nicht funktionierend ist geschmeichelt, oft geht das ja auch. Man kann es jetzt aber beim Release wieder sehen - die Leute, die auf die Schnauze fallen, häufen sich. Da es sich um Anfänger handelt, die dann natürlich keine Datensicherung haben - doppelt schlimm.
Wenn ich für den unbedarften User arbeite, hat das zu funktionieren, einen erfahrenen Anwender dürften solche Kleinigkeiten recht wenig zum stolpern bringen, da nervt es nur. Das ist aber nicht Ziel der Distribution - von daher Klassenziel nicht ganz erreicht.
Ich habe gestern Ubuntu Natty mit Unity aufgesetzt, ganz sauber über debootstrap und es lief problemlos. Das ist aber nicht unbedingt die Installationsvariante für Anfänger. Was soll ich sagen - läuft bis auf ganze Kleinigkeiten während der Installation prima, aber gewöhnungsbedürftig.
Ja für uns Linuxler ist Unity gewöhnungsbedürftig. Aber ich glaube, dass ist eine Prima Einsteiger Oberfläche, weil alles auch ohne Lernen aufgedeckt wird. Jemand, der noch nie einen Pc bedient hat, und nie Internet gemacht hat, wird damit doch genau hundertmal einfacher fahren, als mit Win7 , oder?
Hi zusammen,
also ich glaube das Ubuntu mit Unity für die meisten (Power)Linux'er eine Zumutung darstellt. Ehrlich gesagt ich möchte mich nicht von einen Desktop dermaßen beschränken lassen. In meinen Augen wird Ubuntu für mich immer windowsähnlicher und somit für unakzeptabel.
@bluelupo, ja für Poweruser. Hatte ich erst genauso empfunden. Man kann sich aber sogar als Poweruser einfinden. Und sieh es mal aus den Augen von absoluten Anfänger !?
Überigens ist Gnome3 noch viel einschränkender als Unity :(
Ich habe auf RHs blog einen sehr kurz angebundenen Kommentar hinterlassen (http://raphaelhertzog.com/2011/04/29/do-we-need-project-wide-support-for-debian-rolling/#comment-13945)
@bluelupo: Um es mal so auszudrücken: Der Linuxprofi wird damit entweder nicht, teilweise oder überwiegend arbeiten wollen, je nach persönlichem Gusto. Den sogenannten Poweruser kenn ich eigentlich nur von Windows als Menschen, der viel über seine Wichtigkeit und die Menge der von ihm zu erledigenden Arbeiten redet. Das unterscheidet ihn vom User, der seine Arbeit einfach nur macht. Beide haben aber eines gemein: Ihr Ego und Wissen passen oftmals nicht mit den Anforderungen, die sie an Software stellen, zusammen. Das führt dann oft zu komischen Situationen.
Ich kann mir durchaus vorstellen, mit Unity zu arbeiten, eine Anforderung von mir wäre die Möglichkeit, die Leiste von links nach rechts zu verlegen. Das würde ca. 80% meiner Mauswege sparen. Andererseits habe ich keine Probleme mit KDE oder Openbox oder Awesome oder irgendwas anderem, wenn ich das Gefühl hätte, was ändern zu müssen. Das sind alles so Sachen, wo ein reiner Anwender, der eventuell nicht mal Adminrechte hat, nicht mitreden kann und soll. Wenn es mir zu bunt wird, wird halt was anderes gesucht und wahrscheinlich gefunden. Siehe Wechsel von Gnome zu KDE. Auch XFCE hatte ich damals getestet, fand mich da aber nicht wieder. Von daher finde ich unity einen interessanten Ansatz, auf jeden Fall interessanter als Gnome 3. Vielleicht ändert sich das, wenn Gnome 3 in ein oder zwei Jahren mal in Ansätzen fertig ist, momentan ist es für mich vollkommen am Thema vorbei und einfach nur unbenutzbar. So wie es ist, ist es die perfekte Werbung für flux- und openbox, XFCE, LXDE, enlightment, halt alles andere, was zur Zeit auf dem Markt ist. Ich empfand es übrigens als cleveren Schachzug, dass sich Mark S. nicht an diesem nicht mal ansatzweise halbgaren Entwurf beteiligt hat. Sehen die Gnomies naturgemäß anders, ist aber nicht mein Problem.
@agaida: Ich würde keine große Lust verspüren mich mit einem einem dermaßen kastrierten Teil, weder beruflich noch privat, beschäftigen zu müssen. Ich verstehe die GNOME-Entwickler überhaupt nicht, warum sie nicht aus den negativen Erfahrungen in der Einführungsphase des KDE4 gelernt haben. Frägt hier einer mal die Anwender was die wollen, brauchen oder sich wünschen. Warum alles in der Welt muss man bewährte Konzepte immer so radikal über den Haufen werfen. Manchmal kommt es mir so vor als ob die einige Programmentwickler einfach zum Zweck einer Änderung an dem Gewohnten sich profilieren wollen.
:twisted: full ack.
Bei unity konnte ich zumindest einen Teil vernünftiger Funktionalität wieder herstellen. Auf Schirmen mit 1366x768 sicher eine große Bereicherung - sowas besitze ich aber nicht :lol:
EDIT: Nicht dass hier aufkommt, dass ich gegen Neuerungen bin, die Sinn machen. Aber alten Wein in neuen Schläuchen muss irgendwie nicht sein.
EDIT 2: Back to Topic, ich hab mit die Antworten im Blog von RH durchgelesen, der Vorschlag von muchan war überdenkeswert - nur dass der bei den debianern auf sehr wenig Gegenliebe stossen wird. CUS statt CUT wäre toll.