CentOS ging leider im Ubuntu-Hype bisher ziemlich unter. Obwohl die Update-Politik das beste aus Debian bietet, und auch mal neue Pakete integriert. Niemand muss also 7 Jahre z.B. mit einem zu Tode gepatchten Uralt-Browser arbeiten.
Der Vorlaeufer (Red-Hat 9) war Anfang des Jahrtausends die einzige Distri, die auf den damals rein Windows-basierten nVidia Maschinen auf Anhieb lief.
Da ich seit Mai 2007 auf den PC angewiesen bin, musste ich zwangsweise auf Windows ausweichen, beobachte aber den Linux-Markt immer noch sehr genau.
CentOS ist eine der wenigen Distris, die die Stabilitaet eines Server-OS mit der Benutzerfreundlichkeit von Gnome oder KDE verbindet.
Ach quatsch, CentOS kann es mit Ubuntu in 1000000 Jahren nicht aufnehmen.... .... .... ! ...... ..... ! ... !!
Mal im ernst: CentOS baut auf Red Hat auf, das einfach beim Release schon gut getestet ist. Das ist so, und auch gut so. Ubuntus LTS sind beim Release oft nicht fehlerfrei, das stimmt. Allerdings sind sie aktueller. Gibt man dem LTS nach dem Release 1-2 Monate zur stabilitierung sind sie danach probklemlos nutzbar, und auch immernoch nicht veraltet.
Ich hätte nichts dagegen wenn ein LTS Release vom ersten Tag an perfekt wäre, bei 3-5 Jahren Nutzungszeit kann ich aber auch die 1-2 Reife abwarten. Man muss sowieso bei ernsthaft genutzen Systemen vorher prüfen ob ein Upgrade zu problemen führt, und schwups ist dieser Zeitraum auch schon vorrüber.
Ich nutze Ubuntu sehr viel im Alltag, und speziell die LTS Release sind nach der angesprochenen Reifungszeit auf dauer sehr gut nutzbar.
Bei CentOS fängt das Gefrickel an, wenn man einen Desktop a la Ubuntu mit Universe und Multiverse haben möchte. Hierzu muß man allerdings sagen, dass CentOS bzw. RHEL dafür primär nicht entwickelt wurden. Nur einmal einen möglichen Weg als Beispiel: Bei Dag Wieers vorbeischauen, das erforderliche rpmforge-release-Paket installieren und vor allem die FAQ lesen. Danach z.B. Apt und Synaptic hinzuinstallieren und vor allen Dingen kontrollieren, dass das schon auf dem System befindliche Yum alles mitbekommt. Eine weitere Hürde: Manchmal verhindert unter CentOS 5.x das aktivierte SELinux den Start beliebter Programme, weil letztere Dinge tun, die zu Sicherheitsproblemen führen können. Ein Beispiel ist Torcs 1.3.0, so wie man es bei Sourceforge herunterladen kann. Das Problem sollte dann so angegangen werden, dass man SELinux nicht abschaltet. So, nun einmal ehrlich: Ist CentOS eine Alternative für Newbies oder Nutzer, die sich noch nicht so gut mit RedHat/Fedora-Systemen auskennen? Wohl eher nicht.
ich weis zwar nicht was ihr für probleme imme mit selinux habt?gut früher in der 4x von centos war es echt schlimmm aber es hat sich stark verbessert von der benutzerfreundlichkeit und vorallen einsteigerfreundlicher geworden.
Nicht "ausflippen". Ich habe ein konkretes Beispiel genannt. SELinux stoppt den Start der erwähnten Torcs-Binary. Warum, kannst du hier nachlesen: http://people.redhat.com/drepper/textrelocs.html
Warum sollte man das zulassen? Siehe den Text unter obigem Link. Die betreffende Binary wird dann nicht benutzt, fertig. Der Sinn von SELinux besteht nicht darin, dass man seine Warnungen letztlich komplett ignoriert.
Und worüber beschwerst Du Dich dann? Du hattest beklagt, dass SELinux so kompliziert und CentOS "Gefrickel" sei - jetzt auf einmal das Gegenteil und torcs ist Schuld. Entscheide Dich!
Ich habe oben beschrieben, wann es Gefrickel geben kann: "Bei CentOS fängt das Gefrickel an, wenn man einen Desktop a la Ubuntu mit Universe und Multiverse haben möchte. Hierzu muß man allerdings sagen, dass CentOS bzw. RHEL dafür primär nicht entwickelt wurden." Logischerweise gibt es kein Gefrickel, wenn man bei den mitgelieferten CentOS-Paketen bleibt.
Die SELinux-Geschichte hat damit überhaupt nichts zu tun. Und ja, der ursprüngliche Binary-Ersteller ist "schuld". Wenn Du nicht verstehst, was es mit Text Relocations auf sich hat, dann kann ich Dir auch nicht helfen.
Ich habe oben beschrieben, wann es Gefrickel geben kann: Nicht kann, sondern Deinem Beitrag zu folge zwangsläufig geben muss.
Die SELinux-Geschichte hat damit überhaupt nichts zu tun. Dann solltest Du sie nicht in diesem Zusammenhang nennen und als "eine weitere Hürde" bezeichnen.
Wenn Du nicht verstehst, was es mit Text Relocations auf sich hat, dann kann ich Dir auch nicht helfen. Ich verstehe es sehr wohl, aber wenn ich allen Programmen Text Relocation verweigern würde, könnte ich kein SELinux mehr nutzen. Ich sehe nichts Schlimmes daran, ausgewählten Anwendungen, deren Herkunft mir bekannt ist, Text Relocation zu erlauben.
Ich habe nirgendwo etwas von "müssen" geschrieben.
SELinux ist eine Hürde. Bei Text Relocation-Problemen sollte auf jeden Fall der Autor auf den Fehler aufmerksam gemacht werden.
"aber wenn ich allen Programmen Text Relocation verweigern würde, könnte ich kein SELinux mehr nutzen" Das führt im Extremfall aber dazu, dass SELinux zwar eingeschaltet ist, aber dann doch nicht wirklich benutzt wird. Bedenke bitte, dass auch das RHEL-Sicherheitskonzept ein eingeschaltetes und voll funktionsfähiges SELinux voraussetzt. Aus manchen Mitteilungen zu Sicherheitsupdates geht hervor, dass SELinux auf einem RHEL-Standardsystem das Ausnutzen des betreffenden Fehlers verhindert hat. Zwischen den Zeilen kann man lesen, dass man deshalb eigentlich gar nicht hätte patchen müssen. Wegen der vermutlich noch vorhandenen SELinux-Ausschalter-Admins macht man es halt doch. Aber allerhöchste Priorität hat so etwas wohl nicht mehr.
Pulseaudio ist teilweise wirklich ziemlich vergurkt, vor allem die Art und Weise, wie manche Distros Pulseaudio implementieren. Aus dieser Meldung über eine schwere Pulseaudio-Sicherheitslücke http://seclists.org/bugtraq/2009/Jul/0116.html geht u.a. hervor, dass einige Distros - auch Ubuntu 9.04 - die Pulseaudio Binary mit dem SUID bit versehen. Absolut grausig: Wenn cdrecord das macht, dann meckern alle, aber Pulseaudio ... Der Workaround: As a temporary workaround, remove the SUID bit from the PulseAudio binary. $ chmod u-s `which pulseaudio`
Bei CentOS fängt das Gefrickel an, wenn man einen Desktop a la Ubuntu mit Universe und Multiverse haben möchte. Wieso das denn? Einfach EPEL und RPMFusion (nicht RPMforge!) aktivieren und schon hast Du alles. Und im Gegensatz zu Ubuntu auch mit Updates über die gesamte Dauer eines Releases. Bei Ubuntu gibt es den Support für Multiverse und Universe nur während des "Desktop LTS", nicht während des "extented server support" - und das, obwohl sich in diesem beiden Repositories existenzielle Pakete auch für den Server befinden, für die dann nichteinmal mehr Sicherheitsupdates bereitgestellt werden. Canonical leistet im Grunde genommen nur 3 Jahre LTS-Support und nicht 5, wie sie gerne behaupten.
Ist CentOS eine Alternative für Newbies oder Nutzer, die sich noch nicht so gut mit RedHat/Fedora-Systemen auskennen? Wohl eher nicht. Das will es aber nach eigenem Selbstverständnis auch gar nicht sein. Abgesehen davon ist CentOS meiner Erfahrung nach sehr gut Newbie-tauglich, denn grade Newbies verzweifeln schon an den Kinderkrankheiten eines frischen Releases. Und die hat man bei CentOS eben grade nicht, da es auf der stabilen Basis von RHEL aufbaut.
"Canonical leistet im Grunde genommen nur 3 Jahre LTS-Support und nicht 5, wie sie gerne behaupten."
Canonical leistet für den Main von Ubuntu Server LTS sehr wohl 5 Jahre Support, und dort befinden sich alle wichtige Pakete eines LAMP Systems. Sie behaupten zudem nicht für die Desktop Version 5 Jahre Support zu leisten. Geh auf die Ubuntu HP. Download und schau auf die Datumsangaben für den Support der LTS Version. Du siehst das die Desktop version nur 3 Jahre Support hat.
Canonical leistet für den Main von Ubuntu Server LTS sehr wohl 5 Jahre Support, und dort befinden sich alle wichtige Pakete eines LAMP Systems. Wer sagt, dass Server immer nur LAMP Systeme sein müssen? Ich hatte ja unten schon das Beispiel eines Tomcat-Servers genannt, dessen VM proprietär und deshalb nicht in main ist. Oder vielleicht will ich ja auch ein VCS auf dem Server laufen lassen, aber halt: Alle wichtigen Pakete für Git, SVN, RCS etc liegen in Multiverse. Von Git beispielsweise sind grade mal git-core und gitk in main, der Rest in universe. Liste lässt sich beliebig fortsetzen.
Sie behaupten zudem nicht für die Desktop Version 5 Jahre Support zu leisten. Aber auch beim Server kann keine Rede davon sein, solange elementare Pakete wie console-data (locales für die shell) in universe sind.
Nachtrag, zurück zum Tomcat Server: Man braucht noch nicht mal eine proprietäre JVM zu haben, sogar openjdk-6-jdk ist in universe und wird nur 3 Jahre unterstützt.
"Wer sagt, dass Server immer nur LAMP Systeme sein müssen? "
Wer hat gesagt das sie es sein müssen? Du kannst deine Liste wie du magst fortsetzen, aber was tut das zur Sache? Ubuntu bietet für Main 5 Jahre Support. Jeder kann nachsehen was drinen ist, und das akzeptieren oder nicht. Oftmals wird in Diskussionen behauptet Main sei für viele nicht ausreichend, aber viele nutzen eben typische LAMP Situationen (es sind aber nicht nur lamp pakete enthalten!) und damit ist es für viele dann eben doch ausreichend. Dein Beispiel RCS verstehe ich nicht. Ist da der letzte Release nicht 8 Jahre her? Was erwartest du dort an Änderungen die gepflegt werden müssen?
Bei dem Rest muss man sich entscheiden was man möchte.
"Aber auch beim Server kann keine Rede davon sein, solange elementare Pakete wie console-data (locales für die shell) in universe sind."
Abgesehen davon das ich nicht weiss nach welchen Regeln Ubuntu die Pakete einteilt, sehe ich auch hier wieder nicht warum es in Main sein sollte. Was genau erwartest du in dem Paket das eine zusätzliche Pflege erfordert? Ich habe mir die Changelog angeschaut von Ubuntu, ich konnte nichts finden was Sicherheitsrelevant war.
Es kann ja nicht die Anforderung sein das es einfach ein beruhigendes Label auf ein Paket gibt, und alle sind glücklich.
Wer hat gesagt das sie es sein müssen? Du selbst hattest die Gleichung Server == LAMP aufgemacht.
Oftmals wird in Diskussionen behauptet Main sei für viele nicht ausreichend, aber viele nutzen eben typische LAMP Situationen (es sind aber nicht nur lamp pakete enthalten!) und damit ist es für viele dann eben doch ausreichend. Und was ist mit dem Beispiel Tomcat, das ich schon 2 mal gebracht habe? In meinen Augen eine absolut typische Serveranwendung.
Dein Beispiel RCS verstehe ich nicht. Ist da der letzte Release nicht 8 Jahre her? Was erwartest du dort an Änderungen die gepflegt werden müssen? Der letzte Release ist sogar von 1995 soweit ich weiß. Trotzdem erwarte ich, dass ein Sicherheitsproblem gefixt wird, wenn es gefunden ist. Was ist denn mit meinen anderen Beispielen wie Git und SVN?
Abgesehen davon das ich nicht weiss nach welchen Regeln Ubuntu die Pakete einteilt, sehe ich auch hier wieder nicht warum es in Main sein sollte. Die Sprache an der Konsole umzustellen ist eine grundlegende Funktion eines Rechners, also gehört es nach main.
Es kann ja nicht die Anforderung sein das es einfach ein beruhigendes Label auf ein Paket gibt, und alle sind glücklich. Doch, genau darum geht es einem (zahlenden) Enterprise-Kunden, genau das ist der Sinn einer Enterprise-Distribution.
Für Nutzer, die "nur" Office, Internet und Email benötigen, ist CentOS ideal, keine Frage. Selbst proprietäre Software wie der Flash Player ist auch sofort hinzu installiert, da Adobe für RHEL ein eigenes Repo bereit hält.
"Einfach EPEL und RPMFusion (nicht RPMforge!) aktivieren und schon hast Du alles."
Von "einfach" für einen Newbie kann hier keine Rede sein.
"denn grade Newbies verzweifeln schon an den Kinderkrankheiten eines frischen Releases"
Das will ich nicht bestreiten. Aber Newbies verzweifeln eher daran, dass sie nicht out-of-the-box ihre MP3-Sammlung oder die neuesten Flashfilme abspielen können.
Von "einfach" für einen Newbie kann hier keine Rede sein. Was soll schwer daran sein, sich ein Paket herunterzuladen und es per Mausklick zu installieren?
Aber Newbies verzweifeln eher daran, dass sie nicht out-of-the-box ihre MP3-Sammlung oder die neuesten Flashfilme abspielen können. Wir reden hier immer noch über CentOS und damit über Enterprisesysteme. MP3-Dateien dürften da keine große Rolle spielen.
Mal im ernst: CentOS baut auf Red Hat auf, das einfach beim Release schon gut getestet ist. Das ist so, und auch gut so. Ubuntus LTS sind beim Release oft nicht fehlerfrei, das stimmt. Allerdings sind sie aktueller. "Aktuell" ist eine Sache der Definition. Der Desktop ist bei einem RHEL zwar meist recht alt, aber unter der Haube befinden sich Backports ohne Ende. Im Laufe der Zeit ändert sich die Sache durch die Pointreleases und das "alte" RHEL/CentOS kommt besser mit neuer Hardware zurecht als das "neue" Ubuntu.
Gibt man dem LTS nach dem Release 1-2 Monate zur stabilitierung sind sie danach probklemlos nutzbar, und auch immernoch nicht veraltet.
und warum muss das Produkt dann beim Kunden reifen? Warum nicht einfach noch die 1-2 Monate warten?
""Aktuell" ist eine Sache der Definition. Der Desktop ist bei einem RHEL zwar meist recht alt, aber unter der Haube befinden sich Backports ohne Ende."
Dennoch ist auch mit Backports ein deutlicher Delay zu erkennen.
"Im Laufe der Zeit ändert sich die Sache durch die Pointreleases und das "alte" RHEL/CentOS kommt besser mit neuer Hardware zurecht als das "neue" Ubuntu."
Das ist etwas das dir keiner am Ende garantieren kann. Zwar werden die Red Hat Release gut gepflegt, daran gibt es keinen Zweifel, aber ob am Ende wirklich eine benötigte Hardware unterstützt wird kann niemand sagen. Allerdings, und das stimmt auch wiederum, hat Ubuntu das selbe Problem. Wer aktuelle Hardware perfekt unterstützt haben will muss zwangsweise irgendwann mit der Zeit gehen.
"und warum muss das Produkt dann beim Kunden reifen?"
Wo habe ich geschrieben das es so sein MUSS? Es ist lediglich die Situation wie sie ist die ich beschrieben habe. Canonical entscheidet sich aktuell gerne dafür das die Release pünktlich erscheinen. Wer stabilität will wartet dann bis sicher ist das auch wirklich alles gefunden wurde. Es gibt Release bei denen ist das praktisch sofort der Fall, bei anderen nicht. Wer wartet ist aber immer auf der sicheren Seite.
Bei CentOS wartest du zudem auch eine Zeit lang bis du es nutzen kannst, wenn hier auch weil sie nicht sofort einen Release paralell zu Red Hat bringen können. Gerne auchmal ebenfalls 1-2 Monate. Daher ist es nicht wirklich ein Problem beim Vergleich CentOS/Ubuntu (ist ja eine CentOS News) wann man es nutzen kann. Bei Ubuntu ist es Canonicals ungedult, bei CentOS der natürliche Delay einer Distrie die von dem Release einer anderen abhängt.
Zwar werden die Red Hat Release gut gepflegt, daran gibt es keinen Zweifel, aber ob am Ende wirklich eine benötigte Hardware unterstützt wird kann niemand sagen. Doch, Red Hat kann Dir das sagen, dafür werden Enterprise Linuxe ja zertifiziert, auch Ubuntu LTS soweit ich weiß.
Wer wartet ist aber immer auf der sicheren Seite. Gut, nehmen wir mal an, ein Unternehmenskunde will auf Nummer sicher gehen und wartet ein halbes Jahr nach dem Release. Damit verkürzt sich die Nutzungsdauer von 3 auf 2,5 Jahre.
Wer stabilität will wartet dann bis sicher ist das auch wirklich alles gefunden wurde. Und das kann meiner Ansicht nach nicht in einem Monat zwischen RC und Release passieren und auch nicht in dem einen Monat danach, von dem Du sprichst. Ich halte eine Zeit von mind. einem Jahr für notwendig.
War zweifellos ein sau dämmlicher Fehler. Allerdings wenn es das einzige ist was die einfällt, dann ist es langweilig. Über diesen Fehler wissen alle inzwischen mehr als genug.
Ich sehe ihn auch durchaus in manchen punkten positiv, er hat die Aufmerksamkeit der User erhöht, und den glauben geschwächt das man sich immer und komplett auf andere Menschen verlassen kann, die man zudem meist weder kennt noch überhaupt jemals gesehen hat
Übrigens ist es klar das CentOS den bug nicht hatte. Er wurde ja nuneinmal von Debian gemacht, wodurch auch Ubuntu zum Opfer viel. CentOS hat dafür jeden Fehler den Red Hat macht mit an Bord.
Übrigens ist es klar das CentOS den bug nicht hatte. Er wurde ja nuneinmal von Debian gemacht, wodurch auch Ubuntu zum Opfer viel. CentOS hat dafür jeden Fehler den Red Hat macht mit an Bord. Nur dass das erheblich weniger sein dürften. Nichts gegen Debian, aber bei Red Hat arbeitet eine ganze Abteilung an Sicherheitsfragen, bei Debian nur eine Handvoll Leute. Und Red Hat hat eine andere Unternehmensphilosophie: Patches, die von upstream nicht akzeptiert werden, kommen auch nicht in RHEL oder Fedora. Damit wäre der OpenSSL bug schon mal nicht passiert.
Das könnte jemand gerne mal nachforschen. Ich bezweifle es allerdings. Am Ende dürften sie auf das gleiche hinauslaufen. Aber wer mal eine Statistik erstellen will, das wäre durchaus interessant.
"Damit wäre der OpenSSL bug schon mal nicht passiert."
Der Bug war einfach allgemein bescheuert. Er hätte dort garnicht gefixt werden dürfen. Sau dummes, extrem peinliches und kaum zu etragenes aber sehr menschliches versagen
Allerdings beruhigt es mich auch jedesmal über diesen Bug zu lesen. Immerhin zeigt es das es ansonsten sehr ruhig ist bei Debian in solchen Themen. Ähnlich ist es wohl bei Red Hat mit den nicht gerade Imagefördernden Serveinbruch gewesen. Wenn ich mich nicht irre haben sie doch damals sogar Pakete signiert und verteilt bekommen, oder?
So genau weiß man das ja nicht. Man sieht hier auch direkt den Unterschied zu Debian: Debian betreibt in solchen Fällen nackte und radikale Offenheit, unabhängig davon, welche "Peinlichkeiten" dadurch ans Licht kommen (können).
Von Felix Schwarz am Sa, 1. August 2009 um 18:33 #
Fedora war eigentlich auch ziemlich offen, wenn auch die Veröffentlichung aus bestimmten Gründen erst spät kam: https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html
Übrigens wurden weder bei Fedora noch bei Red Hat manipulierte Pakete über die Standard-Mechanismen ausgeliefert. Bei Red Hat musste man sich die manipulierten Pakete schon umständlich über das Web manuell runterladen...
Der Bug war einfach allgemein bescheuert. Er hätte dort garnicht gefixt werden dürfen. Der ist ja auch nicht in Debian gefixed worden, sondern verhunzt. Und das bei RHEL eben nicht passieren können, wie ich eben schon erläutert habe. Debian leidet darunter, dass sie zu wenig Manpower für Sicherheitsupdates haben. Wenn einer mal im Urlaub ist, merke ich das auf meine Stable jedes Mal daran, dass es auf einmal wenig bis keine Updates mehr gibt.
Ähnlich ist es wohl bei Red Hat mit den nicht gerade Imagefördernden Serveinbruch gewesen. Sowas ist nie förderlich und Debian hatte mehrere, ich kann mich an mindestens 3 erinnern.
Wenn ich mich nicht irre haben sie doch damals sogar Pakete signiert und verteilt bekommen, oder? Du irrst Dich, siehe https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html
Von Felix Schwarz am Sa, 1. August 2009 um 18:27 #
Und Red Hat hat eine andere Unternehmensphilosophie: Patches, die von upstream nicht akzeptiert werden, kommen auch nicht in RHEL oder Fedora.
Falsch (Beispiel: Xen bis Fedora ... Jede Distribution muss immer mal wieder bestimmte Patches einbauen, die nicht von Upstream akzeptiert werden. Und an Fedora arbeiten inzwischen mehr Freiwillige als Red Hat-Mitarbeiter.
Falsch (Beispiel: Xen bis Fedora ... Du vergisst, das Fedora zu dem Zeitpunkt de facto der Upstream für Xen war.
Jede Distribution muss immer mal wieder bestimmte Patches einbauen, die nicht von Upstream akzeptiert werden. Wieso das? Meiner Ansicht nach sollte man solche Patches wo es geht vermeiden.
Und an Fedora arbeiten inzwischen mehr Freiwillige als Red Hat-Mitarbeiter. Brauchst Du mir nicht zu sagen, ich bin einer von ihnen. Zahlenmäßig gibt es tatsächlich mehr Leute aus der Community als RH-Mitarbeiter, aber die Hauptamtlichen arbeiten Vollzeit. Und selbst wenn mehr Freiwillige an Fedora arbeiten, was ist daran schlimm? Das zeigt doch, wie offen die Distribution ist und das RH eben grade nicht (mehr) die Macht hat. Ähnlich ist es bei CentOS: Basiert auf RHEL, aber ist voll in der Hand der Community - und das ist auch gut so.
Äääh, Red Hat Linux 9 als Vorgänger von CentOS zu bezeichnen, ist doch wohl nur ein Witz, oder? RHL 9 war der direkte Vorgänger von Fedora Core 1, das zu Beginn des Entwicklungszyklus tatsächlich noch Version 9.8X trug und erst dann umgenannt wurde, als klar war, dass es kein Red Hat Linux 10 werden würde.
Hingegen gab es den Red Hat Linux Advanced Server 2.1 schon parallel zu Red Hat Linux 7.2 und 7.3. Die Umbenennung in Red Hat Enterprise Linux (RHEL) erfolgte später. Sogar eine Enterprise Fassung von Red Hat Linux 6.2 gab es.
Re: Waere schade..... Gesendet von Susanne Bauer am Fr, 31. Jul um 9:53
Äääh, Red Hat Linux 9 als Vorgänger von CentOS zu bezeichnen, ist doch wohl nur ein Witz, oder? RHL 9 war der direkte Vorgänger von Fedora Core 1, das zu Beginn des Entwicklungszyklus tatsächlich noch Version 9.8X trug und erst dann umgenannt wurde, als klar war, dass es kein Red Hat Linux 10 werden würde.
Hingegen gab es den Red Hat Linux Advanced Server 2.1 schon parallel zu Red Hat Linux 7.2 und 7.3. Die Umbenennung in Red Hat Enterprise Linux (RHEL) erfolgte später. Sogar eine Enterprise Fassung von Red Hat Linux 6.2 gab es.
Hi ,
Da sich ein Privatanwender damals wohl kaum die Server Version von Red-Hat leisten konnte, wollte ich mit RH 9 nur andeuten, wie gut diese Systeme schon damals waren.
Von Marcus Moeller am Do, 30. Juli 2009 um 18:56 #
Ich denke das Lance schon seit laengerem keine Rolle mehr im Projekt spielt. Aergerlich ist das bei Ihm Spenden und Werbeeinnahmen zusammengeflossen sind.
Auch Dag's Kritik zielte sicherlich nicht (ausschliesslich) auf die fehlende Kommunikation mit Lance aus.
Das Projekt und die gesamte Entwicklung ist nach aussen hin nicht transparent. Es bestehen Bemuehungen dies zu verbessern, bisher aber ohne sichtlichen Erfolg.
Hierzu gehoert die Dokumentation des Build Prozesses, die Oeffnung des Wikis, klare Definition von Verantwortlichkeiten und der Umgang mit neuen Maintainern.
Ich persoenlich werde auch in Zukunft versuchen dazu beizutragen das dies moeglich wird.
Für mich ist CentOS gegenwärtig für produktiven Einsatz (auch zu Hause) die beste Distribution. Gängige Distributionen wie openSUSE, Ubuntu usw. weisen einfach viel zu kurze Support-Zeiten auf. Was nützt eine brandaktuelle Distribution, die mich breits nach ca. 2 Jahren zu einer Neuinstallation nötigt, weil keine Updates mehr dafür angeboten werden? Ich will mit einem System arbeiten und nicht ständig neu installieren müssen. Da sind 5 Jahr für mich der minimale Zeitraum, in dem Support geleistet werden sollte. Daran scheitert selbst Ubuntu LTS. Bis dieses Jahr habe ich sogar noch ein SuSE 9.2 eingesetzt, dass noch einwandfrei lief. In Foren wurde ich dafür jedoch schon gefragt, ob mich damit noch ins Internet traue. Nach einiger Zeit der Suche bin ich dann auf CentOS gestossen und begeistert von dem Support bis 2014! Darüber hinaus läuft das System bislang ohne Probleme. Nach dem Hinzufügen von einigen Paketrepositories ist auch Multimedia kein Problem. Damit habe ich genau dass, was ich zum Arbeiten benötige: ein stabiles, zuverlässiges System, dass wenn ich es einmal gemäss meinen Bedürfnissen eingerichtet habe über mehrere Jahre zuverlässig laufen kann.
Daher fände ich es sehr, sehr schade, wenn CentOS nicht weiterbestehen würde.
"Da sind 5 Jahr für mich der minimale Zeitraum, in dem Support geleistet werden sollte. Daran scheitert selbst Ubuntu LTS."
Ich bin mir nicht ganz sicher wie du das meinst. Immerhin ist der Supportzeitraum für die LTS ja 5 Jahre. Ich kann allerdings nachvollziehen das du noch längeren Support vorteilhaft findest.
Ubuntu bietet keine 5 Jahre Support, sondern nur 3. Lediglich die Server-Version bietet die 5 Jahre, die nützen auf einem Desktop nun aber nicht besonders viel. Somit ist Ubuntu für mich komplett aus dem Rennen, da bietet mir Debian bereits mehr (btw. Debian läuft auf meinem Notebook, ich würde mir von Debian nur etwas länger gesicherten Support wünschen). Und wie angesprochen erachte ich 5 Jahre als das sinnvolle Minimum.
"Ubuntu bietet keine 5 Jahre Support, sondern nur 3. "
Das ist korrekt, ich hatte nicht erkannt das du es für Desktops suchst.
Auch für den Server gibt es bei Ubuntu im Grunde genommen nur 3 Jahre Support, warum habe ich oben schon erläutert. Nehmen wir mal an, ich habe einen tomcat mit einer proprietären JVM, die aus universe kommt. Für die bekommst Du nach 3 Jahren auch keinen Support mehr, nur für die Sachen aus dem "main"-repo.
Nimm Solaris, ist auch kostenlos und dort dauert ein Release Cycle 10 Jahre (kein Witz). Ansonsten ist CentOS schon ganz nett wenn es um den professionellen Bereich geht (durch die Kompatibilität mit RH läuft dort auch SAP, Oracle, ... ohne große Modifikationen). Auf meinem Desktop darf es aber ruhig ein bisschen aktueller sein (wobei mir das ständige Upgraden auch so ein bisschen auf den Nerv geht).
Als Server-System würde ich Solaris sicher in die engere Wahl ziehen. Aber auf meinem Desktop ist mir Linux dann doch lieber, da hier mehr Hardware unterstützt wird und einige Programme die ich benötige unter Solaris gar nicht verfügbar sind.
Ich habe im Moment verschiedene weitere Repositories hinzugefügt, über die ich meine bislang benötigten Pakete finden konnte: - epel von Fedora: http://fedoraproject.org/wiki/EPEL/FAQ - RPMForge: http://rpmforge.net - RPMFusion: http://rpmfusion.org/
Von CentOS gibt es noch diese Anleitung: How to setup multimedia on CentOS-5: http://wiki.centos.org/TipsAndTricks/MultimediaOnCentOS?highlight=(multimedia)
centos darf nicht untergehen, sonst habe ich auch ein großes problem.die ganzen betriebssysteme ersetzen,aber was würde man da nehmen?was die gleichen stärken wie das centos hat.
Sag das mal einem OSS-Programmierer der dass in seiner freizeit macht. Die sind doch alle auf einem Egotrip ... Heute war doch eine Meldung auf heise, Streß zwischen Torwalds und Cox. Ok, die sind festangestellt, am das Ego ist nicht kleiner ...
Ich habe auch nicht bestritten dass in kommerziellen Softwarefirmen es auch nicht zum Streit kommt. Nur sind viele OSS-Programmierer in ihrer Freizeit unterwegs, demzufolge werden eigene Interessen verfolgt. Will man aber etwas für die Allgemeinheit tun sollte man sein Ego runterschrauben. Ich habe Informatikprofessoren erlebt die sich in der Vorlesung selbst gefeiert haben, sie wären so toll weil sie mit 300 anderen Profs bei Bill Gates in einer Konverenz waren. So etwas wird den Studenten vorgelebt.
Ich selber bin Mathematiker, und solches Verhalten gibt es unter Mathe-Docs und -Profs nicht! Dies sind alles sehr höfliche und zurückhaltende Leute.
Also was ich schon in Software-Buden an Ego-Trips und politischen Machtspielchen erlebt habe, spottet jeder Beschreibung. Dagegen sind fast alle Open-Source-Projekte wirklich simple, klar und ehrlich.
fs
PS: Die Mathematiker waren auch bei uns meist bescheiden - allerdings kannte ich auch ein paar Ausnahmen, die auch sehr erfolgreich in der Einwerbung von Drittmitteln und der Optimierung ihrer Leistungskennzahlen waren...
> PS: Die Mathematiker waren auch bei uns meist bescheiden - allerdings kannte ich auch ein paar Ausnahmen, die auch sehr erfolgreich in der Einwerbung von Drittmitteln und der Optimierung ihrer Leistungskennzahlen waren...
Gegen Einwerbung von Drittmitteln ist ja erstmal nichts einzuwenden ... Ich habe mich für ein Uni-Leben entschieden, und wenn man da sein Ego nicht im Griff hat, kommt man nicht weit. Es erfordert eine Engelsruhe Übungen zu haleten und Fragen der Studenten zu beantworten, weil einem es selber klar ist, und machmal Fragen kommen wo man denkt ob die Studenten gepennt haben
Warum soll jemand, der Software der Allgemeinheit zur Verfügung stellt, nicht auch ein wenig egozentrisch sein.--- Viele OSS-Programmierer haben sich einen guten Namen gemacht und auch verdient. Schlecht ist es doch nur, wenn es dem Projekt und den Mitstreitern schadet.
> Schlecht ist es doch nur, wenn es dem Projekt und den Mitstreitern schadet.
Damit hast du doch schon selbst die Begründung geliefert. Ich finde OSS auch toll, aber man muss vernünftig miteinander umgehen. Meinen Studenten drücke ich auch ein Linux in die Hand und dann wird in Fortran mit gfortran und oktave anstelle von Matlab programmiert. Dies wäre nicht möglich wenn vor mir nicht jemand die Software geschrieben hätte.
Im übrigen, was jemand mit seiner Freizeit anstellt, ist sein Bier. Er hat dann in meinen Augen auch durchaus das Recht, etwas unverträglicher aufzutreten. Ist ja seine Freizeit. Andere wollen oder können nicht mit ihm zusammenarbeiten? Das ist sehr schade (wirklich!), aber es bleibt nach wie vor seine Freizeit, die er da verbrät.
Nun gut, jetzt kenne ich wenigstens eure Denkweise ... Ich unterrichte z.B. gern, und wir könnten es uns viel leichter machen. Nach dem Motto: "Hier ist eine Literaturliste, und in 5 Monaten ist die Prüfung." Das Dumme an der Geschichte ist, Bücher können Fragen nicht erklären.
Scientific Linux hat andere Probleme: 1. Es werden zusätzliche Features eingebaut, die für die Entwickler wichtig sind. Dadurch ist das System nicht mehr absolut RHEL-kompatibel, was sehr vielen CentOS-Nutzer wichtig ist. 2. Weil SL nicht einfach alle RHEL-Updates nehmen kann (eigene Features), ist auch der Supportzeitraum deutlich kürzer, was noch mehr Nutzern wichtig ist.
Den Fork sehe ich nicht so als Problem an, repräsentieren sind die genannten Unterzeichner praktisch das komplette, derzeit aktive CentOS-Team, d.h. das Wissen über die Infrastruktur etc. könnte mitgenommen werden. Immerhin sind die Probleme mit Lance schon länger bekannt (einige Jahre) und auch ein Grund dafür, warum nicht aggressiver um Spenden geworben wurde...
SL ist ein RHEL Clone wie CentOS mit dem Unterschied, dass einige unfreie Software in der Standard installation vorhanden ist. Es werden auch keine "Features" eingebaut die SL inkompatibel zu RHEL machen, ebenso werden Updates für das aktuelle SL 5.3 mindestens bis Oktober 2010 bereitgestellt, wenn nicht sogar für den Supportraum wie RHEL bis 2014.
Ich habe keine Aussage getroffen, sondern eine diesbezügliche Frage gestellt, w a r u m das so ist. Wenn Du in meinem Team arbeiten würdest, dann wärst du jetzt schon "geflogen".
Von Felix Schwarz am Sa, 1. August 2009 um 10:57 #
SL ist ein RHEL Clone wie CentOS mit dem Unterschied, dass einige unfreie Software in der Standard installation vorhanden ist. Es werden auch keine "Features" eingebaut die SL inkompatibel zu RHEL machen, ebenso werden Updates für das aktuelle SL 5.3 mindestens bis Oktober 2010 bereitgestellt, wenn nicht sogar für den Supportraum wie RHEL bis 2014.
1. Unfreie Software in der Standard-Distribution ist für mich ein sofortiges No-go. Und auch Red Hat separiert Non-Free+Free in RHEL sehr sorgfältig. 2. Man kann einfach Kernel-Module etc. aus der SL-Distribution installieren, die nicht in RHEL sind und damit das Betriebssystem inkompatibel machen. Gerade wenn man noch zusätzliche Kernel-Module für Hardware-Unterstützung braucht, möchte ich soweit wie nur irgendwie möglich mit RHEL übereinstimmen und nicht jedesmal schauen müssen, ob das jetzt immer noch RHEL entspricht... 3. "Mindestens bis 2010" ist etwas anderes als die Aussage "Was immer auch kommt, wir versuchen genauso lange Support bereitzustellen wie Reed Hat".
Danke für die Berichterstattung. Solche Interna kommen Otto-Normal nur selten zur Kenntnis. Ich werde erst einmal abwarten und voerst nicht auf ein vielleicht schon totes Pferd setzen.
Jedoch muss ich sagen das ich bei CentOS immerschon etwas bedenken hatte. In der Theorie klingt es toll, aber Theorie und Praxis sind nicht das selbe.
Aber wie gesagt, man sollte nichts zu früh totsagen. Genausogut könnte das Team jetzt erst recht zupacken, alles ins reine bringen, und einer besseren Zukunft entgegensehen. Vielleicht erkennen sie z.B. andere Distries mit ähnlichen, aber spezielleren Zielen (eben das genannte Scientific Linux) und arbeiten enger zusammen.
Von Felix Schwarz am Sa, 1. August 2009 um 10:52 #
Aber wie gesagt, man sollte nichts zu früh totsagen. Genausogut könnte das Team jetzt erst recht zupacken, alles ins reine bringen, und einer besseren Zukunft entgegensehen. Vielleicht erkennen sie z.B. andere Distries mit ähnlichen, aber spezielleren Zielen (eben das genannte Scientific Linux) und arbeiten enger zusammen.
Ich persönlich sehe bei CentOS keine direkte Gefahr: Alle aktiven Entwickler stehen hinter dem offenen Brief. Bei einem Fork/einer Fusion würden "nur" centos.org und die derzeitigen Mirrors/Gelder verloren sein. Das hätte natürlich einen großen Effekt für die Bekanntheit und das Marketing einer neuen Distribution, aber Benutzer müssten maximal die Yum-Repositories ändern und neue GPG-Keys importieren.
CentOS ging leider im Ubuntu-Hype bisher ziemlich unter. Obwohl die Update-Politik das beste aus Debian bietet, und auch mal neue Pakete integriert. Niemand muss also 7 Jahre z.B. mit einem zu Tode gepatchten Uralt-Browser arbeiten.
Der Vorlaeufer (Red-Hat 9) war Anfang des Jahrtausends die einzige Distri, die auf den damals rein Windows-basierten nVidia Maschinen auf Anhieb lief.
Da ich seit Mai 2007 auf den PC angewiesen bin, musste ich zwangsweise auf Windows ausweichen, beobachte aber den Linux-Markt immer noch sehr genau.
CentOS ist eine der wenigen Distris, die die Stabilitaet eines Server-OS mit der Benutzerfreundlichkeit von Gnome oder KDE verbindet.
Gruss goose
Abgesehen von Ubuntu.
Mal im ernst: CentOS baut auf Red Hat auf, das einfach beim Release schon gut getestet ist. Das ist so, und auch gut so. Ubuntus LTS sind beim Release oft nicht fehlerfrei, das stimmt. Allerdings sind sie aktueller. Gibt man dem LTS nach dem Release 1-2 Monate zur stabilitierung sind sie danach probklemlos nutzbar, und auch immernoch nicht veraltet.
Ich hätte nichts dagegen wenn ein LTS Release vom ersten Tag an perfekt wäre, bei 3-5 Jahren Nutzungszeit kann ich aber auch die 1-2 Reife abwarten. Man muss sowieso bei ernsthaft genutzen Systemen vorher prüfen ob ein Upgrade zu problemen führt, und schwups ist dieser Zeitraum auch schon vorrüber.
Ich nutze Ubuntu sehr viel im Alltag, und speziell die LTS Release sind nach der angesprochenen Reifungszeit auf dauer sehr gut nutzbar.
Hierzu muß man allerdings sagen, dass CentOS bzw. RHEL dafür primär nicht entwickelt wurden.
Nur einmal einen möglichen Weg als Beispiel:
Bei Dag Wieers vorbeischauen, das erforderliche rpmforge-release-Paket installieren und vor allem die FAQ lesen. Danach z.B. Apt und Synaptic hinzuinstallieren und vor allen Dingen kontrollieren, dass das schon auf dem System befindliche Yum alles mitbekommt.
Eine weitere Hürde:
Manchmal verhindert unter CentOS 5.x das aktivierte SELinux den Start beliebter Programme, weil letztere Dinge tun, die zu Sicherheitsproblemen führen können. Ein Beispiel ist Torcs 1.3.0, so wie man es bei Sourceforge herunterladen kann. Das Problem sollte dann so angegangen werden, dass man SELinux nicht abschaltet.
So, nun einmal ehrlich:
Ist CentOS eine Alternative für Newbies oder Nutzer, die sich noch nicht so gut mit RedHat/Fedora-Systemen auskennen?
Wohl eher nicht.
Ich habe ein konkretes Beispiel genannt. SELinux stoppt den Start der erwähnten Torcs-Binary. Warum, kannst du hier nachlesen:
http://people.redhat.com/drepper/textrelocs.html
Siehe den Text unter obigem Link.
Die betreffende Binary wird dann nicht benutzt, fertig.
Der Sinn von SELinux besteht nicht darin, dass man seine Warnungen letztlich komplett ignoriert.
"Bei CentOS fängt das Gefrickel an, wenn man einen Desktop a la Ubuntu mit Universe und Multiverse haben möchte.
Hierzu muß man allerdings sagen, dass CentOS bzw. RHEL dafür primär nicht entwickelt wurden."
Logischerweise gibt es kein Gefrickel, wenn man bei den mitgelieferten CentOS-Paketen bleibt.
Die SELinux-Geschichte hat damit überhaupt nichts zu tun.
Und ja, der ursprüngliche Binary-Ersteller ist "schuld".
Wenn Du nicht verstehst, was es mit Text Relocations auf sich hat, dann kann ich Dir auch nicht helfen.
Nicht kann, sondern Deinem Beitrag zu folge zwangsläufig geben muss.
Die SELinux-Geschichte hat damit überhaupt nichts zu tun.
Dann solltest Du sie nicht in diesem Zusammenhang nennen und als "eine weitere Hürde" bezeichnen.
Wenn Du nicht verstehst, was es mit Text Relocations auf sich hat, dann kann ich Dir auch nicht helfen.
Ich verstehe es sehr wohl, aber wenn ich allen Programmen Text Relocation verweigern würde, könnte ich kein SELinux mehr nutzen. Ich sehe nichts Schlimmes daran, ausgewählten Anwendungen, deren Herkunft mir bekannt ist, Text Relocation zu erlauben.
SELinux ist eine Hürde. Bei Text Relocation-Problemen sollte auf jeden Fall der Autor auf den Fehler aufmerksam gemacht werden.
"aber wenn ich allen Programmen Text Relocation verweigern würde, könnte ich kein SELinux mehr nutzen"
Das führt im Extremfall aber dazu, dass SELinux zwar eingeschaltet ist, aber dann doch nicht wirklich benutzt wird.
Bedenke bitte, dass auch das RHEL-Sicherheitskonzept ein eingeschaltetes und voll funktionsfähiges SELinux voraussetzt. Aus manchen Mitteilungen zu Sicherheitsupdates geht hervor, dass SELinux auf einem RHEL-Standardsystem das Ausnutzen des betreffenden Fehlers verhindert hat. Zwischen den Zeilen kann man lesen, dass man deshalb eigentlich gar nicht hätte patchen müssen. Wegen der vermutlich noch vorhandenen SELinux-Ausschalter-Admins macht man es halt doch. Aber allerhöchste Priorität hat so etwas wohl nicht mehr.
(jawohl, OHNE SELinux wäre das System sicherer gewesen...)
((und pulseaudio hat's auch MAL WIEDER völlig vergurkt))
Aus dieser Meldung über eine schwere Pulseaudio-Sicherheitslücke
http://seclists.org/bugtraq/2009/Jul/0116.html
geht u.a. hervor, dass einige Distros - auch Ubuntu 9.04 - die Pulseaudio Binary mit dem SUID bit versehen.
Absolut grausig: Wenn cdrecord das macht, dann meckern alle, aber Pulseaudio ...
Der Workaround:
As a temporary workaround, remove the SUID bit from the PulseAudio binary.
$ chmod u-s `which pulseaudio`
Wieso das denn? Einfach EPEL und RPMFusion (nicht RPMforge!) aktivieren und schon hast Du alles. Und im Gegensatz zu Ubuntu auch mit Updates über die gesamte Dauer eines Releases. Bei Ubuntu gibt es den Support für Multiverse und Universe nur während des "Desktop LTS", nicht während des "extented server support" - und das, obwohl sich in diesem beiden Repositories existenzielle Pakete auch für den Server befinden, für die dann nichteinmal mehr Sicherheitsupdates bereitgestellt werden. Canonical leistet im Grunde genommen nur 3 Jahre LTS-Support und nicht 5, wie sie gerne behaupten.
Ist CentOS eine Alternative für Newbies oder Nutzer, die sich noch nicht so gut mit RedHat/Fedora-Systemen auskennen?
Wohl eher nicht.
Das will es aber nach eigenem Selbstverständnis auch gar nicht sein. Abgesehen davon ist CentOS meiner Erfahrung nach sehr gut Newbie-tauglich, denn grade Newbies verzweifeln schon an den Kinderkrankheiten eines frischen Releases. Und die hat man bei CentOS eben grade nicht, da es auf der stabilen Basis von RHEL aufbaut.
Canonical leistet für den Main von Ubuntu Server LTS sehr wohl 5 Jahre Support, und dort befinden sich alle wichtige Pakete eines LAMP Systems.
Sie behaupten zudem nicht für die Desktop Version 5 Jahre Support zu leisten. Geh auf die Ubuntu HP. Download und schau auf die Datumsangaben für den Support der LTS Version. Du siehst das die Desktop version nur 3 Jahre Support hat.
Wer sagt, dass Server immer nur LAMP Systeme sein müssen? Ich hatte ja unten schon das Beispiel eines Tomcat-Servers genannt, dessen VM proprietär und deshalb nicht in main ist. Oder vielleicht will ich ja auch ein VCS auf dem Server laufen lassen, aber halt: Alle wichtigen Pakete für Git, SVN, RCS etc liegen in Multiverse. Von Git beispielsweise sind grade mal git-core und gitk in main, der Rest in universe. Liste lässt sich beliebig fortsetzen.
Sie behaupten zudem nicht für die Desktop Version 5 Jahre Support zu leisten.
Aber auch beim Server kann keine Rede davon sein, solange elementare Pakete wie console-data (locales für die shell) in universe sind.
Wer hat gesagt das sie es sein müssen? Du kannst deine Liste wie du magst fortsetzen, aber was tut das zur Sache? Ubuntu bietet für Main 5 Jahre Support. Jeder kann nachsehen was drinen ist, und das akzeptieren oder nicht.
Oftmals wird in Diskussionen behauptet Main sei für viele nicht ausreichend, aber viele nutzen eben typische LAMP Situationen (es sind aber nicht nur lamp pakete enthalten!) und damit ist es für viele dann eben doch ausreichend.
Dein Beispiel RCS verstehe ich nicht. Ist da der letzte Release nicht 8 Jahre her? Was erwartest du dort an Änderungen die gepflegt werden müssen?
Bei dem Rest muss man sich entscheiden was man möchte.
"Aber auch beim Server kann keine Rede davon sein, solange elementare Pakete wie console-data (locales für die shell) in universe sind."
Abgesehen davon das ich nicht weiss nach welchen Regeln Ubuntu die Pakete einteilt, sehe ich auch hier wieder nicht warum es in Main sein sollte. Was genau erwartest du in dem Paket das eine zusätzliche Pflege erfordert? Ich habe mir die Changelog angeschaut von Ubuntu, ich konnte nichts finden was Sicherheitsrelevant war.
Es kann ja nicht die Anforderung sein das es einfach ein beruhigendes Label auf ein Paket gibt, und alle sind glücklich.
Du selbst hattest die Gleichung Server == LAMP aufgemacht.
Oftmals wird in Diskussionen behauptet Main sei für viele nicht ausreichend, aber viele nutzen eben typische LAMP Situationen (es sind aber nicht nur lamp pakete enthalten!) und damit ist es für viele dann eben doch ausreichend.
Und was ist mit dem Beispiel Tomcat, das ich schon 2 mal gebracht habe? In meinen Augen eine absolut typische Serveranwendung.
Dein Beispiel RCS verstehe ich nicht. Ist da der letzte Release nicht 8 Jahre her? Was erwartest du dort an Änderungen die gepflegt werden müssen?
Der letzte Release ist sogar von 1995 soweit ich weiß. Trotzdem erwarte ich, dass ein Sicherheitsproblem gefixt wird, wenn es gefunden ist. Was ist denn mit meinen anderen Beispielen wie Git und SVN?
Abgesehen davon das ich nicht weiss nach welchen Regeln Ubuntu die Pakete einteilt, sehe ich auch hier wieder nicht warum es in Main sein sollte.
Die Sprache an der Konsole umzustellen ist eine grundlegende Funktion eines Rechners, also gehört es nach main.
Es kann ja nicht die Anforderung sein das es einfach ein beruhigendes Label auf ein Paket gibt, und alle sind glücklich.
Doch, genau darum geht es einem (zahlenden) Enterprise-Kunden, genau das ist der Sinn einer Enterprise-Distribution.
Selbst proprietäre Software wie der Flash Player ist auch sofort hinzu installiert, da Adobe für RHEL ein eigenes Repo bereit hält.
Von "einfach" für einen Newbie kann hier keine Rede sein.
"denn grade Newbies verzweifeln schon an den Kinderkrankheiten eines frischen Releases"
Das will ich nicht bestreiten.
Aber Newbies verzweifeln eher daran, dass sie nicht out-of-the-box ihre MP3-Sammlung oder die neuesten Flashfilme abspielen können.
Was soll schwer daran sein, sich ein Paket herunterzuladen und es per Mausklick zu installieren?
Aber Newbies verzweifeln eher daran, dass sie nicht out-of-the-box ihre MP3-Sammlung oder die neuesten Flashfilme abspielen können.
Wir reden hier immer noch über CentOS und damit über Enterprisesysteme. MP3-Dateien dürften da keine große Rolle spielen.
"Aktuell" ist eine Sache der Definition. Der Desktop ist bei einem RHEL zwar meist recht alt, aber unter der Haube befinden sich Backports ohne Ende. Im Laufe der Zeit ändert sich die Sache durch die Pointreleases und das "alte" RHEL/CentOS kommt besser mit neuer Hardware zurecht als das "neue" Ubuntu.
Gibt man dem LTS nach dem Release 1-2 Monate zur stabilitierung sind sie danach probklemlos nutzbar, und auch immernoch nicht veraltet.
und warum muss das Produkt dann beim Kunden reifen? Warum nicht einfach noch die 1-2 Monate warten?
Dennoch ist auch mit Backports ein deutlicher Delay zu erkennen.
"Im Laufe der Zeit ändert sich die Sache durch die Pointreleases und das "alte" RHEL/CentOS kommt besser mit neuer Hardware zurecht als das "neue" Ubuntu."
Das ist etwas das dir keiner am Ende garantieren kann. Zwar werden die Red Hat Release gut gepflegt, daran gibt es keinen Zweifel, aber ob am Ende wirklich eine benötigte Hardware unterstützt wird kann niemand sagen. Allerdings, und das stimmt auch wiederum, hat Ubuntu das selbe Problem. Wer aktuelle Hardware perfekt unterstützt haben will muss zwangsweise irgendwann mit der Zeit gehen.
"und warum muss das Produkt dann beim Kunden reifen?"
Wo habe ich geschrieben das es so sein MUSS? Es ist lediglich die Situation wie sie ist die ich beschrieben habe. Canonical entscheidet sich aktuell gerne dafür das die Release pünktlich erscheinen. Wer stabilität will wartet dann bis sicher ist das auch wirklich alles gefunden wurde. Es gibt Release bei denen ist das praktisch sofort der Fall, bei anderen nicht. Wer wartet ist aber immer auf der sicheren Seite.
Bei CentOS wartest du zudem auch eine Zeit lang bis du es nutzen kannst, wenn hier auch weil sie nicht sofort einen Release paralell zu Red Hat bringen können. Gerne auchmal ebenfalls 1-2 Monate. Daher ist es nicht wirklich ein Problem beim Vergleich CentOS/Ubuntu (ist ja eine CentOS News) wann man es nutzen kann. Bei Ubuntu ist es Canonicals ungedult, bei CentOS der natürliche Delay einer Distrie die von dem Release einer anderen abhängt.
Doch, Red Hat kann Dir das sagen, dafür werden Enterprise Linuxe ja zertifiziert, auch Ubuntu LTS soweit ich weiß.
Wer wartet ist aber immer auf der sicheren Seite.
Gut, nehmen wir mal an, ein Unternehmenskunde will auf Nummer sicher gehen und wartet ein halbes Jahr nach dem Release. Damit verkürzt sich die Nutzungsdauer von 3 auf 2,5 Jahre.
Wer stabilität will wartet dann bis sicher ist das auch wirklich alles gefunden wurde.
Und das kann meiner Ansicht nach nicht in einem Monat zwischen RC und Release passieren und auch nicht in dem einen Monat danach, von dem Du sprichst. Ich halte eine Zeit von mind. einem Jahr für notwendig.
Allerdings wenn es das einzige ist was die einfällt, dann ist es langweilig. Über diesen Fehler wissen alle inzwischen mehr als genug.
Ich sehe ihn auch durchaus in manchen punkten positiv, er hat die Aufmerksamkeit der User erhöht, und den glauben geschwächt das man sich immer und komplett auf andere Menschen verlassen kann, die man zudem meist weder kennt noch überhaupt jemals gesehen hat
Übrigens ist es klar das CentOS den bug nicht hatte. Er wurde ja nuneinmal von Debian gemacht, wodurch auch Ubuntu zum Opfer viel. CentOS hat dafür jeden Fehler den Red Hat macht mit an Bord.
Nur dass das erheblich weniger sein dürften. Nichts gegen Debian, aber bei Red Hat arbeitet eine ganze Abteilung an Sicherheitsfragen, bei Debian nur eine Handvoll Leute. Und Red Hat hat eine andere Unternehmensphilosophie: Patches, die von upstream nicht akzeptiert werden, kommen auch nicht in RHEL oder Fedora. Damit wäre der OpenSSL bug schon mal nicht passiert.
Das könnte jemand gerne mal nachforschen. Ich bezweifle es allerdings. Am Ende dürften sie auf das gleiche hinauslaufen. Aber wer mal eine Statistik erstellen will, das wäre durchaus interessant.
"Damit wäre der OpenSSL bug schon mal nicht passiert."
Der Bug war einfach allgemein bescheuert. Er hätte dort garnicht gefixt werden dürfen. Sau dummes, extrem peinliches und kaum zu etragenes aber sehr menschliches versagen
Allerdings beruhigt es mich auch jedesmal über diesen Bug zu lesen. Immerhin zeigt es das es ansonsten sehr ruhig ist bei Debian in solchen Themen.
Ähnlich ist es wohl bei Red Hat mit den nicht gerade Imagefördernden Serveinbruch gewesen. Wenn ich mich nicht irre haben sie doch damals sogar Pakete signiert und verteilt bekommen, oder?
Man sieht hier auch direkt den Unterschied zu Debian: Debian betreibt in solchen Fällen nackte und radikale Offenheit, unabhängig davon, welche "Peinlichkeiten" dadurch ans Licht kommen (können).
Das ist ja auch das mindeste
http://lwn.net/Articles/340130/
https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html
Übrigens wurden weder bei Fedora noch bei Red Hat manipulierte Pakete über die Standard-Mechanismen ausgeliefert. Bei Red Hat musste man sich die manipulierten Pakete schon umständlich über das Web manuell runterladen...
fs
Der ist ja auch nicht in Debian gefixed worden, sondern verhunzt. Und das bei RHEL eben nicht passieren können, wie ich eben schon erläutert habe. Debian leidet darunter, dass sie zu wenig Manpower für Sicherheitsupdates haben. Wenn einer mal im Urlaub ist, merke ich das auf meine Stable jedes Mal daran, dass es auf einmal wenig bis keine Updates mehr gibt.
Ähnlich ist es wohl bei Red Hat mit den nicht gerade Imagefördernden Serveinbruch gewesen.
Sowas ist nie förderlich und Debian hatte mehrere, ich kann mich an mindestens 3 erinnern.
Wenn ich mich nicht irre haben sie doch damals sogar Pakete signiert und verteilt bekommen, oder?
Du irrst Dich, siehe https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html
Falsch (Beispiel: Xen bis Fedora
...
Jede Distribution muss immer mal wieder bestimmte Patches einbauen, die nicht von Upstream akzeptiert werden. Und an Fedora arbeiten inzwischen mehr Freiwillige als Red Hat-Mitarbeiter.
fs
Du vergisst, das Fedora zu dem Zeitpunkt de facto der Upstream für Xen war.
Jede Distribution muss immer mal wieder bestimmte Patches einbauen, die nicht von Upstream akzeptiert werden.
Wieso das? Meiner Ansicht nach sollte man solche Patches wo es geht vermeiden.
Und an Fedora arbeiten inzwischen mehr Freiwillige als Red Hat-Mitarbeiter.
Brauchst Du mir nicht zu sagen, ich bin einer von ihnen. Zahlenmäßig gibt es tatsächlich mehr Leute aus der Community als RH-Mitarbeiter, aber die Hauptamtlichen arbeiten Vollzeit.
Und selbst wenn mehr Freiwillige an Fedora arbeiten, was ist daran schlimm? Das zeigt doch, wie offen die Distribution ist und das RH eben grade nicht (mehr) die Macht hat. Ähnlich ist es bei CentOS: Basiert auf RHEL, aber ist voll in der Hand der Community - und das ist auch gut so.
Hingegen gab es den Red Hat Linux Advanced Server 2.1 schon parallel zu Red Hat Linux 7.2 und 7.3. Die Umbenennung in Red Hat Enterprise Linux (RHEL) erfolgte später. Sogar eine Enterprise Fassung von Red Hat Linux 6.2 gab es.
Äääh, Red Hat Linux 9 als Vorgänger von CentOS zu bezeichnen, ist doch wohl nur ein Witz, oder? RHL 9 war der direkte Vorgänger von Fedora Core 1, das zu Beginn des Entwicklungszyklus tatsächlich noch Version 9.8X trug und erst dann umgenannt wurde, als klar war, dass es kein Red Hat Linux 10 werden würde.
Hingegen gab es den Red Hat Linux Advanced Server 2.1 schon parallel zu Red Hat Linux 7.2 und 7.3. Die Umbenennung in Red Hat Enterprise Linux (RHEL) erfolgte später. Sogar eine Enterprise Fassung von Red Hat Linux 6.2 gab es.
Hi
,
Da sich ein Privatanwender damals wohl kaum die Server Version von Red-Hat leisten konnte, wollte ich mit RH 9 nur andeuten, wie gut diese Systeme schon damals waren.
Darf ich fragen, was du benutzt ?
Gruss goose
Auch Dag's Kritik zielte sicherlich nicht (ausschliesslich) auf die fehlende Kommunikation mit Lance aus.
Das Projekt und die gesamte Entwicklung ist nach aussen hin nicht transparent. Es bestehen Bemuehungen dies zu verbessern, bisher aber ohne sichtlichen Erfolg.
Hierzu gehoert die Dokumentation des Build Prozesses, die Oeffnung des Wikis, klare Definition von Verantwortlichkeiten und der Umgang mit neuen Maintainern.
Ich persoenlich werde auch in Zukunft versuchen dazu beizutragen das dies moeglich wird.
Viele Gruesse
Marcus
Nach einiger Zeit der Suche bin ich dann auf CentOS gestossen und begeistert von dem Support bis 2014! Darüber hinaus läuft das System bislang ohne Probleme. Nach dem Hinzufügen von einigen Paketrepositories ist auch Multimedia kein Problem. Damit habe ich genau dass, was ich zum Arbeiten benötige: ein stabiles, zuverlässiges System, dass wenn ich es einmal gemäss meinen Bedürfnissen eingerichtet habe über mehrere Jahre zuverlässig laufen kann.
Daher fände ich es sehr, sehr schade, wenn CentOS nicht weiterbestehen würde.
Grüsse
E. coli
Ich bin mir nicht ganz sicher wie du das meinst. Immerhin ist der Supportzeitraum für die LTS ja 5 Jahre. Ich kann allerdings nachvollziehen das du noch längeren Support vorteilhaft findest.
Das ist korrekt, ich hatte nicht erkannt das du es für Desktops suchst.
Das ist korrekt, ich hatte nicht erkannt das du es für Desktops suchst.
Auch für den Server gibt es bei Ubuntu im Grunde genommen nur 3 Jahre Support, warum habe ich oben schon erläutert. Nehmen wir mal an, ich habe einen tomcat mit einer proprietären JVM, die aus universe kommt. Für die bekommst Du nach 3 Jahren auch keinen Support mehr, nur für die Sachen aus dem "main"-repo.
MfG =HAL-9000=
- epel von Fedora: http://fedoraproject.org/wiki/EPEL/FAQ
- RPMForge: http://rpmforge.net
- RPMFusion: http://rpmfusion.org/
Von CentOS gibt es noch diese Anleitung: How to setup multimedia on CentOS-5: http://wiki.centos.org/TipsAndTricks/MultimediaOnCentOS?highlight=(multimedia)
Heute war doch eine Meldung auf heise, Streß zwischen Torwalds und Cox. Ok, die sind festangestellt, am das Ego ist nicht kleiner ...
Jetzt ist gerade eine Meldung auf heise, Streit bei Debian, dies bestätigt nur meine Theorie der Egotrips.
Ich selber bin Mathematiker, und solches Verhalten gibt es unter Mathe-Docs und -Profs nicht! Dies sind alles sehr höfliche und zurückhaltende Leute.
fs
PS: Die Mathematiker waren auch bei uns meist bescheiden - allerdings kannte ich auch ein paar Ausnahmen, die auch sehr erfolgreich in der Einwerbung von Drittmitteln und der Optimierung ihrer Leistungskennzahlen waren...
Gegen Einwerbung von Drittmitteln ist ja erstmal nichts einzuwenden ...
Ich habe mich für ein Uni-Leben entschieden, und wenn man da sein Ego nicht im Griff hat, kommt man nicht weit. Es erfordert eine Engelsruhe Übungen zu haleten und Fragen der Studenten zu beantworten, weil einem es selber klar ist, und machmal Fragen kommen wo man denkt ob die Studenten gepennt haben
Viele OSS-Programmierer haben sich einen guten Namen gemacht und auch verdient.
Schlecht ist es doch nur, wenn es dem Projekt und den Mitstreitern schadet.
Damit hast du doch schon selbst die Begründung geliefert. Ich finde OSS auch toll, aber man muss vernünftig miteinander umgehen.
Meinen Studenten drücke ich auch ein Linux in die Hand und dann wird in Fortran mit gfortran und oktave anstelle von Matlab programmiert.
Dies wäre nicht möglich wenn vor mir nicht jemand die Software geschrieben hätte.
Er behauptet nicht, daß das immer der Fall wäre.
Im übrigen, was jemand mit seiner Freizeit anstellt, ist sein Bier. Er hat dann in meinen Augen auch durchaus das Recht, etwas unverträglicher aufzutreten. Ist ja seine Freizeit. Andere wollen oder können nicht mit ihm zusammenarbeiten? Das ist sehr schade (wirklich!), aber es bleibt nach wie vor seine Freizeit, die er da verbrät.
Arbeitet jemand für Geld, ist das was anderes.
Ich unterrichte z.B. gern, und wir könnten es uns viel leichter machen. Nach dem Motto: "Hier ist eine Literaturliste, und in 5 Monaten ist die Prüfung." Das Dumme an der Geschichte ist, Bücher können Fragen nicht erklären.
1. Es werden zusätzliche Features eingebaut, die für die Entwickler wichtig sind. Dadurch ist das System nicht mehr absolut RHEL-kompatibel, was sehr vielen CentOS-Nutzer wichtig ist.
2. Weil SL nicht einfach alle RHEL-Updates nehmen kann (eigene Features), ist auch der Supportzeitraum deutlich kürzer, was noch mehr Nutzern wichtig ist.
Den Fork sehe ich nicht so als Problem an, repräsentieren sind die genannten Unterzeichner praktisch das komplette, derzeit aktive CentOS-Team, d.h. das Wissen über die Infrastruktur etc. könnte mitgenommen werden. Immerhin sind die Probleme mit Lance schon länger bekannt (einige Jahre) und auch ein Grund dafür, warum nicht aggressiver um Spenden geworben wurde...
fs
Wenn Du in meinem Team arbeiten würdest, dann wärst du jetzt schon "geflogen".
Dann habe ich dich wohl falsch verstanden, nichts für ungut.
1. Unfreie Software in der Standard-Distribution ist für mich ein sofortiges No-go. Und auch Red Hat separiert Non-Free+Free in RHEL sehr sorgfältig.
2. Man kann einfach Kernel-Module etc. aus der SL-Distribution installieren, die nicht in RHEL sind und damit das Betriebssystem inkompatibel machen. Gerade wenn man noch zusätzliche Kernel-Module für Hardware-Unterstützung braucht, möchte ich soweit wie nur irgendwie möglich mit RHEL übereinstimmen und nicht jedesmal schauen müssen, ob das jetzt immer noch RHEL entspricht...
3. "Mindestens bis 2010" ist etwas anderes als die Aussage "Was immer auch kommt, wir versuchen genauso lange Support bereitzustellen wie Reed Hat".
fs
Jedoch muss ich sagen das ich bei CentOS immerschon etwas bedenken hatte. In der Theorie klingt es toll, aber Theorie und Praxis sind nicht das selbe.
Aber wie gesagt, man sollte nichts zu früh totsagen. Genausogut könnte das Team jetzt erst recht zupacken, alles ins reine bringen, und einer besseren Zukunft entgegensehen. Vielleicht erkennen sie z.B. andere Distries mit ähnlichen, aber spezielleren Zielen (eben das genannte Scientific Linux) und arbeiten enger zusammen.
Ich persönlich sehe bei CentOS keine direkte Gefahr: Alle aktiven Entwickler stehen hinter dem offenen Brief. Bei einem Fork/einer Fusion würden "nur" centos.org und die derzeitigen Mirrors/Gelder verloren sein. Das hätte natürlich einen großen Effekt für die Bekanntheit und das Marketing einer neuen Distribution, aber Benutzer müssten maximal die Yum-Repositories ändern und neue GPG-Keys importieren.
fs
Viele Grüsse
Marcus