> Als Grund gab der Red Hat-Entwickler Jeremy Katz an, noch zusätzliche > Funktionen in die finale Variante einbauen zu wollen.
Eben nicht. Gesagt wird (siehe die verlinkte Mail): > Due to circumstances boutside of our control, we're going to be unable to > keep to the scheduled date of March 15th for the release of FC5 and > instead are going to have to make the release date Monday, March 20th.
Welche das genau sind, wird in der Diskussion leider nicht gesagt.
Doch wird, und zwar einen Satz später, den Du aber nicht quotest: This gives us the opportunity to pull in the final GNOME 2.14 tarballs which should be available on Monday assuming the changes are suitably minor.
Wie kann man denn nur kurz vor nem Release noch Neuerungen einfließen lassen, das schreit doch schon wieder nach Bugs. Da wird wieder schnelle was reingepfriemelt, dass keinem ordentlichen Test unterzogen werden kann und danach hat man wieder die Scheiße.
Geh mal davon aus, dass die Jungs von Red Hat _deutlich_ mehr Ahnung von der Materie haben als Du, die wissen schon was sie tun und können die Auswirkungen ihres Handelns auf die Distribution mit Sicherheit besser beurteilen. Abgesehen davon wird das neue Gnome auch einiges an Fehlerkorrekturen mitbringen. Und das Release verzögert sich ja auch extra wegen der Neuerungen...
Die letzte Testversion von FC5 kam bereits mit Gnome 2.13.4 daher und die Änderungen zwischen 2.13.4 und 2.14 sind kaum der Rede wert. So viel zum Thema "einiges an Fehlerkorrekturen".
Ob sie wirklich wissen, was sie tun können? Dazu sage ich nur "Red Hat 7" und der GCC.
Das war kein Fehlgriff, sondern notwendig, um zum damaligen Zeitpunkt ein Produkt anbieten zu können, das zum damaligen Zeitpunkt auf den zum damaligen Zeitpunkt nachgefragten Hardwarearchitekturen läuft. Wer es besser zu wissen meint, kann ja die Zeit auf den damaligen Zeitpunkt zurückdrehen, ein Unternehmen gründen, das zum damaligen Zeitpunkt Produkte anbietet, wie sie RedHat zum damaligen Zeitpunkt angeboten hat und den Beweis antreten, dass es zum damaligen Zeitpunkt auch ohne GCC 2.96 ging.
Im Übrigen finde ich es wirklich immer wieder erstaunlich und auch ein wenig gewagt, wie in Foren immer wieder Werturteile über die fachlichen Fähigkeiten bekannter Distributionen gefällt werden. Das gilt sowohl für den GCC als auch für GNOME. Es ist nämlich bekannt, dass beide Projekte nicht von Milliarden freiwilliger Helferlein, sondern von gewissen bekannten Unternehmen entwickelt werden, zu denen - man höre und staune - auch RedHat gehört. Daraus könnte man die Schlussfolgerung ziehen, dass RedHat einigermaßen weiß, worum es geht. Diese Schlussfolgerung wäre übrigens richtig.
> zu denen - man höre und staune - auch RedHat gehört. Daraus könnte man die Schlussfolgerung ziehen, dass RedHat einigermaßen weiß, worum es geht. Diese Schlussfolgerung wäre übrigens richtig.
So war es ja auch. Redhat ist regelrecht verachtet worden, weil sie diesen Compiler benutzt haben. Ich hatte Redhat 7 zu der Zeit auch benutzt. In diversen makefiles und configfiles (von nicht Redhat-Programmen) waren Versionsabfragen drin und das Compilieren wurden abgebrochen wenn ein Redhat-gepatchter GCC gefunden worde. Oft hat es einfach gereicht, diese Abfragen zu entfernen und die Programme wurden wunderbar compiliert und liefen bestens hinterher. Was ein Blödsinn, oder?
> Oft hat es einfach gereicht, diese Abfragen zu entfernen und die Programme wurden > wunderbar compiliert und liefen bestens hinterher. Was ein Blödsinn, oder?
Redhat hat in späteren Distributionen teilweise entbuggte GCCs eingesetzt, den die Versionsnummer aber nicht ausreichend geändert. Redhats ursprünglicher gcc 2.96 war wirklich annähernd unbrauchbar, aus dieser Zeit stammen die Versionsabfragen. Später funktionierte er dann etwas besser, was wohl dine Beobachtung erklärt. Die Codebasis ist aber trotzdem veraltet und zu nichts wirklich kompatibel, es war also eher Glück, wenn das Programm nach Entfernen der Versionsabfrage nicht eifach abstürzt.
Dann nimm ihre mutwilligen Verkrüppelungen von KDE, z.B. Konsole: Bei der unten liegenden Tab-Bar haben sie die Textlabels entfernen, so dass sie annähernd unbrauchbar wurde, anschließend wurde sie unter die Menüleiste verschoben, so dass sie wie eine nicht funktionierende Toolbar wirkt. Und dann das ganze noch mit einem (zumindest) damals verbuggten gnome-ähnlichen Theme versehen...
Das ist doch nur ein Zeichen für die hervorragende Konfigurierbarkeit von KDE. Nach ein paar Klicks in den Einstellungen hast du den KDE-Standard wiederhergestellt.
Die Einen beschweren sich, wenn ein Desktop nicht "gescheit" integriert, sondern im Originalzustand belassen wurde. Die Anderen beschweren sich, wenn der Distributor eben genau das gemacht hat. Man soll sich bei RH nicht umgewöhnen müssen, wenn man innerhalb des Standard-GNOME-Desktops mal ne KDE-Anwendung startet: Einzel- vs. Doppelklick usw.
Was hätte RedHat denn deiner Meinung nach machen sollen, um Look & Feel von GNOME und KDE konsistent zu halten? Man muss sich halt auf den kleinsten gemeinsamen Nenner einigen.
| warum sollte man zwei so unterschiedliche Werke gleich aussehen lassen? Damit man sich z.B. in Sachen Doppel- vs. Einzelklick nicht umgewöhnen muss, wenn man in GNOME eine KDE-Anwendung startet. Ich merks ja schon, wenn an Windows gewöhnte im Konqueror Dateien per Doppelklick öffnen und die entsprechende Anwendung dann zweimal startet und sich die Leute drüber aufregen. Wenn das jetzt _innerhalb_ einer Oberfläche passiert, ists noch nerviger.
| Wenn du dir einen Porsche kaufst, reißt du doch auch nicht die Karosserie runter und klatscht die eines Golfs dran, oder? Der Vergleich hinkt. Denn demnach dürfte man unter GNOME niemals K3b und unter KDE niemals GIMP starten. Da dies aber funktioniert und sich manche nicht auf die Anwendungen eines Desktops beschränken wollen, da es für das jeweils andere Toolkit in manchen Punkten bessere Anwendungen gibt, sollte man nicht gleich dutzende Look & Feels _gleichzeitig_ haben.
>>>>Geh mal davon aus, dass die Jungs von Red Hat _deutlich_ mehr Ahnung von der Materie haben als Du, die wissen schon was sie tun und können die Auswirkungen ihres Handelns auf die Distribution mit Sicherheit besser beurteilen
Ich war ne zeitlang KDE Maintainer einer sehr bekannten Distribution, ich weis mit Sicherheit mehr über solche Sachen als du:-)
>>>Abgesehen davon wird das neue Gnome auch einiges an Fehlerkorrekturen mitbringen
Hast du dir schon mal ein RPM Specfile angesehen, schon mal gesehen, wie viele Patches da drin sind z.B. Patches von Entwicklerzweigen ob KDE oder Gnome, solche Patches können auf einmal Probleme verursachen wenn man die mit einer neuen Programmversion mixt, da heißt es nochmal jeden Patch checken ob notwendig oder nicht und dann ordentlich testen, RedHat hat genauso wenig wie andere ein plain Gnome oder KDE im Einsatz von daher kannste da nicht sofort sagen, dass das alles zusammenspielt. Es ist nunmal in jeder ordentliche Firma so, dass man nach ner Testphase und Stabilisierungsphase keine Neuerungen mehr einfließen lässt, egal wie trivial manche Sachen scheinen.
Vorab: Du bist sehr toll. So wie das klingt wars wohl Debian.
Setze selbst fast ausschließlich Debian ein, aber die Releasezyklen sind ein schlechter Witz und mit Sachargumenten nicht mehr zu rechtfertigen. Fazit: ein flotter Release (wohlgemerkt: Distribution - die eigentlich Software ist ja schon stabil) und Distributionsstabilität widersprechen einander nicht.
>Ich war ne zeitlang KDE Maintainer einer sehr bekannten Distribution, ich weis mit Sicherheit mehr über solche Sachen als du:-) Wenn das so ist (warum sagst du nicht einfach um welche Distribution es sich handelt), magst du da sicherlich Recht haben. Die Frage ist doch, was hast du da genau gemacht? Nur die Pakete zusammengeschnürt, oder steckst du auch im KDE Code drinn? Da Red Hat sich stark im Gnome Projekt engagiert bin ich davon überzeugt, dass die Jungs dort auf dem Laufendem sind und ziemlich genau abschätzen können, was da in wie weit die Stabilität der Distribution beeinträchtigen könnte. Mal abgesehen davon schweigt sich der Artikel ja über die neuen Funktionen aus, und dass RH keine Entwicklungsversion von Gnome ins Release packen will halte ich ja wol für selbstverständlich. Ich entwicke Hardware und embedded Software für Mess-, Steuer-, und Regelsysteme, hat zwar mit PC Programmierung wenig zu tun, aber der Projektablauf dürfte in etwa identisch sein. Bei meinem letzten Hardwareprojekt ist mir ne Stunde bevor das Layout in die Vertigung ging noch eingefallen, dass ich ja noch ein paar Messpunkte und die zweiten CAN + RS232 Schnittstellen des Controllers (obwol nicht benötigt) zugänglich machen könnte. Also das Layout noch schnell entsprechend angepasst und ab in die Vertigung damit. Warum ich das so einfach mal flott tuen konnte? Weil ICH die Platine entwickelt habe und deshalb genau wusste, dass diese Änderungen die Funktion der restlichen Schaltung auf keinen Fall beeinflussen konnten. Auf nen anderen (besseren) Schaltregler oder DAC währe ich hingegen so kurz vorm Termin nicht mehr umgestiegen. Dies nur mal als Beispiel. Mir geht es auch nicht darum, hier deine Kompetenz anzuzweifeln, ich kann es nur nicht mehr lesen, wenn hier andauernd auf solch oberflächlicher Grundlage die Kompetenz professioneller Entwickler in Frage gestellt wird. Bisher zumindest ist Red Hat eher durch Qualität aufgefallen. Manchmal komm ich mir hier so vor wie in ner Kneipe, wo ein Länderspiel übertragen wird, da sitzen auch immer ne menge Experten, die alles Besser wissen als die Spieler, der Schirie und die Trainer
>>>Ich entwicke Hardware und embedded Software für Mess-, Steuer-, und Regelsysteme, hat zwar mit PC Programmierung wenig zu tun, aber der Projektablauf dürfte in etwa identisch sein. Bei meinem letzten Hardwareprojekt ist mir ne Stunde bevor das Layout in die Vertigung ging noch eingefallen, dass ich ja noch ein paar Messpunkte und die zweiten CAN + RS232 Schnittstellen des Controllers (obwol nicht benötigt) zugänglich machen könnte. Also das Layout noch schnell entsprechend angepasst und ab in die Vertigung damit.
Jo sowas darfst du bei deinen Geräten/Software evtl. machen, in der Automobilindistrie oder Luftfahrtindustrie, Mobilgeräte dürftest du z.B. sowas nicht, wenn du da eine Änderung vornimmst musst du wieder das komplette Prüfprogramm durchziehen. Meinetwegen macht RedHat sowas und darf sich dann auch zu den Distributionen zählen, die instabil sind etc. Klar gibts bei RedHat Leute, die überall drinstecken, aber auch die machen Fehler und du findest auch massenweise Leute die dir von ätzenden Bugs in Fedora erzählen können. Hast du schon mal in ner richtigen Firma Software entwickelt? Selbst bei meiner eigenen Software würde ich nicht gegen Ende der Testphase neue Features einfließen lassen und ich denke, dass ich bei so einer Anwendung auch im Code drin stecke. Aber es ist nunmal gutes Qualitätsmanagement in der Softwareentwicklung, dass man sich an gewisse Regeln hält.
Hallo, kann jemand was dazu sagen, wie Fedora auf PPC (G4) ist? Debian rennt ja ganz gut. Ubuntu als live-CD ist auch schnell getestet und hat einen guten Eindruck hinterlassen. Um Fedora mal anzusehen, will ich aber nicht gleich alles installieren... Kann jemand vielleicht seine Erfahrung im Vergleich zum debian sagen ...
> Funktionen in die finale Variante einbauen zu wollen.
Eben nicht. Gesagt wird (siehe die verlinkte Mail):
> Due to circumstances boutside of our control, we're going to be unable to
> keep to the scheduled date of March 15th for the release of FC5 and
> instead are going to have to make the release date Monday, March 20th.
Welche das genau sind, wird in der Diskussion leider nicht gesagt.
Da wird wieder schnelle was reingepfriemelt, dass keinem ordentlichen Test unterzogen werden kann und danach hat man wieder die Scheiße.
Ob sie wirklich wissen, was sie tun können? Dazu sage ich nur "Red Hat 7" und der GCC.
Nun verzeihe ihnen doch endlich mal diesen "Fehlgriff". Das ist lange, lange her ...
Im Übrigen finde ich es wirklich immer wieder erstaunlich und auch ein wenig gewagt, wie in Foren immer wieder Werturteile über die fachlichen Fähigkeiten bekannter Distributionen gefällt werden. Das gilt sowohl für den GCC als auch für GNOME. Es ist nämlich bekannt, dass beide Projekte nicht von Milliarden freiwilliger Helferlein, sondern von gewissen bekannten Unternehmen entwickelt werden, zu denen - man höre und staune - auch RedHat gehört. Daraus könnte man die Schlussfolgerung ziehen, dass RedHat einigermaßen weiß, worum es geht. Diese Schlussfolgerung wäre übrigens richtig.
So war es ja auch. Redhat ist regelrecht verachtet worden, weil sie diesen Compiler benutzt haben. Ich hatte Redhat 7 zu der Zeit auch benutzt. In diversen makefiles und configfiles (von nicht Redhat-Programmen) waren Versionsabfragen drin und das Compilieren wurden abgebrochen wenn ein Redhat-gepatchter GCC gefunden worde. Oft hat es einfach gereicht, diese Abfragen zu entfernen und die Programme wurden wunderbar compiliert und liefen bestens hinterher. Was ein Blödsinn, oder?
> wunderbar compiliert und liefen bestens hinterher. Was ein Blödsinn, oder?
Redhat hat in späteren Distributionen teilweise entbuggte GCCs eingesetzt, den die Versionsnummer aber nicht ausreichend geändert. Redhats ursprünglicher gcc 2.96 war wirklich annähernd unbrauchbar, aus dieser Zeit stammen die Versionsabfragen. Später funktionierte er dann etwas besser, was wohl dine Beobachtung erklärt. Die Codebasis ist aber trotzdem veraltet und zu nichts wirklich kompatibel, es war also eher Glück, wenn das Programm nach Entfernen der Versionsabfrage nicht eifach abstürzt.
Der gcc 2.96 war für NICHTS gut.
Welche ominöse Hardwareplattform war das denn, die den 2.96 brauchte? Und warum haben alle anderen Distributionen es geschafft ohne auszukommen?
Der 2.96 war nur der Versuch, sich möglichst inkompatibel zum Rest zu machen, um Pfründe zu sichern. Nicht mehr, nicht weniger.
Du wilslt Beweise, daß es uohne 2.96 ging?
Gut, schau dir Suse, Debian, slackware oder jede andere Nicht-Redhat-Distribution an. Die kamen ALLE ohne aus.
Na los - welche Hardware brauchte den 2.96?
Welcher Kernel?
Welche Software?
Nenn mir eine.
Die Einen beschweren sich, wenn ein Desktop nicht "gescheit" integriert, sondern im Originalzustand belassen wurde. Die Anderen beschweren sich, wenn der Distributor eben genau das gemacht hat.
Man soll sich bei RH nicht umgewöhnen müssen, wenn man innerhalb des Standard-GNOME-Desktops mal ne KDE-Anwendung startet: Einzel- vs. Doppelklick usw.
Den Grund würde ich gern wissen. War es die Angst, daß der bessere KDE ihren geliebten gnome zu sehr naß macht oder doch was anderes?
Aber das wird man wohl nie erfahren.
warum sollte man zwei so unterschiedliche Werke gleich aussehen lassen?
Wenn du dir einen Porsche kaufst, reißt du doch auch nicht die Karosserie runter und klatscht die eines Golfs dran, oder?
Das war nichts weiter, als der eklige Versuch RedHats, KDE zu schaden.
Damit man sich z.B. in Sachen Doppel- vs. Einzelklick nicht umgewöhnen muss, wenn man in GNOME eine KDE-Anwendung startet. Ich merks ja schon, wenn an Windows gewöhnte im Konqueror Dateien per Doppelklick öffnen und die entsprechende Anwendung dann zweimal startet und sich die Leute drüber aufregen. Wenn das jetzt _innerhalb_ einer Oberfläche passiert, ists noch nerviger.
| Wenn du dir einen Porsche kaufst, reißt du doch auch nicht die Karosserie runter und klatscht die eines Golfs dran, oder?
Der Vergleich hinkt. Denn demnach dürfte man unter GNOME niemals K3b und unter KDE niemals GIMP starten. Da dies aber funktioniert und sich manche nicht auf die Anwendungen eines Desktops beschränken wollen, da es für das jeweils andere Toolkit in manchen Punkten bessere Anwendungen gibt, sollte man nicht gleich dutzende Look & Feels _gleichzeitig_ haben.
Ich war ne zeitlang KDE Maintainer einer sehr bekannten Distribution, ich weis mit Sicherheit mehr über solche Sachen als du:-)
>>>Abgesehen davon wird das neue Gnome auch einiges an Fehlerkorrekturen mitbringen
Hast du dir schon mal ein RPM Specfile angesehen, schon mal gesehen, wie viele Patches da drin sind z.B. Patches von Entwicklerzweigen ob KDE oder Gnome, solche Patches können auf einmal Probleme verursachen wenn man die mit einer neuen Programmversion mixt, da heißt es nochmal jeden Patch checken ob notwendig oder nicht und dann ordentlich testen, RedHat hat genauso wenig wie andere ein plain Gnome oder KDE im Einsatz von daher kannste da nicht sofort sagen, dass das alles zusammenspielt. Es ist nunmal in jeder ordentliche Firma so, dass man nach ner Testphase und Stabilisierungsphase keine Neuerungen mehr einfließen lässt, egal wie trivial manche Sachen scheinen.
Setze selbst fast ausschließlich Debian ein, aber die Releasezyklen sind ein schlechter Witz und mit Sachargumenten nicht mehr zu rechtfertigen. Fazit: ein flotter Release (wohlgemerkt: Distribution - die eigentlich Software ist ja schon stabil) und Distributionsstabilität widersprechen einander nicht.
Wenn das so ist (warum sagst du nicht einfach um welche Distribution es sich handelt), magst du da sicherlich Recht haben. Die Frage ist doch, was hast du da genau gemacht? Nur die Pakete zusammengeschnürt, oder steckst du auch im KDE Code drinn? Da Red Hat sich stark im Gnome Projekt engagiert bin ich davon überzeugt, dass die Jungs dort auf dem Laufendem sind und ziemlich genau abschätzen können, was da in wie weit die Stabilität der Distribution beeinträchtigen könnte. Mal abgesehen davon schweigt sich der Artikel ja über die neuen Funktionen aus, und dass RH keine Entwicklungsversion von Gnome ins Release packen will halte ich ja wol für selbstverständlich.
Ich entwicke Hardware und embedded Software für Mess-, Steuer-, und Regelsysteme, hat zwar mit PC Programmierung wenig zu tun, aber der Projektablauf dürfte in etwa identisch sein. Bei meinem letzten Hardwareprojekt ist mir ne Stunde bevor das Layout in die Vertigung ging noch eingefallen, dass ich ja noch ein paar Messpunkte und die zweiten CAN + RS232 Schnittstellen des Controllers (obwol nicht benötigt) zugänglich machen könnte. Also das Layout noch schnell entsprechend angepasst und ab in die Vertigung damit. Warum ich das so einfach mal flott tuen konnte? Weil ICH die Platine entwickelt habe und deshalb genau wusste, dass diese Änderungen die Funktion der restlichen Schaltung auf keinen Fall beeinflussen konnten. Auf nen anderen (besseren) Schaltregler oder DAC währe ich hingegen so kurz vorm Termin nicht mehr umgestiegen.
Dies nur mal als Beispiel. Mir geht es auch nicht darum, hier deine Kompetenz anzuzweifeln, ich kann es nur nicht mehr lesen, wenn hier andauernd auf solch oberflächlicher Grundlage die Kompetenz professioneller Entwickler in Frage gestellt wird. Bisher zumindest ist Red Hat eher durch Qualität aufgefallen. Manchmal komm ich mir hier so vor wie in ner Kneipe, wo ein Länderspiel übertragen wird, da sitzen auch immer ne menge Experten, die alles Besser wissen als die Spieler, der Schirie und die Trainer
Jo sowas darfst du bei deinen Geräten/Software evtl. machen, in der Automobilindistrie oder Luftfahrtindustrie, Mobilgeräte dürftest du z.B. sowas nicht, wenn du da eine Änderung vornimmst musst du wieder das komplette Prüfprogramm durchziehen.
Meinetwegen macht RedHat sowas und darf sich dann auch zu den Distributionen zählen, die instabil sind etc.
Klar gibts bei RedHat Leute, die überall drinstecken, aber auch die machen Fehler und du findest auch massenweise Leute die dir von ätzenden Bugs in Fedora erzählen können. Hast du schon mal in ner richtigen Firma Software entwickelt?
Selbst bei meiner eigenen Software würde ich nicht gegen Ende der Testphase neue Features einfließen lassen und ich denke, dass ich bei so einer Anwendung auch im Code drin stecke. Aber es ist nunmal gutes Qualitätsmanagement in der Softwareentwicklung, dass man sich an gewisse Regeln hält.
kann jemand was dazu sagen, wie Fedora auf PPC (G4) ist? Debian rennt ja
ganz gut. Ubuntu als live-CD ist auch schnell getestet und hat einen
guten Eindruck hinterlassen. Um Fedora mal anzusehen, will ich aber nicht
gleich alles installieren... Kann jemand vielleicht seine Erfahrung im
Vergleich zum debian sagen ...