welche Distribution
Sebastian Deiszner
ich möchte einen kleinen Server mit Apache, MySql, Cyrus und Postfix mit
einer festen IP betreiben.
Ich habe jetzt 4 Distributionen - RedHat 9, Suse 8.0 Prof., Mandrake 9 und
Debian 3.01.
Alle sehen beim SSH Zugriff gleich aus - daher ist die äußere Ästhetik
nicht unbedingt ausschlaggebend.
Welche Distribution könnt Ihr für diese Zwecke empfehlen?
Danke
Sebastian
Udo Blasel
> Ich habe jetzt 4 Distributionen - RedHat 9, Suse 8.0 Prof., Mandrake 9
> und Debian 3.01.
> Welche Distribution könnt Ihr für diese Zwecke empfehlen?
No4.
--
Leere Sig. Uvre xöaagr vuer Jreohat fgrura.
Marcus Frings
> ich möchte einen kleinen Server mit Apache, MySql, Cyrus und Postfix mit
> einer festen IP betreiben.
> Ich habe jetzt 4 Distributionen - RedHat 9, Suse 8.0 Prof., Mandrake 9 und
> Debian 3.01.
> Alle sehen beim SSH Zugriff gleich aus - daher ist die äußere Ästhetik
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Das ist natürlich mal eine
äußerst wichtige Bemerkung für die Welt nachkommender Generationen.
> nicht unbedingt ausschlaggebend.
> Welche Distribution könnt Ihr für diese Zwecke empfehlen?
Debian. Aus Gründen der Stabilität, Wartbarkeit und Security.
Prinzipiell ist aber jede Distribution geeignet -- lies die FAQ!
Außerdem sind Deine Umlaute nicht deklariert. Such nach der OE FAQ und
behebe Dein Problem!
Gruß,
Marcus
--
"Tuba cum sonuerit dies erit extrema
et iudex advenerit vocabit sempiterna
electos in patria
prescitos ad inferna."
Norbert Tretkowski
[...]
> Welche Distribution könnt Ihr für diese Zwecke empfehlen?
Norbert Tretkowski
> Ich wüßte nicht, warum SuSE oder was immer weniger stabil sein
> sollten.
Weil es einige Distributoren toll finden, den Kernel mit vielen
inoffiziellen Patches zu versauen. Je nach Hardware macht das dann
mal mehr, mal weniger Probleme.
Oliver C. Jung
>Weil es einige Distributoren toll finden, den Kernel mit vielen
>inoffiziellen Patches zu versauen. Je nach Hardware macht das dann
>mal mehr, mal weniger Probleme.
Das sollte aber im großen und ganzen nichts an der Stabilität
ändern. Das Patchen führt doch meistens nur dazu, dass es mehr
Kernel-Module gibt. Werden die nicht benötigt, bieten sich dem
Anwender keine Unterschiede...
ocj
--
Oliver C. Jung - Dortmund/Bochum - Germany
Bitte keine Antworten per email!
Andreas Kretschmer
>> Debian. Aus Gründen der Stabilität, Wartbarkeit und Security.
>
> sein sollten.
Prinzipiell ACK, allerdings ist SuSE irgendwie geil darauf, immer das
aktuellste und damit unreifste zu nehmen. Das macht es echt schwer,
einen Server, der mit SuSE versehen ist, sympatisch zu finden...
SuSE ist im Vergleich zu Debian immer das jeweil aktuelle unstable, und
das will man nicht, wenn es was produktives sein soll.
Dazu kommt: wenn man SuSE sagt, dann impliziert das auch YaST. Hast Du
das bei einer SuSE 8.2 schon mal über eine lahme 64 KBit-Leitung
getestet? Wenn nicht: tue es lieber nicht.
Und hast Du schon mal eine SuSE 8.2 auf einer Gurke, die mit PII und 32
MByte für eine ISDN-DialUp-Leitung iptables-Paketfilter spielen soll
installiert? Wenn nein, versuche es nicht erst, Zeitverschwendung.
Aber mal ehrlich: das ich _Dir_ das erklären muß? Das macht mich
stutzig...
end
Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)
Robin S. Socha
> begin Robin S. Socha <ro...@socha.net> wrote:
>>> Debian. Aus Gründen der Stabilität, Wartbarkeit und Security.
>>
>> Linux ist Linux. Ich wüßte nicht, warum SuSE oder was immer weniger
>> stabil sein sollten.
>
> Prinzipiell ACK, allerdings ist SuSE irgendwie geil darauf, immer das
> aktuellste und damit unreifste zu nehmen. Das macht es echt schwer,
> einen Server, der mit SuSE versehen ist, sympatisch zu finden...
Tut mir leid, aber das nach meiner eigenen Erfahrung falsch.
> SuSE ist im Vergleich zu Debian immer das jeweil aktuelle unstable,
> und das will man nicht, wenn es was produktives sein soll.
Das ist definitiv falsch. Ja, man *kann* irgendwelche Entwicklerversionen
einspielen. Aber bei Systemdiensten ist mir das bei SuSE (nb: letzte SuSE,
die ich auf einem Produktivsystem hatte, war 7.2) noch nicht untergekommen.
> Dazu kommt: wenn man SuSE sagt, dann impliziert das auch YaST. Hast
> Du das bei einer SuSE 8.2 schon mal über eine lahme 64 KBit-Leitung
> getestet? Wenn nicht: tue es lieber nicht.
Ich habe YaST nur für die Installation verwendet.
> Und hast Du schon mal eine SuSE 8.2 auf einer Gurke, die mit PII und 32
> MByte für eine ISDN-DialUp-Leitung iptables-Paketfilter spielen soll
> installiert? Wenn nein, versuche es nicht erst, Zeitverschwendung.
Warum sollte ich das tun? Für solche Zwecke ist OpenBSD IMNSHO die
*erheblich* bessere Wahl. Und mit *erheblich* meine ich "ich würde
niemals wieder freiwillig etwas anderes als OpenBSD auf einem Gateway
installieren".
> Aber mal ehrlich: das ich _Dir_ das erklären muß? Das macht mich
> stutzig...
Och... SuSE-bashing ist irgendwie lustig, weil halt die meisten
Verlierer hier SuSE haben (seit jüngstens Mandrake). Aber das heißt
nicht, daß SuSE nicht eine außergewöhnlich gute Distribution
ist. OpenBSD, FreeBSD, Debian, SuSE - das wäre die Reihenfolge, in der
ich einen Rechner heutzutage aufsetzen würde.
Thomas Skora
> Prinzipiell ACK, allerdings ist SuSE irgendwie geil darauf, immer das
> aktuellste und damit unreifste zu nehmen.
Wenn sich an Redhat nichts geändert hat, dürften die gleichen Gründe
für eine Disqualifizierung sprechen. Ich denk da nur an gcc-2.96 und
was die da sonst noch an unstable Software reingepackt haben.
Thomas
Andreas Kretschmer
> ist. OpenBSD, FreeBSD, Debian, SuSE - das wäre die Reihenfolge, in der
> ich einen Rechner heutzutage aufsetzen würde.
Oh, dann bin ich auf Platz 2 von hinten...
*verlegen am Kopf kratz*
Andreas Wiese
> * Andreas Kretschmer <krets...@kaufbach.delug.de> writes:
>> Und hast Du schon mal eine SuSE 8.2 auf einer Gurke, die mit PII und 32
>> MByte für eine ISDN-DialUp-Leitung iptables-Paketfilter spielen soll
>> installiert? Wenn nein, versuche es nicht erst, Zeitverschwendung.
>
Mein 'Arbeits-'Rechner ist so eine 'Gurke' (gut, an RAM hat sie das
10-fache).
> Warum sollte ich das tun? Für solche Zwecke ist OpenBSD IMNSHO die
> *erheblich* bessere Wahl. Und mit *erheblich* meine ich "ich würde
> niemals wieder freiwillig etwas anderes als OpenBSD auf einem Gateway
> installieren".
>
#v+
awiese@schroeder:~> ssh woodstock uname -sr
NetBSD 1.6T
awiese@schroeder:~>
#v-
*duck*.
SCNR
Was ich daran allerdings (noch - ich nehme an, ich hab's nur noch
nicht gefunden) vermisse, ist ein Pendant zum Linux-isdnctrl. DoD kann
ich mir nicht leisten ;) und staendig 'ifconfig ippp0 up/down' ist IMHO
laestig.
[snip...]
Gruesse,
awiese
--
Vor Gott waren alle Menschen gleich. Seit er hier ist, gibt es
Unterschiede.
Rainer Weikusat
> Norbert Tretkowski <usene...@bzimage.de> schrieb:
>>Weil es einige Distributoren toll finden, den Kernel mit vielen
>>inoffiziellen Patches zu versauen. Je nach Hardware macht das dann
>>mal mehr, mal weniger Probleme.
>
> Das sollte aber im großen und ganzen nichts an der Stabilität
> ändern.
Gerade bei SuSE gab es da schon abschreckende Gegenbeispiele. 'Once
upon a time' gab es mal ein kernel-feature zum automatischen
masskieren von TCP-Verbindungen mit 'alten' dynamischen Quelladressen,
das beim Wechsel 2.0 -> 2.2 aus 'politischen Gründen' ausgebaut wurde
(die offizielle Linux-Lösung war auch sehr unschön, weil sie
absichtlich fehlerhafte Datagramme verschickt hat, um den anderen host
zu einem RST zu provozieren). Es gibt zwei mir bekannte
in-kernel-Lösungen für dieses Problem: Den 'IFF-dynamic'-patch, den
die Firma SuSE derzeit in ihrer Kernel eingebaut hat (häßlich und mit
diversen unbeabsichtigten Nebenwirkungen) und irgenwas, das sich zur
selben Zeit 'für die Firma' programmiert hatte (unsere
Telephonrechungen waren einen Monat lang etwas hoch ...) und das wir
dann ~1.5 Jahre problemfrei im Dauereinsatz hatten.
Der 'sinnvolle' Ratschlag bzgl Kernel ist wohl, das man
kernel.org-Quellen nehmen sollte und da gezielt die features
reinpatchen, die man auch wirklich haben möchte.
Andreas Kretschmer
>> SuSE ist im Vergleich zu Debian immer das jeweil aktuelle unstable,
>> und das will man nicht, wenn es was produktives sein soll.
>
> Das ist definitiv falsch. Ja, man *kann* irgendwelche Entwicklerversionen
> einspielen. Aber bei Systemdiensten ist mir das bei SuSE (nb: letzte SuSE,
> die ich auf einem Produktivsystem hatte, war 7.2) noch nicht untergekommen.
Anmerkung dazu:
$Kollege bat mit, auf $Maschine doch nun mal $MTA zu installieren, um
von $bösem_MTA wegzukommen. Also Quellpaket geladen und kompiliert.
Tausendmal probiert, tausendmal funktioniert. Auf dieser Kiste nicht.
Installiert war SuSE 8.2 und gcc 3.2 (oder 3.3).
(ja, ich weiß, gcc ist kein Systemdienst)
Ich weiß, daß $Kollege nie etwas kompiliert und wenn er installiert die
Defaults nimmt, also gehe ich davon aus, das es keine direkte Absicht
war. Also alten gcc (2.9x sonstwas) geholt und alles war gut.
PS.: Deine Erfahrungen zu SuSE sind Update-würdig. Oder auch nicht.
Jedenfalls habe ich zuletzt SuSE 7.3 verwendet, das war noch okay. Vor
einigen Monaten habe ich mal $Kollege bei Installation von SuSE 8.1
beobachtet, YaST2. Muß ich mehr sagen?
Okay, SuSE mag ja für Endnutzer okay sein. Das wars dann aber auch, die
Zielgruppe ist deutlich nicht die der Admins, die mehr können/wollen als
Mäuse zu schubsen. Der erste Satz in diesem Absatz, um nicht den Vorwurf
des SuSE-Bashings aufkommen zu lassen...
PS.: $Kollege bat mich heute, ihm bei Installation von Debian kurz zu
helfen. Nun ist er auch auf Stufe 2 (von hinten) auf der im anderen
Posting deklarierten Socha-Skala ;-)
Andreas Wiese
[snip...]
> PS.: Deine Erfahrungen zu SuSE sind Update-würdig. Oder auch nicht.
> Jedenfalls habe ich zuletzt SuSE 7.3 verwendet, das war noch okay. Vor
> einigen Monaten habe ich mal $Kollege bei Installation von SuSE 8.1
> beobachtet, YaST2. Muß ich mehr sagen?
>
YaST2, ist das nicht dieses Teil mit den
super-wahnsinnig-toll-effektiven Tastaturbedienung im ncurses-Modus?
Das wo man, bevor man den richtigen Menuepunkt erwischt, sich die
Finger gebrochen hat?
[snip...]
> PS.: $Kollege bat mich heute, ihm bei Installation von Debian kurz zu
> helfen. Nun ist er auch auf Stufe 2 (von hinten) auf der im anderen
> Posting deklarierten Socha-Skala ;-)
>
Ich komm da garnicht vor. Ist das jetzt ein gutes oder ein schlechtes
Zeichen?
[snip...]
Gruesse,
awiese
--
Freu' Dich des Lebens und Du freust Dich umsonst.
Daniel Pichl
> Wenn sich an Redhat nichts geändert hat, dürften die gleichen Gründe
> für eine Disqualifizierung sprechen. Ich denk da nur an gcc-2.96 und
> was die da sonst noch an unstable Software reingepackt haben.
Redhat ist mittlerweile etwas "konservativer" als SuSE. SuSE packt immer
mehr Beta-Pakete drauf (z.B. den angesprochenen gcc in der Version 3.3beta
[SuSE 8.2]), und Redhat beschränkt sich zumeist auf die aktuellsten
freigegebenen Versionen.
Auch sonst habe ich persönlich in letzter Zeit bessere Erfahrungen mit
Redhat als mit SuSE gemacht.
bye, Daniel
Andreas Metzler
[...]
> YaST2, ist das nicht dieses Teil mit den
> super-wahnsinnig-toll-effektiven Tastaturbedienung im ncurses-Modus?
> Das wo man, bevor man den richtigen Menuepunkt erwischt, sich die
> Finger gebrochen hat?
Nein, das ist dselect. :-)
SCNR, cu andreas
Achim Linder
> Andreas Kretschmer <krets...@kaufbach.delug.de> writes:
>
>> Prinzipiell ACK, allerdings ist SuSE irgendwie geil darauf, immer das
>> aktuellste und damit unreifste zu nehmen.
Die pauschale Gleichsetzung von aktuell und unreif ist Blödsinn, und
aktueller als Debian stable dürfte so ziemlich jede Distribution sein.
> Wenn sich an Redhat nichts geändert hat, dürften die gleichen Gründe
> für eine Disqualifizierung sprechen. Ich denk da nur an gcc-2.96 und
Der bei RedHat7 (September 2000) mitgelieferte gcc-2.96 war fehlerhaft,
die gemeldeten Probleme wurden allerdings noch im Herbst 2000 behoben.
Bei Redhat8 und 9 wird der gcc-2.96 nicht mehr verwendet.
Es trifft zu, daß es bei RedHat und Mandrake Probleme beim Compilieren
mit dem gcc-2.96 gab, in den Fällen, die ich mir näher angesehen habe,
handelte es sich aber durchweg um Fehler im Quellcode, nicht im Compiler.
Achim
Thomas Skora
>> Wenn sich an Redhat nichts geändert hat, dürften die gleichen Gründe
>> für eine Disqualifizierung sprechen. Ich denk da nur an gcc-2.96 und
>
> Der bei RedHat7 (September 2000) mitgelieferte gcc-2.96 war fehlerhaft,
> die gemeldeten Probleme wurden allerdings noch im Herbst 2000 behoben.
> Bei Redhat8 und 9 wird der gcc-2.96 nicht mehr verwendet.
War das nicht ein gepachter gcc-3.0?
Thomas
Gerd Knorr
> Es trifft zu, daß es bei RedHat und Mandrake Probleme beim Compilieren
> mit dem gcc-2.96 gab, in den Fällen, die ich mir näher angesehen habe,
> handelte es sich aber durchweg um Fehler im Quellcode, nicht im Compiler.
Und das ist in der Regel bei Programmen die jetzt mit gcc 3.2 / 3.3
nicht mehr bauen auch so ...
Gerd
--
sigfault
Achim Linder
Ein gepatchter Vorläufer von gcc-3.0 (3.0 wurde erst im Juni 2001
veröffentlicht), der aber bis auf die erste Version IMO auch nicht
fehlerhafter als 2.95.2 war - schließlich wurden ja alle 7er Versionen von
RedHat damit übersetzt. Die Bugs im ersten Release und die Probleme mit
dem 2.2.17 von kernel.org wären vermeidbar gewesen, aber ein Großteil des
Ärgers war eh programmiert, weil die 3er-Reihe des gcc (und damit auch
gcc-2.96) bestimmten Code nicht mehr schluckt, der bei gcc-2.95.2 noch
durchgegangen war.
Empfehlen würde ich RedHat trotzdem nicht mehr: fehlerhafte rpm-Version
in 8.0, in 9.0 war der Radeon-Treiber kaputt und als GUI werden nur noch
KDE und Gnome und ein kaputter sawfish mitgeliefert.
Achim
Achim Linder
> Am Tue, 24 Jun 2003 20:14:32 +0200 schrieb Thomas Skora:
>
>> Wenn sich an Redhat nichts geändert hat, dürften die gleichen Gründe
>> für eine Disqualifizierung sprechen. Ich denk da nur an gcc-2.96 und
>> was die da sonst noch an unstable Software reingepackt haben.
>
> Redhat ist mittlerweile etwas "konservativer" als SuSE. SuSE packt
> immer mehr Beta-Pakete drauf (z.B. den angesprochenen gcc in der
> Version 3.3beta [SuSE 8.2]),
Weitere Beispiele?
Ein Upgrade auf 3.3-final wäre BTW kein Fehler, andererseits sollte man
sich Fehlerberichte schon etwas näher ansehen. Bei Problemen mit
Kernel 2.5.70 oder beim Upgrade von einer Distribution mit gcc-2.95.x
stellt sich schon die Frage, ob die nicht auch mit gcc-3.2 aufgetreten
wären.
> und Redhat beschränkt sich zumeist auf die aktuellsten freigegebenen
> Versionen.
RedHat verwendet in den Versionen 8 und 9 die rpm-Versionen 4.1 bzw.
4.2. rpm-4.1 kann man nicht gerade stabil nennen.
Achim
Thomas Skora
> On Tue, 24 Jun 2003 23:57:49 +0200, Thomas Skora wrote:
>> Achim Linder <achim....@nikocity.de> writes:
>>
>>>> Wenn sich an Redhat nichts geändert hat, dürften die gleichen Gründe
>>>> für eine Disqualifizierung sprechen. Ich denk da nur an gcc-2.96 und
>>>
>>> Der bei RedHat7 (September 2000) mitgelieferte gcc-2.96 war fehlerhaft,
>>> die gemeldeten Probleme wurden allerdings noch im Herbst 2000 behoben.
>>> Bei Redhat8 und 9 wird der gcc-2.96 nicht mehr verwendet.
>>
>> War das nicht ein gepachter gcc-3.0?
>
> Ein gepatchter Vorläufer von gcc-3.0 (3.0 wurde erst im Juni 2001
> veröffentlicht), der aber bis auf die erste Version IMO auch nicht
> fehlerhafter als 2.95.2 war
3.0 war noch ziemlich buggy, ich glaub nicht, daß es bei Vorläufern
davon noch besser war. Ich finds einfach nur ziemlich dreist, den
Leuten irgendeine Vorversion des 3.0er gcc's als 2.96 auszugeben,
weils dem nichtwissenden User suggeriert, daß dies eine
Nachfolgerversion vom stabilen 2.95.3 ist.
> - schließlich wurden ja alle 7er Versionen von RedHat damit
> übersetzt.
Wer weiß, was die da rumgepatcht haben...
Thomas
Thomas Skora
>> Es trifft zu, daß es bei RedHat und Mandrake Probleme beim Compilieren
>> mit dem gcc-2.96 gab, in den Fällen, die ich mir näher angesehen habe,
>> handelte es sich aber durchweg um Fehler im Quellcode, nicht im Compiler.
>
> Und das ist in der Regel bei Programmen die jetzt mit gcc 3.2 / 3.3
> nicht mehr bauen auch so ...
Was nicht heißen muß, das es nicht so gewollt war, also aus der Sicht
des Programmierers keinen Fehler darstellt.
Thomas
Thorsten Lange
> weil die 3er-Reihe des gcc (und damit auch
> gcc-2.96) bestimmten Code nicht mehr schluckt, der bei gcc-2.95.2 noch
> durchgegangen war.
Wenn man Softwarepakete selber übersetzen will, dann ist das natürlich
ärgerlich - auch wenn die Fehlermeldungen des gcc-3 durchaus ihre
Berechtigungen haben, wenn der Code unsauber programmiert ist und nur
wegen eines "toleranten" Compilers kompiliert.
Das größte Problem bestand bei Redhats "2.96" allerdings darin, dass
dessen C++-ABI zu nichts ausser sich selbst kompatibel war, weder zum
gcc-3 noch zum 2.95.x. Das ist extrem ärgerlich, wenn die eine oder
andere (dummerweise kommerzielle und nur in Binärform erhältliche)
Software damit übersetzt wurde und man einige Verrenkungen machen
muss, wenn man nicht genau diese RedHat einsetzt. Bäh.
Die C++-ABI ist beim g++ in der letzten Zeit sowieso ein echtes
Ärgernis gewesen. Erst seit der 3.2 scheint die Welt wieder in Ordnung
zu sein.
Bye,
Thorsten
Gerd Knorr
i.e. $programmierer baut absichtlich illegale C oder C++ Konstrukte
ein, die mit 2.95 zufällig funkionieren, mit einem richtigen[tm]
Compiler aber nicht? Das wäre aber eine äußerst eigenwillige Sicht...
Gerd
--
sigfault
Rainer Weikusat
> Thomas Skora <use...@skora.net> writes:
>> Gerd Knorr <kra...@bytesex.org> writes:
>> >> Es trifft zu, daß es bei RedHat und Mandrake Probleme beim Compilieren
>> >> mit dem gcc-2.96 gab, in den Fällen, die ich mir näher angesehen habe,
>> >> handelte es sich aber durchweg um Fehler im Quellcode, nicht im Compiler.
>> >
>> > Und das ist in der Regel bei Programmen die jetzt mit gcc 3.2 / 3.3
>> > nicht mehr bauen auch so ...
>>
>> Was nicht heißen muß, das es nicht so gewollt war, also aus der Sicht
>> des Programmierers keinen Fehler darstellt.
>
> i.e. $programmierer baut absichtlich illegale C oder C++ Konstrukte
> ein, die mit 2.95 zufällig funkionieren,
Nicht unbedingt bloß zufällig. Leute benutzen gcc-Erweiterungen, die
seit Äonen dokumentiert sind und irendwer beschließt, sie aus dem
Compiler auszubauen => bumm.
Achim Linder
> Achim Linder <achim....@nikocity.de> writes:
>> Ein gepatchter Vorläufer von gcc-3.0 (3.0 wurde erst im Juni 2001
>> veröffentlicht), der aber bis auf die erste Version IMO auch nicht
>> fehlerhafter als 2.95.2 war
>
> 3.0 war noch ziemlich buggy, ich glaub nicht, daß es bei Vorläufern
> davon noch besser war.
Der 2.96 war nun mal brauchbarer als die ersten 3.0-Versionen.
> Ich finds einfach nur ziemlich dreist, den Leuten irgendeine Vorversion
> des 3.0er gcc's als 2.96 auszugeben, weils dem nichtwissenden User
> suggeriert, daß dies eine Nachfolgerversion vom stabilen 2.95.3 ist.
Den gcc-2.95.3 gab es erst ein halbes Jahr nach dem 2.96, der 2.95.2
hatte beim Erscheinen von RH7 schon fast ein Jahr auf dem Buckel, und bei
RedHat hatte man sich eben dafür entschieden, die Manpower ins Debuggen
der 3er-Serie zu stecken, statt in den 2.95.x-Seitenast. Man hätte ihn
besser anders genannt, allerdings hätte das an der Kritik wohl nicht viel
geändert.
>> - schließlich wurden ja alle 7er Versionen von RedHat damit
>> übersetzt.
>
> Wer weiß, was die da rumgepatcht haben...
Sie haben einen Haufen Pakete gepatcht, damit sie sich mit der 3er
Serie übersetzen lassen. Ich wüßte nicht, was daran verkehrt sein soll,
schließlich sind inzwischen auch die anderen Distributoren auf die
3er-Serie migriert, und von allein geht's nun mal nicht.
Achim
Gerd Knorr
> > i.e. $programmierer baut absichtlich illegale C oder C++ Konstrukte
> > ein, die mit 2.95 zufällig funkionieren,
>
> Nicht unbedingt bloß zufällig. Leute benutzen gcc-Erweiterungen, die
> seit Äonen dokumentiert sind und irendwer beschließt, sie aus dem
> Compiler auszubauen => bumm.
Was meinst Du konkret?
Gerd
--
sigfault
Achim Linder
> Achim Linder <achim....@nikocity.de> writes:
> Das größte Problem bestand bei Redhats "2.96" allerdings darin, dass
> dessen C++-ABI zu nichts ausser sich selbst kompatibel war, weder zum
> gcc-3 noch zum 2.95.x.
Was aber bei den "offiziellen" 2.95.x, 3.0 und 3.1 Versionen und
IIRC auch denen davor auch nicht anders war.
> Das ist extrem ärgerlich, wenn die eine oder andere (dummerweise
> kommerzielle und nur in Binärform erhältliche) Software damit übersetzt
> wurde und man einige Verrenkungen machen muss, wenn man nicht genau
> diese RedHat einsetzt.
Es ist natürlich lästig, wenn man die 2.96er libs mitschleppen muß, oder
wenn man Ärger mit Plugins bekommt, andererseits muß man beim Übernehmen
von Binaries auf andere Distributionen eh immer mit Problemen rechnen.
Man sollte halt eine Distribution mit ausreichendem Paketsortiment
verwenden, und ggf. unwillige Binary-Anbieter stupfen.
> Die C++-ABI ist beim g++ in der letzten Zeit sowieso ein echtes
> Ärgernis gewesen.
Eben. :)
Achim
Martin Bock
> Andreas Kretschmer <krets...@kaufbach.delug.de> dixit:
[ ... ]
> > PS.: $Kollege bat mich heute, ihm bei Installation von Debian kurz zu
> > helfen. Nun ist er auch auf Stufe 2 (von hinten) auf der im anderen
> > Posting deklarierten Socha-Skala ;-)
> >
>
> Ich komm da garnicht vor. Ist das jetzt ein gutes oder ein schlechtes
> Zeichen?
Weil bei NetBSD ein ganz kleiner YaST namens 'sushi' heranwächst? ;-)
BTW: Ich spiele seit knapp zwei Wochen mit NetBSD 1.6.1 'rum und bin
- sagen wir 'mal - nicht abgeneigt.
Wegen OT: Fup2 me.
--
Martin (auch auf Stufe 2 von hinten)
/* God is dead!............Nietzsche */
www.martin-bock.de /* Nietzsche is dead!......God */
Key-ID: 0x93FA8A93 /* Nietzsche is God!.......The Dead */
Rainer Weikusat
Multiline-Strings in C-Quellen zB. Oder signatures in C++.
Gerd Knorr
Das mit den multiline strings war aber jetzt nicht wirklich
überraschend, die hat gcc schon seit einiger Zeit mit #warn deprecated
angekreidet ...
Gerd
--
sigfault
Thomas Skora
>> Was nicht heißen muß, das es nicht so gewollt war, also aus der Sicht
>> des Programmierers keinen Fehler darstellt.
>
> i.e. $programmierer baut absichtlich illegale C oder C++ Konstrukte
> ein, die mit 2.95 zufällig funkionieren, mit einem richtigen[tm]
> Compiler aber nicht? Das wäre aber eine äußerst eigenwillige Sicht...
GNU-C-Erweiterungen sei dank wirst du eine Menge C-Code nicht durch
andere Compiler bekommen.
Thomas
Thomas Skora
>>> - schließlich wurden ja alle 7er Versionen von RedHat damit
>>> übersetzt.
>>
>> Wer weiß, was die da rumgepatcht haben...
>
> Sie haben einen Haufen Pakete gepatcht, damit sie sich mit der 3er
> Serie übersetzen lassen. Ich wüßte nicht, was daran verkehrt sein soll,
> schließlich sind inzwischen auch die anderen Distributoren auf die
> 3er-Serie migriert, und von allein geht's nun mal nicht.
Klar muß irgendwann damit angefangen werden, aber das schien mir
ziemlich verfrüht.
Thomas
Juergen Ilse
Aus Sicht des Sprachstandards ist es i.d.R. "undefined" oder
"implementation defined", der Code funktionierte also genau
genommen eigentlich nur "rein zufaellig mit genau der verwendeten
gcc-Version" ... Statt nun neuere gcc-Versionen diesem Code anzu-
passen, ist es IMHO meistens erheblich sinnvoller, den Code dem
anzupassen, was der jeweilige Sprachstandard wirklich festlegt ...
Ansonsten treten frueher oder spaeter immer wieder Probleme auf,
wie damals in den 2.0.x Kerneln mit gcc-Versionen > 2.7.xx (der
gravierendste Unterschied war in /usr/src/linux/arch/i386/kernel/ioport.c
in der Funktion sys_iopl(), wo man die Funktion als "mit den Register-
Inhalten als Parameter aufgerufen" deklariert hat, dann an den Aufruf-
parametern herummanipulierte ohne den geaenderten Wert zu benutzen
und neuere gcc-Versionen dann den Variablenzugriff wegoptimierten,
weil die Ubergabeparameter mit dem verlassen der Funktion *eigentlich*
ohnehin ihre gueltigkeit verloren haetten (nur nicht in diesem Fall,
weil die aufrufende Assemblerfunktion den Kram naemlich wieder vom
Stack heruntergepult und in die Register verteilt hat ...).
Btw. ist die Methode in Kernel-Version 2.2.25 auch nicht wesentlich
schoener, aber zumindest ist die Chance geringer, dass ein cleverer
Optimizer disfunktionalen Code erzeugt ... Da die aufrufende Funktion
in Assembler geschrieben ist und die Funktion sys_iopl() ohehin
Architektur-abhaengig ist, waere es sinnvoller gewesen, diese
Funktion ebenfalls in Assembler zu implementieren, dann haette man
sich diese Probleme dauerhaft erspart ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglühen
läßt. Es ist Duft, den man fühlt. Es ist ein Bild, das man riecht.
Es ist Erfüllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Juergen Ilse
Achim Linder <achim....@nikocity.de> wrote:
> On Wed, 25 Jun 2003 13:07:08 +0200, Thomas Skora wrote:
>> Achim Linder <achim....@nikocity.de> writes:
>>> Ein gepatchter Vorläufer von gcc-3.0 (3.0 wurde erst im Juni 2001
>>> veröffentlicht), der aber bis auf die erste Version IMO auch nicht
>>> fehlerhafter als 2.95.2 war
>> 3.0 war noch ziemlich buggy, ich glaub nicht, daß es bei Vorläufern
>> davon noch besser war.
> Der 2.96 war nun mal brauchbarer als die ersten 3.0-Versionen.
Da bin ich mir ehrlich gesagt gar nicht so sicher, ausserdem: Welcher
"2.96"? Alles mit Versionsnummer "2.96" war ein "moving target", es
veraenderte sich schneller, als man mitschreiben konnte ...
>> Ich finds einfach nur ziemlich dreist, den Leuten irgendeine Vorversion
>> des 3.0er gcc's als 2.96 auszugeben, weils dem nichtwissenden User
>> suggeriert, daß dies eine Nachfolgerversion vom stabilen 2.95.3 ist.
> Den gcc-2.95.3 gab es erst ein halbes Jahr nach dem 2.96, der 2.95.2
> hatte beim Erscheinen von RH7 schon fast ein Jahr auf dem Buckel, und bei
> RedHat hatte man sich eben dafür entschieden, die Manpower ins Debuggen
> der 3er-Serie zu stecken, statt in den 2.95.x-Seitenast.
Es spricht nichts dagegen, Aufwand in das debuggen einer Beta-Version
des gcc zu stecken, aber es ist eine Zumutung, diese Beta-Versionen
Endkunden zuzumuten. So etwas gehoert *ausschliesslich* in die Haende
von Leuten, die sich dessen bewusst sind, eine Beta-Version zu fahren
und bei Problemen entsprechend reagieren (Probleme selbst beseitigen,
Bug-Reports an die Entwickler, ...).
> Man hätte ihn besser anders genannt, allerdings hätte das an der Kritik
> wohl nicht viel geändert.
Natuerlich nicht, denn eine inoffizielle Beta-Version gehoert nicht
in eine Software-Sammlung fuer Endanwender (auch, wenn solcherlei
Unfug anscheinend immer ueblicher wird).
Rainer Weikusat
> Thomas Skora <use...@skora.net> wrote:
>> Gerd Knorr <kra...@bytesex.org> writes:
>>>> Es trifft zu, daß es bei RedHat und Mandrake Probleme beim Compilieren
>>>> mit dem gcc-2.96 gab, in den Fällen, die ich mir näher angesehen habe,
>>>> handelte es sich aber durchweg um Fehler im Quellcode, nicht im Compiler.
>>> Und das ist in der Regel bei Programmen die jetzt mit gcc 3.2 / 3.3
>>> nicht mehr bauen auch so ...
>> Was nicht heißen muß, das es nicht so gewollt war, also aus der Sicht
>> des Programmierers keinen Fehler darstellt.
>
> Aus Sicht des Sprachstandards ist es i.d.R. "undefined" oder
> "implementation defined", der Code funktionierte also genau
> genommen eigentlich nur "rein zufaellig mit genau der verwendeten
> gcc-Version"
Computerprogramme verhalten sich nie zufällig.
> Ansonsten treten frueher oder spaeter immer wieder Probleme auf,
> wie damals in den 2.0.x Kerneln mit gcc-Versionen > 2.7.xx (der
> gravierendste Unterschied war in /usr/src/linux/arch/i386/kernel/ioport.c
> in der Funktion sys_iopl(), wo man die Funktion als "mit den Register-
> Inhalten als Parameter aufgerufen" deklariert hat, dann an den Aufruf-
> parametern herummanipulierte ohne den geaenderten Wert zu benutzen
> und neuere gcc-Versionen dann den Variablenzugriff wegoptimierten,
Es wäre unglaublich erhellend, mal eine einleuchtende Begründung für
solche Optimierungen zu lesen, die nicht 'ISO sagt wir dürfen das'
beeinhaltet, sondern nachvollziehbar macht, wofür es gut sein soll.
Optimizer im allgemeinen und der gcc-Optimizer im besonderen sind weit
davon entfernt, 'optimalen' Code zu erzeugen und als Werkzeuge zur
automatischen Fehlerkorrektur erst recht ungeeignet.
Achim Linder
> Achim Linder <achim....@nikocity.de> wrote:
>> On Wed, 25 Jun 2003 13:07:08 +0200, Thomas Skora wrote:
>>> 3.0 war noch ziemlich buggy, ich glaub nicht, daß es bei Vorläufern
>>> davon noch besser war.
>> Der 2.96 war nun mal brauchbarer als die ersten 3.0-Versionen.
>
> Da bin ich mir ehrlich gesagt gar nicht so sicher,
Hast Du RedHat oder Mandrake mal längere Zeit eingesetzt?
> ausserdem: Welcher "2.96"? Alles mit Versionsnummer "2.96" war ein
> "moving target", es veraenderte sich schneller, als man mitschreiben
> konnte ...
Die erste Version hab ich nie verwendet, als ich auf RedHat7 umgestiegen
bin, gab es schon ein verbessertes gcc-Paket. Mit gcc-2.96 hab ich unter
RedHat und Mandrake im Lauf der Jahre mit Sicherheit mehr als ein GB Code
erfolgreich übersetzt, was will man mehr?
> Es spricht nichts dagegen, Aufwand in das debuggen einer Beta-Version
> des gcc zu stecken, aber es ist eine Zumutung, diese Beta-Versionen
> Endkunden zuzumuten.
Mich interessiert, ob ein Paket funktioniert, und nicht das Etikett. Wenn
Du den gcc-2.96 für so ein großes Problem hältst, dann warne halt vor
RedHat 7.x. Ich glaube allerdings nicht, daß das heutzutage noch viele
Umsteiger interessiert.
Achim
Marc Haber
>Prinzipiell ACK, allerdings ist SuSE irgendwie geil darauf, immer das
>aktuellste und damit unreifste zu nehmen.
SuSEs Zielgruppe fordert dies.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29