On Wed, 23 Jan 2002, Ratti wrote:
Ein anderer Kundenkreis jammert über Versioneritis und hätten am liebsten die Konfiguration, die unverändert die 90er Jahre durch stabil gelaufen ist, bis ihr Rechner verreckt ist.
Naja, es gibt _verdammt_ alte Kernel auf ftp://ftp.kernel.org/pub/linux/kernel... Auch dieser Wunsch kann also erfuellt werden... Und ne SuSE 5.3 hab ich hier auch noch (inkl. Live-CD) auf 5 CDs rumfahren (nein, die geb ich nicht her).
Welche _Chance_ hat ein Distributor, alle glücklich zu machen?
Keine.
ACK! [..]
Die eierlegende Wollmilchsau mit drei Kerneln gleichzeitig,
Geht. Naja, ausser auf IBMs s/390 (IIRC) nicht gleichzeitig, aber zumindest abwechselnd. (achso: $ ls /boot/bzImage-2.* /boot/vmlinuz* /boot/2.2.1*/{vmlinux,bzIma*} | wc -l 35 Welche davon (noch) in der lilo.conf stehen oder gar, welche ich davon verwende ist ein anderes Thema...
stabiler und sicherer Serverumgebung, bunter simpel-GUI,
Was spricht gegen 2.2.x + KDE 1.1.2? letzteres laeuft bei mir seit $ rpm -q --queryformat "%{NAME} %{VERSION}-%{RELEASE}, %{DISTRIBUTION}, " klibs; rpm -q --queryformat "%{INSTALLTIME}" klibs | xargs epochtodate klibs 1.1.2-85, SuSE Linux 6.4 (i386), Sun 09.07.2000 08:48:32 CEST stabil, und auch das war noch ein Update...
mit superprofessioneller Leistung ohne denken zu müssen gibt es nicht, kann es nicht geben - außer man kauft sich die "Privat Edition" - sprich: Einen kompetenten Menschen, der das System individuell für mich zurechtschneidert. Dann aber nicht für DM 129.
Ack.
Ich bin sehr froh über "Versioneritis".
Ich nicht. Oder du verstehst Versionitis flasch. SuSE 7.0 ist ein Beispiel fuer Versionitis. Neue, oder aktualisierte -- stabile, oder "korrigierte" -- Versionen sind _kein_ Anzeichen von Versionitis. Ein "$VER > $FOO" auf Deubel komm raus hingegen schon. Wie das eben IMHO bei 7.0 der Fall war. Dass man _auch_ nen Kernel 2.4.x mitlieferte, oder dass auch Yast2 verbessert wurde war IMO kein Argument fuer eine neue Major-Version...
Sie gibt mir die Möglichkeit, regelmässig mein System auf den neuesten Stand zu bringen, ohne jede Nacht zu saugen und zu kompilieren.
Ack. (naja, wenn die .specs oder Makefiles vorhersehbar gut waeren, waere auch eine Rekompilation per cronjob kein Problem... Aber dem ist leider nicht so, und daher sollte man eben "von Hand" kompilieren. [..]
Lieber öfter mal eine neue Version, die Bugs kriegen wir schon behoben - und wer nicht mag, kauft's sich einfach nicht. Linux ist nicht Windows oder MacOS - man muß nicht das neueste haben, damit der Kram überhaupt funktioniert.
Jep. Funktionieren tut's auch mit $URALT_VERSION, nur muss man dann eben auf das ein oder andere neue Feature verzichten oder die ein oder anderen Sicherheits-Luecke in Kauf nehmen... GS oder sendmail kommen mir da z.B. in den Sinn... Und manchmal hat die neue Version gravierende Nachteile... (z.B. KDE2), da muss (und kann!!!) dann jeder eben selbst entscheiden... Das schoene ist, dass man eben die Wahl hat! Die Politik z.B. von M$ bzgl. Updates/Fixes aelterer Versionen von Windows ist wuest... Und ja, ich verwende hier z.B. einen munteren Mix aus alten und aktuellen Versionen -- ohne (groessere) Probleme. Teilweise ist "mein OS" aktueller als die neueste SuSE (inkl. Online-updates), teilweise gut 2 Jahre alt... Das meiste ist irgendwo zwischen SuSE 6.4 und 7.2... ==== Eine Zeile! C&P faehig ==== for p in `rpm -qa`; do t=`rpm -q --queryformat \ "%{INSTALLTIME}" $p`; rpm -q --queryformat \ "$t %{NAME} %{VERSION}-%{RELEASE}, %{DISTRIBUTION}\n" $p; \ done | sort -n | while read datum rest; do \ echo -e "`epochtodate $datum`\t - $rest"; done | head ==== <return> ==== ==== -> Ausgabe ==== Mon 16.08.1999 19:19:04 CEST - bc 1.04-74, SuSE Linux 6.2 (i386) Mon 16.08.1999 19:19:08 CEST - tcsh 6.08.05-5, SuSE Linux 6.2 (i386) Mon 16.08.1999 20:26:51 CEST - aaa_dir 99.7.12-0, SuSE Linux 6.2 (i386) Mon 16.08.1999 20:26:52 CEST - aaa_skel 99.4.9-0, SuSE Linux 6.1-BETA [..] ==== ==== NB: an die (auch) Debianer (f'up per PM!): Geht sowas wie oben auch mit 'apt(-get)' bzw. 'dpkg'? Und _gut_ dass man unter Linux "mal eben" gegen seine "alten" libs neu kompilieren kann, ich habe hier "massig" Zeug, das es als Binary nur gegen die glibc 2.2.x gelinkt gibt, ich verwende es hier munter rekompiliert gegen die glibc 2.1.3 :) -dnh PS: epochtodate ist mein kleines C-Proggie, dass Argumente in Sekunden mittels strftime in ein lesbares Datum umwandelt ;) Quellcode auf Anfrage per PM. ===== epochtodate -h ==== Usage: epochtodate [-u] SECONDS ... Converts the "epoch" given in SECONDS since 1970-01-01 00:00 to a readable date (e.g. use `date "+%s"`, but that's the default anyway). Set the Timezome via the environment variable TZ Options: -u use UTC, not localtime -f FORMAT use FORMAT as format string for strftime(7) -h, --help prints this help ===== (Wie man sieht, ist das eher "ad hoc" entstanden, und wohl kein Beispiel dafuer, wie man (sicher) programmiert... Wenn allein schon die Hilfe falsch bzw. in sich widerspruechlich ist... *g*) -- 136: Deadline Programmtod durch überhastete Weiterentwicklung eines falsch konstruierten Entwurfsmusters. (Lutz Donnerhacke)