[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: KUbuntu als Alternative zu Debian



Moin,

Am Mittwoch, den 27.07.2005, 22:48 +0200 schrieb Michelle Konzack:
> Am 2005-07-27 21:44:57, schrieb Joerg Rossdeutscher:

> > Wenn ich mir die Software wieder selbst drehen muss, kann ich auch
> > gleich LinuxFromScratch verwenden.
> 
> Es geht um einzelne ausgewähle Pakete.  Dafür verwende ich
> eine Devel-Workststion mit "pbuilder". Das teil erledigt das
> Backporten für mich.

Das ist ja schön. Aber für die meisten wohl nicht brauchbar, eigene
Builder für die internen Server zu haben. In der Regel existiert ja
bloss einer davon.
Bei uns wäre es ohnehin unsinnig, da wir für ein halbes dutzend Server
verschiedene Architekturen einsetzen - x86, amd64, ppc und mipsel. Ich
tät' mich totbauen.

> Ich kenne jedenfals keine Firme mit über 50 Angestellten, in
> denen ein Sysadmin nicht mal selber kompiliert, backportet
> oder paketiert.

Weil du an Provider u.ä. Firmen denkst. 
Es gibt genug Firmen mit deutlich mehr als 50 Angestellten, die haben
bloß ein DSL-Modem, und jeder Angestellte holt seine Mails direkt mit
seinem Outlook vom Provider ab, ihr-Unternehmen-im-Netz mit
50-Postfächern-inklusive.

Wir haben eigene Server, weil wir Websites entwickeln und die kleineren
davon selbst hosten. Aber wozu braucht Hoch-und-Tiefbau-Müller eigene
Web/Mailserver - das lassen sie alles extern und gut ist.


> > Ich verwende für meine Server im Job keine Backports und keinen
> > Eigenbau, der Kram kommt entweder aus der Distri, oder ich wechsel die
> > Distri.
> 
> Naja, dann nimm die neuste Software mit den neuesten Bugs.  :-)

Aha. Aktuelle Software=böse. Komisch nur, dass die Exploits, von denen
ich so lese, entweder runterreichen bis in die Version von vor 3 Jahren,
oder oft sogar in der aktuellen Version bereits gefixt sind (Weil sie
während der Arbeit in diesem Bereich überhaupt erst entdeckt wurden).

Ich würde ja zustimmen bei irgendwelchen ans Tageslich gezerrten
Alpha-Release-Candidates. Aber einfach "aktuelle Versionen=schlecht"?
Ne, nicht nach meiner Erfahrung.

Natürlich muss man sich fragen, ob man das immer so alles braucht. Nun,
vieles sicher nicht - aber einiges schon.

> > 1.
> > wichtige Sache, aber letztlich will ich mein Apache/php/whatever nicht
> > davon abhängig machen, ob irgendwo auf der Welt EINE Person immer
> > aufpasst, wo sie hinläuft.
> 
> Hat man denn bei soooo wichtigen Sachen nur einen Sysadmin ?

Hä? Wieso Sysadmin? Das Thema war Backports. 
Meistens 1-Mensch-Projekte, und das ist mir zu unsicher. Dem läuft die
Freundin weg, und dann muss der erstmal zwei Wochen saufen statt
Exploits fixen. Oder er kriegt Mumps. Oder fällt in einen offenen Gulli.
Das ist nunmal so. Genau deswegen gibt es ja Organisationen wie Debian,
weil die einfach besser und zuverlässiger agieren als Heerscharen von
Einzelkämpfern.


> > 2.
> > Ich habe nicht die Zeit und nicht die Lust, den ganzen Tag
> > Security-Listen zu lesen, um möglicherweise zu erfahren, dass meine
> 
> Das benötigst Du nicht.
> Einfach auf <debian-security-annonce> einschreiben und dann
> wieder procmailfilter für die gewünschten Pakete einrichten.

Dann hast du debian-security. 
Hattest du nicht vorgeschlagen, man solle eigene Pakete bauen?

> > Eigenkompilat eine Sicherheitslücke übernommen hat - oder möglicherweise
> > sogar viel zu spät ("responsible disclosure").
> 
> Das haste aber auch bei ALLEN Distris.

Eben - die Betonung liegt auf *Distris*. Ich habe es bei allen Distris,
dass die Distributoren sich drum kümmern, und "jemand" es fixt. Nicht
ich. Deswegen baue auch nicht ich die Pakete.

Natürlich lese ich gezwungenermassen dies und das. Aber der liebste
Report ist mir eigentlich die Ausgabe von apt-get dist-upgrade -s:
Problem bekannt und gefixt.

> > Lässt sich bei DIR nicht auf SATA installieren.
> 
> Bei mehreren Kunden ebenfals.

Bei mir aber. Und mein Ubuntu-Server ist ebenfalls ein reines
SATA-System. Und zwar ohne Eingriff - es ging einfach.

