Stimme überhaupt nicht zu. Ein Grund von SuSE auf Debian zu wechseln war, das ich es leit war 4 Updates / Jahr auf den Server einzuspielen. Aller 3 Jahre ne neue Version reicht völlig aus!
Nein! Schon nach zwei Jahren sind viele Bibliotheken veraltet, so dass man ohne Backports auch für Server interessante Software nicht installieren kann. Aber vielleicht sollten sie sowas wie Ubuntu machen, nämlich den Support nicht mit dem Erscheinen eines neuen Releases einstellen, sondern noch 12 Monate fortzuführen. Dann wäre man nicht gezwungen, sofort upzudaten.
Ansonsten finde ich die Entscheidung gut, so wird sich zeigen, welche Architekturen wirklich noch benötigt werden und welche tatsächlich vor allem Ballast waren, da sie kaum Maintainer anziehen.
Das ist natürlich Quark. In der Praxis laufen noch viele NT4-Server (SP 6a war 1999) und Win2000-Server. Die sind beide älter als 2 Jahre und niemanden juckts. So lange ein Serverdienst tut was er soll und keine gravierenden Sicherheitslöcher hat, bleibt er wie er ist. Hat er Löcher, dann fixt Debian.org diese Löcher im Stablezweig, auch bei älteren Versionen.
Tolle Antwort. was du kannst nicht programmieren, keine packages machen, hast keine Zeit? also sei still und friss was wir dir geben. Wer so Leute vergrualt, wird Debian auf keinen Fall nach vorne bringen und auch keine Werbung für machen.
Sarge kommt doch sowieso erst, wenn Hurd Final ist.
Also i bleib bei Slackware, da weiss man was man hat und alle sind viel freundlicher zueinander.
Ein verläßlicher Releasezyklus von 12 bis maximal 18 Monaten wäre völlig o.k.
Wer halbjährliche Releases will kann ja SuSE oder neandere Distro nehmen und rpm-apt nachrüsten. Bei halbjährlichen Releasen darf man dann aber auch nicht jammern wenn nur SuSE-Qualität erreicht wird.
Ja, stimmt. Meine 6 SuSEn rauchen alle 5 Minuten ab und ständig entdecke ich Rootkits. Wenn ich einmal groß bin und so klug wie Du, dann werde ich mir aber auch ein Debian installieren. Das ist nämlich 100% sicher und absolut fehlerfrei.
Vielleicht laufen meine SuSEn aber einfach nur gut. Muss wohl ein glücklicher Zufall sein.
Wenn eine Distri mit uralten Programmversionen aufährt, kapier ich nicht, worin der Sinn darin liegen soll. Oder ist das ein Missverständnis meinerseits?
Nicht das man immer das Neueste bräuchte, aber im Allgemeinen steigen auch die Funktionalitäten und Stabilität, wie z.B. bei MPlayer ganz erheblich. Und sich sowas jedesmal selbst zu kompilieren, wenn man vorher die Bibliotheken zu aktualisiseren hat, ist ganz schön mühsam. Gerade die Probleme mit Mplayer und Xine haben mich von Suse zu Gentoo migrieren lassen. Es machte unter dem Strich weniger Arbeit, selbst wenn allzuoft manche EBuilds fehlerhaft sind.
Der Sinn bei Debian liegt daran, dass man z.B. einen Server aufstellen, automatisch täglich per Cronjob Updates einspielen und sich sicher sein kann dass er immer läuft. Bei den Paketen werden nur Sicherheitsupdates und sonstige Bugfixes geupdatet, keine umfangreichen Änderungen.
Kein Unsinn. In einer idealen Welt würde man das nicht machen... dumm nur, das wir diese nicht haben. Für kleinere Betriebe ohne IT-Labor ist das automatische Update, mit der extrem geringen Wahrscheinlichkeit dass was zerrissen wird, sehr vorteilhaft. Auf jeden Fall ist es besser, die Kisten zu installieren und sie mit automatischen Update zu vergessen, als sie zu installieren und sie ungepatcht zu vergessen... was leider die Regel ist.
Ich hab bei Debian-Woody noch niemals einen Server gehabt, der durch ein automatisches Update zerrissen wurde. Bei gemachten Updates wird einfach ne Mail an den Admin gesendet, der diese wohlwollend zur Kenntnis nimmt. Wenn das Update was zerreißen sollte, dann weiß man sofort wo man suchen muß. Für mittelständische Firmen ist das Security-Framework von Debian wie ein Gottesgeschenk.
ich hab zwar auch bauchschmerzen bei dem gedanken an automatische updates, aber ich kann ebenfalls bestätigen, daß ich durch updates von debian/stable auch noch nie einen dienst zerlegt habe. wenn man einigermaßen sicher stellen kann, daß die updates von einer vertrauenswürdigen quelle kommen und keiner da was unterjubeln kann, würde ich im zweifel auch lieber automatisch updaten als überhauptnicht.
Von Random Debian User am Mo, 14. März 2005 um 23:31 #
> Kein Unsinn.
Doch. Viele Updates benoetigen weitere Handgriffe. Ein Kernel Update wird erst aktiv nach einem Reboot, ein Update von OpenSSL fixed nicht die Programme die bereits laufen und noch die alte Version im Speicher haben.
Automatische Update sind gefaehrlich. Man wiegt sich in falscher Sicherheit.
Um solche Updates mitzubekommen gibts ja ne Mail an den Admin. So sagt dir dein Server, dass du dich drum kümmern muß. Wenn du das nicht automatisch machst, dann mußt du immer alle Mailinglisten mitverfolgen, was zwar in einer idealen Welt gemacht wird, doch leider nicht in unseren heutigen.
Nein das ist unsinnig, das macht niemand. Einfaches Bsp. neulich gab es ein gnupg update, einer unserer Kunden Verschlüsselt über PHP mit gnupg Online-bestellungen. Bis vor dem update war das importieren ohne "" nach dem update mit "" anführungszeichen, schlussfolgerung dessen das PHP Script lief nicht mehr. Wäre das autom. Passiert hätte man nicht wirklich nachvollziehen können auch wenn Du das update mit Protokollierst nicht, denn gesetz den Fall du machst jeden Tag ein apt-get update && apt-get upgrade und schreibst den output in eine Liste. Nun wird aber nicht jeden Tag eine Bestellung ausgeführt sondern meinetwegen nach 2 Wochen wo es schon wieder 3 neue Updates gab weißt du was dann wirklich los war?
Mal ganz zu schweigen davon wie entscheidest Du voher schon welches update eingebspielt werden sollen wenn du mit listbugs arbeitest? Bei Listbugs wird das neue Paket nach bugs abgefragt wenn Bugs vorhanden sind wird gefragt ob Du es dennoch installieren willst, klar ich könnt ihm ein yes mitteilen aber was ist wenn wirklich Kritische Fehler mit drinn sind, wie würdest Du das autom. wollen oder updatest du nur unkritische Pakete? - toll weil dann kannst du das gleich ganz lassen denn dann werden Pro Monat vermultich nur 2 updates eingespielt die kein bekannten bug haben.
Nachwie vor sollten Administratoren vom jeweiligen System wenn möglich eine Testumgebung haben. - Der aufwand ist sichlich grösser und der jeweilige Administrator wird mangels aus Zeit nichts anderes machen können aber so wäre garantiert das sich keine ungewollten Fehler einschlechen oder die Chance das wäre um einiges geringer das etwas Passieren kann.
Das trifft nicht nur auf Debian das ist gleich zusetzen mit allen Paketorientieren Distributionen auch unter Windows. Dich möchte ich nicht als Administrator in einer Firma haben wollen ernsthaft das ist faulheit und dummheit auf einmal.
> Einfaches Bsp. neulich gab es ein gnupg update, einer unserer Kunden Verschlüsselt über PHP mit gnupg > Online-bestellungen. Bis vor dem update war das importieren ohne "" nach dem update mit "" > anführungszeichen, schlussfolgerung dessen das PHP Script lief nicht mehr. Bist Du Dir wirklich sicher, dass das in stable war? Der letzte gnupg-upgrade war am 14.2.04, also nicht mehr ganz "neulich". Ich kann mir aber nicht wirklich vorstellen, dass es so ein gravierender upgrade-bug in stable gegeben hat.
Wer ein automatisches update/upgrade in testing oder unstable macht ist natürlich selber schuld.
Ein Server mit Debian-Unstable und automatischen Update zu fahren ist auch extrem schwachsinnig. Aber ein Debian-Stable mit automatischem Update ist für mich ein Feature.
>Nachwie vor sollten Administratoren vom jeweiligen System wenn möglich eine Testumgebung haben. - Der aufwand ist sichlich grösser und der jeweilige Administrator wird mangels aus Zeit nichts anderes machen können aber so wäre garantiert das sich keine ungewollten Fehler einschlechen oder die Chance das wäre um einiges geringer das etwas Passieren kann.
Viele kleine Firmen können diesen Aufwand einfach nicht leisten. Wenn du dann die Wahl hast keine IT oder IT ohne Labor, dann ist die IT ohne Laborumgebung immer noch besser.
>Mal ganz zu schweigen davon wie entscheidest Du voher schon welches update eingebspielt werden sollen wenn du mit listbugs arbeitest? Bei Listbugs wird das neue Paket nach bugs abgefragt wenn Bugs vorhanden sind wird gefragt ob Du es dennoch installieren willst, klar ich könnt ihm ein yes mitteilen aber was ist wenn wirklich Kritische Fehler mit drinn sind, wie würdest Du das autom. wollen oder updatest du nur unkritische Pakete? - toll weil dann kannst du das gleich ganz lassen denn dann werden Pro Monat vermultich nur 2 updates eingespielt die kein bekannten bug haben.
In stable werden NUR kritische Bugs behoben. Das heißt, das jedes Update nötig ist(Ok lokale ausnutzbare Lücken müssten bei einem System ohne lokale User nicht upgedatet werden). Nach meiner Erfahrung bewegt sich die Wahrscheinlichkeit das ein automatisches Debian-STABLE-Update das Produkivsystem zerreißt, bei nahezu Null. Die Wahrscheinlichkeit das sich das mittelständische Unternehmen keine anständige IT leisten kann/will, ist dagegen weit höher.
>Dich möchte ich nicht als Administrator in einer Firma haben wollen ernsthaft das ist faulheit und dummheit auf einmal.
Dummheit wäre es, wenn du nicht weißt was du tust. Faulheit wäre es, wenn du die Zeit für die ideale Administration bekommen würdest und trotzdem nicht ideal administrieren würdest.
Außerdem sehe ich immer noch keine Grund wieso ich das Update nicht automatisch machen sollte, und mich von den Update per Mail informieren lasse. Wenn du keine Laborumgebung hast, dann mußt du das Update auch am Produktivsystem machen. Das geht natürlich nur, wenn das die Firma nicht Millionen kostest, wenn im EXTREMFALL mal was schief geht und der Server ne Stunde nicht läuft. Solche Firmen haben dann aber auch selber Schuld, wenn sich sich kein Laborsystem leisten. Doch beim Mittelstand ist es eher das Problem, das sie sich die anständige IT nicht leisten können.
Das ist ne ganz einfache Kosten/Nutzen-Analyse.
Ich finde solche Aussagen wie von dir, extrem wirklichkeitsfremd. Ich bin jemand, der jedem Unternehmen mit IT erzählt, das es eigendlich eine Security-Police benötigt und daraus das Sicherheitskonzept erarbeitet werden muß. Dazu gehört auch die regelmäßige Mitarbeiterschulung und Konzepte für Reaktionen im Schadensfall. Dank der "Unmöglichkeit" Bugfreie Programme zu erkennen, wird Intrusion und Misuse-Detektion auf Network und Hostebene benötigt. Auch sollte das Know-How vorhanden sein, eine gerichtsverwertbare Beweißkette beim erkennen eines Mißbrauches zu führen.
Und jetzt rate mal, wie viele Mittelständler eine Security-Policy haben. Das sind nahezu Null. Das Sicherheitskonzept ist meist das, was sich der Admin aus den Fingern gesaugt hat. Eventuell sind mal Host-Intrusion-Detektion-Systeme wie Aide im Gebrauch, doch die sind meist installiert und nicht auf einer CD zu finden - also manipulierbar. Network-Intrusion-Detection-Systeme sind dagegen nahezu im Land der Mythen einzuordnen. Und sollte mal eins Vorhanden sein, dann ist der Admin zu 99% durch zu viele false-positiv's überfordert. Einen vorhandenen Plan zur lückenlosen Führung einer gerichtsverwertbaren Beweißkette bin ich noch nie begegnet.
Was mir aber regelmäßig über den Weg läuft, sind Server die in Firmen installiert werden, und daraufhin darauf warten das jemand sie besser benutzen kann als die Firma. Diese Firmen sind sehr gut beraten, wenn sie ihr Debian-STABLE automatisch updaten und so die Wahrscheinlichkeit das was passiert von 100% auf 0,1% zu verringern.
Aber sehr wahrscheinlich bin ich ja zu blöde, um zu sehen wie das in real existierenden Firmen abläuft. Mind
neulich gab es ein gnupg update, einer unserer Kunden Verschlüsselt über PHP mit gnupg Online-bestellungen. Bis vor dem update war das importieren ohne "" nach dem update mit "" anführungszeichen, schlussfolgerung dessen das PHP Script lief nicht mehr.
Das war dann wohl ein Versionsupdate und mithin _nicht_ Debian Stable denn solche wird da nicht gemacht. Da werden nur in die in Stable enthaltenen Versionen sicherheitsrelevante Patches eingepflegt, die nichts am Verhalten des Programms ändern.
> Wenn eine Distri mit uralten Programmversionen aufährt, kapier ich nicht, worin der Sinn darin liegen soll. Oder ist das ein Missverständnis meinerseits?
In manchen Umgebungen ist die Stabilität einer Distribution wesentlich wichtiger als die Aktualität. z.B. auf Servern oder auf Desktops in Firmen. Eine stabile Distribution ist vor allem wesentlich leider zu pflegen als eine Distribution die sich ständig verändert.
Bei privaten Desktops ist Aktualität gefragt und dafür gibt es bei Debian ja den Testing und den Unstable Zweig. Der Unstable Zweig enthält die aktuellsten Pakete die nach einiger Zeit dann in den Testing Zweig wandern, sofern keine größeren Probleme aufgetreten sind.
im allgemeinen gilt, dass wenn etwas angeboten wird, meistens auch eine Nachfrage nach diesem Angebot besteht. Da Debian eine der ältesten Distributionen ist muss es irgendwo schon eine Nachfrage geben. In zukunft also erst Kopf einschalten, dann schreiben...
Wenn du jetzt wirklich wissen willst für was man Debian gebrauchen kann, dann suche einfach mal nen bischen in irgendwelchen distri-flame-wars da wirst du ganz schnell fündig. Selbst hier irgendwas auflisten werde ich hier nichts, da dein posting einfach zusehr nach flame ausschaut....
Es geht dabei hauptsächlich um Stabilität. "Stabilität" bedeutet ja per definitionem, dass sich das Verhalten des Gesamtsystems nicht ändert — und das (für die "Enterprise"-Anwender) möglichst über mehrere (mindestens drei, besser fünf) Jahre hinweg. Die einfachste Möglichkeit, dafür zu sorgen, dass sich das Verhalten des Gesamtsystems nicht ändert, ist, dafür zu sorgen, dass sich das Verhalten der Einzelkomponenten nicht ändert. Und der einfachste Weg, dafür zu sorgen, dass sich das Verhalten einer Einzelkomponente nicht ändert, ist, die Einzelkomponente gar nicht zu verändern. Wie der Name des öffentlichen Release-Zweiges von Debian, nämlich "stable", schon anzeigt, ist Stabilität das oberste Ziel. Daher wird im Zweifelsfall eben auf unnötige Upgrades verzichtet. Debian hat mit Abstand die größte Paketauswahl (IIRC irgendwas um 15000 Pakete) aller Linux-Distributionen. Es ist schlicht unmöglich zu garantieren, dass ein Upgrade einer Komponente, das z.B. ein anderes Verhalten, neue Schnittstellen, neue Features o.ä. einführt, keinen Effekt auf das aus 15000 Komponenten bestehende Gesamtsystem hat.
Es gibt natürlich gewisse Punkte, bei denen es sinnvoll ist, das Konzept der Stabilität aufzugeben. Wenn beispielsweise der Kernel bei bestimmten Aktionen reproduzierbar abstürzt und man diesen Crash dann mit einem Fix behebt, dann hat man auch das Verhalten des Gesamtsystems verändert: vorher stürzte es ab, hinterher nicht mehr. Das gleiche gilt für das Beheben von Sicherheitslücken. In gewissem Sinne ist das nicht mehr "stabil", weil sich das Verhalten geändert hat, aber es handelte sich eben um unerwünschtes Verhalten, das korrigiert wurde. Bei Sicherheitslücken oder Systemcrashes ist es allerdings recht einfach, einen generellen Konsens zu erzielen, was unerwünschtes und was erwünschtes Verhalten ist. Wenn aber ein Benutzer gerne das Foo Desktop Environment in Version 42 statt Version 17 haben möchte, weil ihm die runden Icons von Version 42 besser gefallen als die eckigen von Version 17, dann dürfte es schwierig sein, die Nutzer- und Entwicklergemeinschaft davon zu überzeugen, dass eckige Icons unerwünschtes Verhalten sind.
Das sowas passiert habe ich schon lange gehofft. Ich kann mich daran erinnern das Firefox (ich glaube 0.9 oder 1.0) nicht ins testing kam weil es sich nicht auf mips kompilieren ließ. Der Schritt ist zwar etwas drastisch es hätte wohl auch gereicht einfach den X Bereich nur für die "gängingen" 4 Architekturen anzubieten.
Ich bin auch voll dafür. Ist zwar weit hergeholt wenn ich behaupte, dass andere CPUs nicht den gesamten Softwareumfang von Debian benötigen oder sagt package contest was anderes?
Damit beraubt sich Debian selbst einer seiner letzten Vorteile gegenüber anderen Distris. In vielen Diskussionen wurde immer wieder auf die Architekturzahlen hingewiesen, für welche Debian verfügbar ist. Das fällt damit auch weg.
Von Banana Republic am Mo, 14. März 2005 um 13:51 #
Nein, d.h. doch nur das Paket X, welches nicht auf MIPS kompiliert, nicht den ganzen Release verzoegern darf, obwohl es auf allen anderen Releaseplattformen keine Probleme macht.
Und das wird doch schon seit bald zwei Jahren immer wieder diskutiert. Jetzt hat man ein gutes Ergebnis (Hauptplattformen Release, SCCs spaeter und nicht zwingend im selben Umfang) und es gibt immer noch welche die darueber meckern. Ich sehe ueberhaupt keine Alternative zu dieser Entscheidung.
Wo bitte ist denn fuer einen MIPS-User der Unterschied, ob sein MIPS-Release nach drei Jahren erscheint (z.Bsp. ein Jahr nach dem Release der "Populaeren"), oder nach den gleichen drei Jahren (nun aber gemeinsam mit den Populaeren)?
Richtig, fuer den MIPS-User macht das keinen Unterschied, aber fuer die anderen sehr wohl!
> Wo bitte ist denn fuer einen MIPS-User der Unterschied, > ob sein MIPS-Release nach drei Jahren erscheint (z.Bsp. ein > Jahr nach dem Release der "Populaeren"), oder nach den > gleichen drei Jahren (nun aber gemeinsam mit den Populaeren)?
Die grosse Angst duerfte wohl sein das der Support fuer die exotischen Plattformen schleichend stirbt. Heute wird MIPS in der Prioritaet zurueck gesetzt, morgen komplett aufgegeben, oder so aehnlich.
Fakt ist, dass dem Debian Projekt auf vielen Architekturen einfach die Kernel-Porter fehlen. Mit "wir bauen das Paket XYZ einfach mal auf Sparc" ist es leider nicht getan. Andreas Barth schreibt so schoen in seinem letzten Release-Update:
It's for this reason that all architectures are required to be synced to the same kernel version for sarge, but even so, more per-architecture kernel help is needed, particularly for the sparc and the arm port.
Sicherlich ist der Schnitt hart, aber ich denke, auf lange Sicht tut sich das Debian Projekt eher damit einen Gefallen, mit weniger Architekturen zu releasen, als einen Release wegen fehlenden Supports auf bestimmten Architekturen auf unbestimmte Zeit zu verschieben.
> Sicherlich ist der Schnitt hart, aber ich denke, auf lange > Sicht tut sich das Debian Projekt eher damit einen Gefallen, > mit weniger Architekturen zu releasen, als einen Release wegen > fehlenden Supports auf bestimmten Architekturen auf unbestimmte > Zeit zu verschieben.
Ack. Ich denke, das Hauptproblem der meisten (Desktop-)User ist, daß sie mit dem Titel "Testing" Instabilität verbinden. Ich hatte bisher (~2 Jahre Testing-Nutzung) keine Situation, in der mir ein Paket so richtig abgeschmiert wäre, weder auf meinem kleinen Homeserver noch auf meinem Desktop.
Vielleicht wäre ein anderer Name für Testing sinnvoller? Vielleicht 'Preview' oder 'Sneak' oder sowas...?
Leute die sich von sowas verunsichern lassen, ohne sich wenigstens mal die release politik von debian anzukucken koennen gleich wegbleiben! Solche Ignoranten woellt ich bei debian gar nicht sehen...
na ja, vor ca. 1,5 Jahren hat sich mein Mailsystem unter Sarge verabschiedet, weil Exim nach einem Update plötzlich nicht mehr mit dem User mail, sondern unter Debian_exim lief. Und dann gab es erst mal Probleme mit den Zugriffsrechten, weil MailScanner und Dovecot nicht mehr an die gespeicherten Mails rankamen - die anderen Tools liefen ja noch mit dem User mail.
Einzige Lösung, die in <3 Stunden ging: Debian_exim die uid von mail zuweisen.
Ich will mich gar nicht beschweren oder so, so was kann in Testing passieren, aber genau deswegen würde ich keine Server mehr mit Testing laufen lassen. Klar, zum Ende einer Release-Periode wird Testing immer stabiler und wird von vielen Nutzern auch empfohlen (das konnte man schon bei Woody sehen), aber ein Ersatz für ein Release ist das imho nicht.
Und Woody ist inzwischen einfach veraltet. Z.B. Exim: Wenn man auf exim-users mit einem 3.x Problem anfragt, wird zu 90% einfach eine Antwort kommen wie "wird nicht mehr unterstützt.".
Bei den Architekturen wie Sparc ..etc werden eh fast nur Serveranwendungen laufen . Vielleicht könnte man für diesen Architekturen einen extra Server-Zweig einrichten , der für diese Gruppe von Anwendern zugeschnitten ist . Der Pflegeaufwand würde sich dann verringern , weil die Desktopanwendungen nicht mehr den Auwand aufblähen .
Aber wo machst du den Schnitt zwischen Server und Client? Bei uns hier in der Uni arbeiten wir mit Terminals, so das alle Anwendungen auf einem der Server (in unserem Fall Sparc) dann laufen. Auf den Clients laeuft nur ein X das sich via XDMCP an den Server verbindet. Ist KDE oder Gnome dann eine Server-Anwendung oder eine Client-Anwendung?
Nein, das wird nicht gehen.
Ich wuerde es eher fuer sinnvoll halten, dass Debian die Sektionen Base und Standart alle 9-18 Monate released, und dann basierend darauf weitere Zweige aufgebaut werden. Sowas wie Snapshot-Release fuer Gnome, oder Snapshot-Release KDE.
Das birgt dann wieder andere Risiken... Naja, wir werden sehen.
Sparc nur für Server? Wir sind gewiss kein großes Unternehmen, aber wir haben 31 Sunblades und zwei Macs (beim Chef und seiner Sekretärin), die alle auf Sarge laufen. Dazu kommt eine lpar auf einer 990 im rz Ludwigshafen, da läuft aber, wohl noch für eine Weile, Woody. Mein Laptop ist eine alte SparcStation 77MHz, nicht das neuste, aber zuverlässig und mit 14 Stunden Akkulaufzeit. Das Display macht zwar nur 512x480, aber für unterwegs reicht dasa völlig, arbeitet dann eh' auf der Console.
Das ist do die reinste Diskriminierung anders Kaufender. Das muss bestraft werden!
*lol* ich freue mich schon wieder auf die endlosen Diskussionen, ob das jetzt richtig ist oder nicht. Wenn sie das zu Ende diskutiert haben werden bei debian, dann wird wahrscheinlich i386 auch schon outdated sein ;=)
> *lol* ich freue mich schon wieder auf die > endlosen Diskussionen, ob das jetzt richtig > ist oder nicht. Wenn sie das zu Ende diskutiert > haben werden bei debian, dann wird wahrscheinlich > i386 auch schon outdated sein ;=)
Höchstwahrscheinlich schon, aber im Gegensatz zu Linux gibt es Hurd bisher ja nur auf x86, ppc und sparc und nur die x86 läuft ordentlich, hier sind die Einschränkungen also nicht ganz so groß. Trotzdem finde ich es erstaunlich, dass zwar ppc aber nicht sparc bei den Hauptarchitekturen dabei ist.
Ich finde das schade. Ein extrem wichtiger Punkt bei Debian ist die Freiheit. Und ein wichtiger Punkt, der diese Freiheit garantiert, ist die große Auswahl an (Hardware-)Architekturen, auf denen Debian läuft. Intel, AMD, Via, Apple, IBM und Motorola schließen sich zusammen und gründen ein "Evil Empire" und produzieren nur noch Prozessoren, die nur unter signierten Windows-Versionen laufen? Kein Problem, Debian unterstützt ja noch sechs andere Architekturen, darunter unter anderem die Sparc-Architektur, von der es auch eine Open-Source-Implementierung (Leon) gibt. George Bush erklärt IT-Technologie zu Kriegswaffen und die EU zu Schurkenstaaten? Kein Problem, ARM ist ein englisches Unternehmen und Debian läuft selbstverständlich auch auf ARM. Ulrich Drepper ist in Wirklichkeit ein Agent von Microsoft und hat unbemerkt Unmengen an patentiertem Code in die Glibc eingeschleust? Kein Problem, Debian wurde ja noch auf ein paar andere libcs portiert. SCO gewinnt überraschend doch noch den Prozess gegen IBM? Kein Problem, Debian wurde ja noch auf drei andere Kernel (FreeBSD, NetBSD, Hurd) portiert.
Außerdem bin ich mir nicht sicher, ob das überhaupt so viel bringt. Die häufigsten Portabilitätsprobleme sind Endianness und Adressbreite. x86 und AMD64 sind Little-Endian, IA64 ist Bi-Endian, die Linux-Portierung ist aber Little-Endian, PowerPC ist Bi-Endian, die Linux-Portierung ist aber Big-Endian. Mit anderen Worten: bei der Endianness ist schon mal nichts gewonnen, dafür müsste man auch noch PowerPC rauswerfen. Bleibt noch die Adressbreite: x86 und PowerPC sind 32 Bit, IA64 und AMD64 sind 64 Bit, um hier etwas zu gewinnen, müsste man IA64 und AMD64 noch rauswerfen. Als letztes Problem bleibt noch die Performance: viele Software ist handoptimiert für x86, zum Beispiel hängt mein betagter Pentium III den Opteron bei PearPC locker ab: es gibt zwar den G3-zu-Pentium Just-in-Time-Compiler, aber der läuft natürlich nicht im Long-Mode, auf dem Opteron muss ich also auf die generische CPU-Emulation zurückgreifen, die aber etwa 15-mal langsamer ist als der JITC. Das kann der Opteron auch mit seiner dreimal höheren Taktfrequenz und der doppelten Registerzahl nicht aufholen. Ähnliches gilt auch für viele Multimedia-Codecs, für die es häufig handoptimierten MMX- oder SSE-Assemblercode, nicht aber IA64- oder VMX-Assembler gibt.
Allo
Ansonsten wäre wohl Ubuntu Linux was für dich.
Woher diese Erwartungshaltung? Was tust du denn dafuer? Ach? Nichts? Dann Schnauze.
Ein Grund von SuSE auf Debian zu wechseln war, das ich es leit war 4 Updates / Jahr auf den Server einzuspielen.
Aller 3 Jahre ne neue Version reicht völlig aus!
Nein! Schon nach zwei Jahren sind viele Bibliotheken veraltet, so dass man ohne Backports auch für Server interessante Software nicht installieren kann. Aber vielleicht sollten sie sowas wie Ubuntu machen, nämlich den Support nicht mit dem Erscheinen eines neuen Releases einstellen, sondern noch 12 Monate fortzuführen. Dann wäre man nicht gezwungen, sofort upzudaten.
Ansonsten finde ich die Entscheidung gut, so wird sich zeigen, welche Architekturen wirklich noch benötigt werden und welche tatsächlich vor allem Ballast waren, da sie kaum Maintainer anziehen.
iGEL
Das ist natürlich Quark.
In der Praxis laufen noch viele NT4-Server (SP 6a war 1999) und Win2000-Server.
Die sind beide älter als 2 Jahre und niemanden juckts.
So lange ein Serverdienst tut was er soll und keine gravierenden Sicherheitslöcher hat, bleibt er wie er ist.
Hat er Löcher, dann fixt Debian.org diese Löcher im Stablezweig, auch bei älteren Versionen.
Bye
Tolle Antwort.
was du kannst nicht programmieren, keine packages machen, hast keine Zeit? also sei still und friss was wir dir geben.
Wer so Leute vergrualt, wird Debian auf keinen Fall nach vorne bringen und auch keine Werbung für machen.
Sarge kommt doch sowieso erst, wenn Hurd Final ist.
Also i bleib bei Slackware, da weiss man was man hat und alle sind viel freundlicher zueinander.
Ein verläßlicher Releasezyklus von 12 bis maximal 18 Monaten wäre völlig o.k.
Wer halbjährliche Releases will kann ja SuSE oder neandere Distro nehmen und rpm-apt nachrüsten.
Bei halbjährlichen Releasen darf man dann aber auch nicht jammern wenn nur SuSE-Qualität erreicht wird.
Bye
Vielleicht laufen meine SuSEn aber einfach nur gut. Muss wohl ein glücklicher Zufall sein.
Nicht das man immer das Neueste bräuchte, aber im Allgemeinen steigen auch die Funktionalitäten und Stabilität, wie z.B. bei MPlayer ganz erheblich. Und sich sowas jedesmal selbst zu kompilieren, wenn man vorher die Bibliotheken zu aktualisiseren hat, ist ganz schön mühsam. Gerade die Probleme mit Mplayer und Xine haben mich von Suse zu Gentoo migrieren lassen. Es machte unter dem Strich weniger Arbeit, selbst wenn allzuoft manche EBuilds fehlerhaft sind.
Bei den Paketen werden nur Sicherheitsupdates und sonstige Bugfixes geupdatet, keine umfangreichen Änderungen.
fabian
Unsinn. Sowas macht man nicht. Weder bei Debian, noch bei einer anderen Distribution.
Ich hab bei Debian-Woody noch niemals einen Server gehabt, der durch ein automatisches Update zerrissen wurde. Bei gemachten Updates wird einfach ne Mail an den Admin gesendet, der diese wohlwollend zur Kenntnis nimmt. Wenn das Update was zerreißen sollte, dann weiß man sofort wo man suchen muß. Für mittelständische Firmen ist das Security-Framework von Debian wie ein Gottesgeschenk.
Mind
cya, jens:wq
Doch. Viele Updates benoetigen weitere Handgriffe. Ein Kernel Update wird erst aktiv nach einem Reboot, ein Update von OpenSSL fixed nicht die Programme die bereits laufen und noch die alte Version im Speicher haben.
Automatische Update sind gefaehrlich. Man wiegt sich in falscher Sicherheit.
Mind
Einfaches Bsp. neulich gab es ein gnupg update, einer unserer Kunden Verschlüsselt über PHP mit gnupg Online-bestellungen. Bis vor dem update war das importieren ohne "" nach dem update mit "" anführungszeichen, schlussfolgerung dessen das PHP Script lief nicht mehr. Wäre das autom. Passiert hätte man nicht wirklich nachvollziehen können auch wenn Du das update mit Protokollierst nicht, denn gesetz den Fall du machst jeden Tag ein apt-get update && apt-get upgrade und schreibst den output in eine Liste. Nun wird aber nicht jeden Tag eine Bestellung ausgeführt sondern meinetwegen nach 2 Wochen wo es schon wieder 3 neue Updates gab weißt du was dann wirklich los war?
Mal ganz zu schweigen davon wie entscheidest Du voher schon welches update eingebspielt werden sollen wenn du mit listbugs arbeitest? Bei Listbugs wird das neue Paket nach bugs abgefragt wenn Bugs vorhanden sind wird gefragt ob Du es dennoch installieren willst, klar ich könnt ihm ein yes mitteilen aber was ist wenn wirklich Kritische Fehler mit drinn sind, wie würdest Du das autom. wollen oder updatest du nur unkritische Pakete? - toll weil dann kannst du das gleich ganz lassen denn dann werden Pro Monat vermultich nur 2 updates eingespielt die kein bekannten bug haben.
Nachwie vor sollten Administratoren vom jeweiligen System wenn möglich eine Testumgebung haben. - Der aufwand ist sichlich grösser und der jeweilige Administrator wird mangels aus Zeit nichts anderes machen können aber so wäre garantiert das sich keine ungewollten Fehler einschlechen oder die Chance das wäre um einiges geringer das etwas Passieren kann.
Das trifft nicht nur auf Debian das ist gleich zusetzen mit allen Paketorientieren Distributionen auch unter Windows. Dich möchte ich nicht als Administrator in einer Firma haben wollen ernsthaft das ist faulheit und dummheit auf einmal.
>
Woher nimmst Du die Weisheit zu wissen, daß das niemand macht? Bist Du Gott?
> Online-bestellungen. Bis vor dem update war das importieren ohne "" nach dem update mit ""
> anführungszeichen, schlussfolgerung dessen das PHP Script lief nicht mehr.
Bist Du Dir wirklich sicher, dass das in stable war? Der letzte gnupg-upgrade war am 14.2.04, also nicht mehr ganz "neulich". Ich kann mir aber nicht wirklich vorstellen, dass es so ein gravierender upgrade-bug in stable gegeben hat.
Wer ein automatisches update/upgrade in testing oder unstable macht ist natürlich selber schuld.
Bram
>Nachwie vor sollten Administratoren vom jeweiligen System wenn möglich eine Testumgebung haben. - Der aufwand ist sichlich grösser und der jeweilige Administrator wird mangels aus Zeit nichts anderes machen können aber so wäre garantiert das sich keine ungewollten Fehler einschlechen oder die Chance das wäre um einiges geringer das etwas Passieren kann.
Viele kleine Firmen können diesen Aufwand einfach nicht leisten. Wenn du dann die Wahl hast keine IT oder IT ohne Labor, dann ist die IT ohne Laborumgebung immer noch besser.
>Mal ganz zu schweigen davon wie entscheidest Du voher schon welches update eingebspielt werden sollen wenn du mit listbugs arbeitest? Bei Listbugs wird das neue Paket nach bugs abgefragt wenn Bugs vorhanden sind wird gefragt ob Du es dennoch installieren willst, klar ich könnt ihm ein yes mitteilen aber was ist wenn wirklich Kritische Fehler mit drinn sind, wie würdest Du das autom. wollen oder updatest du nur unkritische Pakete? - toll weil dann kannst du das gleich ganz lassen denn dann werden Pro Monat vermultich nur 2 updates eingespielt die kein bekannten bug haben.
In stable werden NUR kritische Bugs behoben. Das heißt, das jedes Update nötig ist(Ok lokale ausnutzbare Lücken müssten bei einem System ohne lokale User nicht upgedatet werden). Nach meiner Erfahrung bewegt sich die Wahrscheinlichkeit das ein automatisches Debian-STABLE-Update das Produkivsystem zerreißt, bei nahezu Null. Die Wahrscheinlichkeit das sich das mittelständische Unternehmen keine anständige IT leisten kann/will, ist dagegen weit höher.
>Dich möchte ich nicht als Administrator in einer Firma haben wollen ernsthaft das ist faulheit und dummheit auf einmal.
Dummheit wäre es, wenn du nicht weißt was du tust. Faulheit wäre es, wenn du die Zeit für die ideale Administration bekommen würdest und trotzdem nicht ideal administrieren würdest.
Außerdem sehe ich immer noch keine Grund wieso ich das Update nicht automatisch machen sollte, und mich von den Update per Mail informieren lasse. Wenn du keine Laborumgebung hast, dann mußt du das Update auch am Produktivsystem machen. Das geht natürlich nur, wenn das die Firma nicht Millionen kostest, wenn im EXTREMFALL mal was schief geht und der Server ne Stunde nicht läuft. Solche Firmen haben dann aber auch selber Schuld, wenn sich sich kein Laborsystem leisten. Doch beim Mittelstand ist es eher das Problem, das sie sich die anständige IT nicht leisten können.
Das ist ne ganz einfache Kosten/Nutzen-Analyse.
Ich finde solche Aussagen wie von dir, extrem wirklichkeitsfremd. Ich bin jemand, der jedem Unternehmen mit IT erzählt, das es eigendlich eine Security-Police benötigt und daraus das Sicherheitskonzept erarbeitet werden muß. Dazu gehört auch die regelmäßige Mitarbeiterschulung und Konzepte für Reaktionen im Schadensfall. Dank der "Unmöglichkeit" Bugfreie Programme zu erkennen, wird Intrusion und Misuse-Detektion auf Network und Hostebene benötigt. Auch sollte das Know-How vorhanden sein, eine gerichtsverwertbare Beweißkette beim erkennen eines Mißbrauches zu führen.
Und jetzt rate mal, wie viele Mittelständler eine Security-Policy haben. Das sind nahezu Null. Das Sicherheitskonzept ist meist das, was sich der Admin aus den Fingern gesaugt hat. Eventuell sind mal Host-Intrusion-Detektion-Systeme wie Aide im Gebrauch, doch die sind meist installiert und nicht auf einer CD zu finden - also manipulierbar. Network-Intrusion-Detection-Systeme sind dagegen nahezu im Land der Mythen einzuordnen. Und sollte mal eins Vorhanden sein, dann ist der Admin zu 99% durch zu viele false-positiv's überfordert.
Einen vorhandenen Plan zur lückenlosen Führung einer gerichtsverwertbaren Beweißkette bin ich noch nie begegnet.
Was mir aber regelmäßig über den Weg läuft, sind Server die in Firmen installiert werden, und daraufhin darauf warten das jemand sie besser benutzen kann als die Firma. Diese Firmen sind sehr gut beraten, wenn sie ihr Debian-STABLE automatisch updaten und so die Wahrscheinlichkeit das was passiert von 100% auf 0,1% zu verringern.
Aber sehr wahrscheinlich bin ich ja zu blöde, um zu sehen wie das in real existierenden Firmen abläuft.
Mind
Das war dann wohl ein Versionsupdate und mithin _nicht_ Debian Stable denn solche wird da nicht gemacht. Da werden nur in die in Stable enthaltenen Versionen sicherheitsrelevante Patches eingepflegt, die nichts am Verhalten des Programms ändern.
> keine umfangreichen Änderungen.
Das ist in etwa bei jeder ernstzunehmenden Distribution so. Z.B. Suse hat das auch shcon immer so gehandhabt.
In manchen Umgebungen ist die Stabilität einer Distribution wesentlich wichtiger als die Aktualität.
z.B. auf Servern oder auf Desktops in Firmen. Eine stabile Distribution ist vor allem wesentlich leider zu pflegen als eine Distribution die sich ständig verändert.
Bei privaten Desktops ist Aktualität gefragt und dafür gibt es bei Debian ja den Testing und den Unstable Zweig. Der Unstable Zweig enthält die aktuellsten Pakete die nach einiger Zeit dann in den Testing Zweig wandern, sofern keine größeren Probleme aufgetreten sind.
schon eine Nachfrage geben. In zukunft also erst Kopf einschalten, dann schreiben...
Wenn du jetzt wirklich wissen willst für was man Debian gebrauchen kann, dann suche einfach mal nen bischen in irgendwelchen distri-flame-wars da wirst du ganz schnell fündig. Selbst hier irgendwas auflisten werde ich hier nichts, da dein posting einfach zusehr nach flame ausschaut....
Es gibt natürlich gewisse Punkte, bei denen es sinnvoll ist, das Konzept der Stabilität aufzugeben. Wenn beispielsweise der Kernel bei bestimmten Aktionen reproduzierbar abstürzt und man diesen Crash dann mit einem Fix behebt, dann hat man auch das Verhalten des Gesamtsystems verändert: vorher stürzte es ab, hinterher nicht mehr. Das gleiche gilt für das Beheben von Sicherheitslücken. In gewissem Sinne ist das nicht mehr "stabil", weil sich das Verhalten geändert hat, aber es handelte sich eben um unerwünschtes Verhalten, das korrigiert wurde. Bei Sicherheitslücken oder Systemcrashes ist es allerdings recht einfach, einen generellen Konsens zu erzielen, was unerwünschtes und was erwünschtes Verhalten ist. Wenn aber ein Benutzer gerne das Foo Desktop Environment in Version 42 statt Version 17 haben möchte, weil ihm die runden Icons von Version 42 besser gefallen als die eckigen von Version 17, dann dürfte es schwierig sein, die Nutzer- und Entwicklergemeinschaft davon zu überzeugen, dass eckige Icons unerwünschtes Verhalten sind.
jwm
Ich kann mich daran erinnern das Firefox (ich glaube 0.9 oder 1.0) nicht ins testing kam weil es sich nicht auf mips kompilieren ließ.
Der Schritt ist zwar etwas drastisch es hätte wohl auch gereicht einfach den X Bereich nur für die "gängingen" 4 Architekturen anzubieten.
husky
Schön
kompiliert, nicht den ganzen Release verzoegern darf,
obwohl es auf allen anderen Releaseplattformen keine
Probleme macht.
Und das wird doch schon seit bald zwei Jahren immer
wieder diskutiert. Jetzt hat man ein gutes Ergebnis
(Hauptplattformen Release, SCCs spaeter und nicht
zwingend im selben Umfang) und es gibt immer noch
welche die darueber meckern. Ich sehe ueberhaupt keine
Alternative zu dieser Entscheidung.
Wo bitte ist denn fuer einen MIPS-User der Unterschied,
ob sein MIPS-Release nach drei Jahren erscheint (z.Bsp. ein
Jahr nach dem Release der "Populaeren"), oder nach den
gleichen drei Jahren (nun aber gemeinsam mit den Populaeren)?
Richtig, fuer den MIPS-User macht das keinen Unterschied,
aber fuer die anderen sehr wohl!
> ob sein MIPS-Release nach drei Jahren erscheint (z.Bsp. ein
> Jahr nach dem Release der "Populaeren"), oder nach den
> gleichen drei Jahren (nun aber gemeinsam mit den Populaeren)?
Die grosse Angst duerfte wohl sein das der Support fuer die exotischen
Plattformen schleichend stirbt. Heute wird MIPS in der Prioritaet zurueck
gesetzt, morgen komplett aufgegeben, oder so aehnlich.
Waer ja nicht das erste Projekt das so verfaehrt.
It's for this reason that all architectures are required to be synced to the same kernel version for sarge, but even so, more per-architecture kernel help is needed, particularly for the sparc and the arm port.
Sicherlich ist der Schnitt hart, aber ich denke, auf lange Sicht tut sich das Debian Projekt eher damit einen Gefallen, mit weniger Architekturen zu releasen, als einen Release wegen fehlenden Supports auf bestimmten Architekturen auf unbestimmte Zeit zu verschieben.
> Sicht tut sich das Debian Projekt eher damit einen Gefallen,
> mit weniger Architekturen zu releasen, als einen Release wegen
> fehlenden Supports auf bestimmten Architekturen auf unbestimmte
> Zeit zu verschieben.
Ack.
Ich denke, das Hauptproblem der meisten (Desktop-)User ist, daß sie mit dem Titel "Testing" Instabilität verbinden. Ich hatte bisher (~2 Jahre Testing-Nutzung) keine Situation, in der mir ein Paket so richtig abgeschmiert wäre, weder auf meinem kleinen Homeserver noch auf meinem Desktop.
Vielleicht wäre ein anderer Name für Testing sinnvoller? Vielleicht 'Preview' oder 'Sneak' oder sowas...?
Just my 2cent,
husky
Einzige Lösung, die in <3 Stunden ging: Debian_exim die uid von mail zuweisen.
Ich will mich gar nicht beschweren oder so, so was kann in Testing passieren, aber genau deswegen würde ich keine Server mehr mit Testing laufen lassen. Klar, zum Ende einer Release-Periode wird Testing immer stabiler und wird von vielen Nutzern auch empfohlen (das konnte man schon bei Woody sehen), aber ein Ersatz für ein Release ist das imho nicht.
Und Woody ist inzwischen einfach veraltet. Z.B. Exim: Wenn man auf exim-users mit einem 3.x Problem anfragt, wird zu 90% einfach eine Antwort kommen wie "wird nicht mehr unterstützt.".
fs
Vielleicht könnte man für diesen Architekturen einen extra Server-Zweig einrichten , der
für diese Gruppe von Anwendern zugeschnitten ist .
Der Pflegeaufwand würde sich dann verringern , weil die Desktopanwendungen nicht mehr den
Auwand aufblähen .
Nein, das wird nicht gehen.
Ich wuerde es eher fuer sinnvoll halten, dass Debian die Sektionen Base und Standart alle 9-18 Monate released, und dann basierend darauf weitere Zweige aufgebaut werden. Sowas wie Snapshot-Release fuer Gnome, oder Snapshot-Release KDE.
Das birgt dann wieder andere Risiken... Naja, wir werden sehen.
*lol* ich freue mich schon wieder auf die endlosen Diskussionen, ob das jetzt richtig ist oder nicht. Wenn sie das zu Ende diskutiert haben werden bei debian, dann wird wahrscheinlich i386 auch schon outdated sein ;=)
CU popel
> endlosen Diskussionen, ob das jetzt richtig
> ist oder nicht. Wenn sie das zu Ende diskutiert
> haben werden bei debian, dann wird wahrscheinlich
> i386 auch schon outdated sein ;=)
mh, und sarge kommt dann noch spaeter raus
Außerdem bin ich mir nicht sicher, ob das überhaupt so viel bringt. Die häufigsten Portabilitätsprobleme sind Endianness und Adressbreite. x86 und AMD64 sind Little-Endian, IA64 ist Bi-Endian, die Linux-Portierung ist aber Little-Endian, PowerPC ist Bi-Endian, die Linux-Portierung ist aber Big-Endian. Mit anderen Worten: bei der Endianness ist schon mal nichts gewonnen, dafür müsste man auch noch PowerPC rauswerfen. Bleibt noch die Adressbreite: x86 und PowerPC sind 32 Bit, IA64 und AMD64 sind 64 Bit, um hier etwas zu gewinnen, müsste man IA64 und AMD64 noch rauswerfen. Als letztes Problem bleibt noch die Performance: viele Software ist handoptimiert für x86, zum Beispiel hängt mein betagter Pentium III den Opteron bei PearPC locker ab: es gibt zwar den G3-zu-Pentium Just-in-Time-Compiler, aber der läuft natürlich nicht im Long-Mode, auf dem Opteron muss ich also auf die generische CPU-Emulation zurückgreifen, die aber etwa 15-mal langsamer ist als der JITC. Das kann der Opteron auch mit seiner dreimal höheren Taktfrequenz und der doppelten Registerzahl nicht aufholen. Ähnliches gilt auch für viele Multimedia-Codecs, für die es häufig handoptimierten MMX- oder SSE-Assemblercode, nicht aber IA64- oder VMX-Assembler gibt.
jwm