> > Sowas passiert bei allen Distris hier oder da mal, auch bei Debian, auch
> > bei anderen, mal mit dieser oder jener Hardware.
> 
> Also bei Debian habe ich es in den lezten 6 Jahren und 4 Monaten
> nicht feststellen können.  Ich bin seit Linux 2.0.36 dabei.

Aha - und Woody ging auf Anhieb z.B. mit einem reinen SATA-System?

> > Das sagt übrigens nichts zu dem Thema "nicht SERVERtauglich". Unter
> > "nicht Servertauglich" verstehe ich doch eher etwas in der Art von "hat
> > lahme Sicherheits-updates" oder "kommt mit irgendwelchen
> 
> Komisch das meine Server so gut wie keine Sicherheitsupdates
> in den lezten 3 Jahren benötigt haben.  Vieleicht insgesamt
> 120 Pakete upgedated.

Das ist keine Antwort auf die Frage: Was denn nun in Ubuntu nicht
Servertauglich ist?

> > Alpha/Beta-Versionen, um mit den höchsten Seriennummern prahlen zu
> 
> ???  Die versionsnummern werden von den Upstreams vergeben...

Hä? Die Distribution entscheidet doch wohl selbst, welche Version sie
paketiert? Was haben denn die Upstreams damit zu tun, ob Die Distri eine
alte, eine aktuelle oder eione RC-Version mitbringt?

> > können". Oder "bringt nur grafische Konfigurationstools mit". Oder, oder
> 
> Hört sich nach Windows an.  :-P

Ich sagte "Konfiguration". Nicht: "Destruktion". :-)

> > Trotzdem würde ich gern mal wissen, wieso Debian "servertauglich" ist
> > und Ubuntu nicht. Ich verwende beides auf unseren Servern für ein
> 
> Weil die Programme in fast allen situationen Das neuseste sind
> was Du von Upstream bekommen kannst, sprich ungetestet und mit
> jeder menge Bugs.

FUD.
Bitte zahlen, Daten, Fakten.

> > 30köpfiges Unternehmen, und bisher ist der einzige wirkliche Unterschied
> > zwischen Debian und Ubuntu, den ich bisher sehe, dass Ubuntu
> > perspektivisch aktuelle Software verspricht. Das ist mir wichtig für
> 
> Und neue Bugs...

Wenn man Spam kriegt, weil der Spamfilter alt ist,
Würmer wegen veralteter Scanner,
Software nicht anwenden kann wegen alter Versionen von $Scriptsprache,

...dann sind das auch "Bugs". Nicht im technischen Sinne, aber im
praktischen. Der Kram tut nicht. 

Ich habe bisher keinen, repeat: Keinen Report mitgekriegt, dass
Sicherheitslücken derzeit exklusiv Ubuntu betreffen würden. I.d.R. sind
die Probleme Distributionsübergreifend, und gelegentlich einschränkend
"...wenn mit lib-soundso oder Feature-xyz kompiliert".

> > seinen Releases zu warten), für diverse Software auf unserem Webserver
> > (z.B. php5 für Typo3/FTB).
> 
> Habe ich auch, nur PHP5 hat jede menge Bugs...  Viel spaß damit.
> Ich habe den Mist am Hals, weil ein Kunde unbedings PHP aus dem
> CVS haben will.

Das tu ich mir auch nicht an. PHP5 liegt auf dem internen
Entwicklungsserver, und wenn eine Site PHP5 braucht, kann der Kunde
damit zu einem Content-Provider gehen, soll der sich damit rumschlagen.
Auf dem externen Server verwenden wir PHP4.
Ich gehe aber fest davon aus, dass das maximal noch 12 Monate
durchzuhalten ist. Dann werden wir wohl, da Sarge nur PHP4 liefert und
wir wie gesagt weder Backports noch Eigenbau akzeptieren, die Distri
wechseln. Mal sehen, wohin.

> 
> > Ich bin ja gerne offen für Argumente - wie gesagt, Ubuntu läuft erst
> > testweise auf einem einzige Gerät, und wenn mir jemand sagen kann, was
> > Ubutu schlechter macht, dann habe ich da ein offenes Ohr für. 
> 
> Für nen Server zu aufgeblasen...

FUD.
WAS ist zuviel, WAS gehört da nicht rein?

Am Installationsprompt "install-server" (odr sowas ähnliches) eingeben,
und du hast eine Minimal-Installation. Wenn dir das immer noch zuviel
ist, kannst du wie bei Debian mit anderen Tools arbeiten (debootstrap).


> > Bisher kam allerdings nichts anderes als "Die haben einen schöneren
> > Desktop, daher /kann/ Ubuntu ja als Server nix taugen" - das ist mir zu
> 
> Habe ich nicht gesagt...
> Aber KDE und GNOME sind einfach häßlich.

Das Ubuntu-Gnome ist m.E. die einzige Linux-Oberfläche, die gut
aussieht. Alle anderen, von allen Distris, sieht entweder kindisch aus
(Und noch 'nen Wirbel, und gelb auf rot, und halb durchsichtig) oder wie
ein Ziegelstein im Pappkarton (twm).


> > dünne. Ob die eine Alpha-Crash-Version von KDE oder Gnome drin haben,
> > ist mir völlig Latte - das habe ich sowieso nicht auf dem Server. Die
> > Serverdienste, die ich bisher gesehen habe, sind stabil und aktuell. 
> 
> Kann ich von apache2 und php5 nicht behaupten.

Kein Ärger bisher.

> > Sarge wird jetzt schon zum Problem, weil von mir verwendete Software
> > langsam nach php5 schreit, und wie lange Tools wie ImageMagick noch mit
> > den xlibs von XFree statt Xorg glücklich sind, wird man ja sehen...
> 
> Xorg läuft bei mir auch nicht... Warum sollte ich sowas installieren?
> Dann hat es eine Latte von Bugs die länger ist das das BTS on Debian.

Ich habe ja auch "xlibs" geschrieben, nicht "Komplettes Xorg/XFree". Die
xlibs sind eine Dependency von vielen bildverarbeitenden
Kommandozeilentools wie z.B. ImageMagick, oder auch von php-gd.


> > Das mag ja sein. Wenn Debian problemfrei wäre, gäbe es vermutlich diese
> > Liste nicht. So ist nunmal das Leben mit Computern: Man dreht irgendwo
> > dran, und plötzlich bricht irgendwas weg. Oder es lässt sich gar nicht
> > erst drehen. Oder.
> 
> ...blubber!

Aha.

> Hatte mich erst vor zwei stunden mit jemanden angelegt der der
> Meinung war PHP ist Schrot weil andauern irgendwelche exploits
> in seiner phpBB auftauche. Sein Server wurde mehrfach geownt. :-)
> 
> Nun sind die BUGs aber nicht in php sondern in der phpBB.

Einiges an php ist auch Schrott. Was php fehlt, ist

use warnings;
use strict;

damit wäre 90% der "Exploits" ein Riegel vorgeschoben. Ich verstehe
nicht, warum die das nicht machen.


> Ich kann auch python oder perl applikationen schreiben,
> die Buffer-Overflows und andere schweinereien erzeugen.

Nun, perl musst du schon sehr quälen, um das hinzukriegen, während php
dir da recht wenige Steine in den Weg legt.

Ich arbeite selbst gern in php, aber in einigen Dingen ist es einfach zu
lässig.


> > macht *manchmal* Ärger, weil Menschen Menschen sind und Fehler machen.
> > Dazu gehört m.E. Debian, aber auch Ubuntu. Beide machen einen guten Job.
> > Ubuntu scheint dabei inzwischen eher meine Bedürfnisse zu treffen, ohne
> > dass man nach "besser" oder "schlechter" gewichten müsste.
> 
> Mir sind zuviele Bugs drin.
> Ubuntu nimmt auch nur Debian/Unstable als Basis.

Unstable ist nicht getestet und abgestimmt - da pumpt halt jeder
Developer rein, wie er grad Zeit und Lust hat. Das ist das eigentlich
"Problem" mit Sid - nicht, dass ständig alles Broken wäre. Ubuntu
stabilisiert Sid.
Zum zweiten fehlen Sid die Security-fixes. Das liegt daran, dass es sie
halt nicht gibt - möglich wäre das, und Ubuntu tuts halt.

 
> > Sid ist ja auch nicht schlecht. Ich verwende es seit langem auf meinem
> > Desktop. Wenn nicht gerade so Phasen sind wie jetzt (Server migrieren
>   ^^^^^^^
> > seit einer Woche, Umstellung der C++-ABI, broken libaspell blockiert
> > etliche Pakete), dann ist Sid eine wunderbare Sache.
> 
> Auf nem Produktions-Server ?
> Wo kriegse da laufen Security-Updates ?

Kannst du mir bitte mal erklären, wieso du eigenhändig "Desktop"
unterstreichst und mich anschließend fragst, wie ich mich das auf einem
*Server* traue?

> Habe hier einen TestServer laufen der selber auf "HOLD" gegangen
> ist, weil es sich sonst selber killt.  Sprich wennich SID auf nem
> produktionssystem hätte, würde ich für die nächsten Wochen keine
> security-updates mehr bekommen...

Du bekommst auch sonst für Sid keine Security-Updates. Es gibt keine.

> > Sicherlich nichts für einen Server (security!). Aber meiner persönlichen
> > Meinung nach ist ein Sid an 355 Tagen im Jahr mehr "stable" als z.B. ein
> > Suse "fertig" in den Läden steht.
> 
> Gut, gillt für Fedora und Mandrake gleichermaßen.

Beides habe ich nie probiert, nachdem ich meinen Linux-Umstieg per Suse
hinter mich gebracht hatte. 
"Klick du nur drauf, ich denk' für dich" ist eine administrative
Sackgasse, deren verschiedene Ausgestaltungen ich nicht alle gesehen
haben muss.


Gruß,
Ratti

-- 
 -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux
 /\\ http://freshmeat.net/projects/fontlinge/
_\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: