Performance-Vergleich: Slackware-Linux vs. FreeBSD

[hmikux]

hallo leute,

ich bin seit ca.2jahren slackware-linux benutzer und überlege nun ernsthaft auf freebsd umzusteigen. werde freebsd mit dem nächsten stable-release auf meine hd installieren und testen.

nun frage ich mich jedoch, wie es wohl mit der performance des systems unter freebsd ausschaut? wie sind eure erfahrungen?

folgende hardware besitze ich: CPU: AMD K7 1600+XP / RAM: 512MB DDR-RAM

ich lege besonderen wert auf ein schlankes system, habe deshalb slackware-linux als distri installiert und nachträglich jedemenge pakete kompiliert. als windowmanager nutze ich fluxbox mit rox zur darstellung von icons auf dem desktop. mail-client: sylpheed, und arbeite häufig mit der konsole (aterm)... also alles recht schlank und flott.
mein system benötigt ca. 1min und ein paar sekunden bis es voll funktionsfähig ist!

kann man eine aussage treffen, das mein system mit freebsd schneller/flüssiger läuft, flotter hochfährt oder größere appliaktionen wie z.B. openoffice, mozilla schneller ausgeführt/aufgerufen werden.

Gruss hmikux aus hessen

 

[xqq]

am besten du installierst FreeBSD und überzeugst dich selbst?

 

[hmikux]

ja ich weiss, diese antwort habe ich auch schon fast erwartet! jedoch würde ich mich vielleicht doch, auf die ein oder andere antwort freuen, die auf meine frage etwas detaillierter eingeht.

Gruss hmikux

 

[nihonto]

Ganz subjektiv: Habe hier Debian Sid und FreeBSD 5.2.1 parallel laufen. Kann keine Performance-Unterschiede ausmachen. Laufen beide ziemlich flott und rund. Könnte mir höchstens vorstellen, dass es bei spezifischen Anwendungen Unterschiede gibt. Das Einzige was mir so ad hoc einfällt, ist, dass Sid ein bisschen schneller bootet. Aber das liegt an einer etwa 30-sekündigen Gedenkpause, die FreeBSD bei mir aus unerfindlichen Gründen macht. Kann man aber mit leben.

 

[d4mi4n]

also ich hab noch nie slackware benutzt, aber wenn ich deinen rechner anschau und dann meinen dann kann ich sagen das sollte schon flott sein wenn dus draufklatschst, aber probieren geht über studieren

 

[thor]

Du bist Heimanwender. Das sieht man an deiner Hardware. Nimm das System, mit dem du am besten zurecht kommst und was du ausnutzen kannst nach deinen Möglichkeiten. Ich brauch auch keinen Porsche um zum ienkaufen zu fahren.

Thorsten

 

[Ice]

Wenn es Dir darum geht, die Performance zu verbessern, dann würde ich sagen:
"LASS ES SEIN!!!"

Ich kann mir nicht vorstellen, dass Du mit FreeBSD Performance-Gewinne in dem Bereich, den Du angesprochen hast, erreichen wirst.
Ein System, das so glatt läuft, wie Du es beschrieben hast, solltest Du nicht zerstören.

Was anderes ist es allerdings, wenn Du FreeBSD unbedingt haben willst....

Gruß,

Ice

 

[MrFixit]

Das booten wird unter FreeBSD wohl etwas laenger dauern. Es sein denn, rcNG wird endlich parallelisiert ...

 

[minuseins]

kann man eine aussage treffen, das mein system mit freebsd schneller/flüssiger läuft, flotter hochfährt oder größere appliaktionen wie z.B. openoffice, mozilla schneller ausgeführt/aufgerufen werden.

^
NEIN!
---
Wenn du so ein System wünscht, solltest du dir evtl. Yopi ansehen oder dir mit Gentoo und gcc+O3 dein System kaputt optimieren. (Yopi startet nicht wirklich schneller aber der KDE-Start ist schon beeindruckend.)

Versteh mich nicht falsch. Ich will dir nicht von FreeBSD abraten aber mich nerven ein bisschen diese Pauschalaussagen oder -fragen: x ist schneller als y.

Es ist ziemlich unwahrscheinlich, dass FreeBSD von Haus aus schneller ist als dein handoptimiertes System jetzt. Bis zur Kernelversion 2.6.x hatte der FreeBSD 4.x Kernel immer den Vorteil auch bei hoher Last besser ansprechbar zu sein.
FreeBSD ist performant und bei den üblichen Desktopanwendungen, Office, Browser, E-Mail sitzt die langsamste Komponente zwischen Stuhl und Tastatur.

Schnelleres Booten läßt sich erreichen, in dem man den Startprozess parallelisiert, die Prozessreihenfolge ändert, bestimmte Komponenten austauscht (Software und Hardware) oder, im Extremfall das BIOS tauscht. Sowohl meine Debianbox (Sarge), wie auch meine FreeBSD-Box (Current) brauchen etwa 20-25 Sekunden bis zum Login nach drücken des Powerknopfes. Dann weitere ein bis zwei Sekunden bis zum Desktop.

Einen Königsweg zur Optimierung eines Systemes gibt es nicht, da immer die Anwendung die Vorgehensweise entscheidet.

da minus

 

[Perdurabo]

Wenn du so ein System wünscht, solltest du dir evtl. Yopi ansehen oder dir mit Gentoo und gcc+O3 dein System kaputt optimieren. (Yopi startet nicht wirklich schneller aber der KDE-Start ist schon beeindruckend.)

Was haben Compileroptionen mit Gentoo, Yopi oder Distribution XY zu tun?

Bevor Du weiter irgendwelchen Unsinn verbreitest, diese Optionen kann ich genauso bei FreeBSD in der /etc/make.conf eintragen. Oder bei System XY beim compilieren mitgeben.

 

[asg]

@Perdurabo
<Zitat>
Es ist ziemlich unwahrscheinlich, dass FreeBSD von Haus aus schneller ist als dein handoptimiertes System jetzt.
</Zitat>

Das hat er doch schon relativiert.

 

[chewy]

Meine Erfahrung war mit FreeBSD eigentlich sehr positiv. Hab vor FreeBSD Gentoo benutzt, Stage 1, also komplettes System für meinen Rechner optimiert und der Performance Unterschied war doch sehr deutlich. Slackware hab ich nie benutzt.

 

[Perdurabo]

nun frage ich mich jedoch, wie es wohl mit der performance des systems unter freebsd ausschaut? wie sind eure erfahrungen?

Irgendwie finde ich Deinen Ansatz schon mal für falsch. Die Frage ist doch was will ich miit der Kiste erreichen. Ist es ein Desktopsystem, dann stellt sich eher die Frage, kann FreeBSD was Linux kann. Oder ist es ein Server der unter Last arbeiten muss.

folgende hardware besitze ich: CPU: AMD K7 1600+XP / RAM: 512MB DDR-RAM

Die Hardware sieht doch ganz normal aus. Zeigt mir aber auch, das Deine Kentnisse von Performance nicht ausreichend sind. Das sind Angaben wie aus der Waschmittelwerbung. Wichtig ist wie gut ist das Mainboard, Grafikkarte, welche Festplatten und I/O Leistung, vielleicht sogar SCSI, einen oder mehrere Speicherriegel und und und.

Man muss immer die Komponenten einbeziehen, die zur Gesamtperformance einen Einfluss haben können.

Natürlich geht auch die Entwicklung bei unixoiden Betriebssystemen weiter und man kann aus einer alten Mühle keinen Ferrari machen. Sollte wohl klar sein.

ich lege besonderen wert auf ein schlankes system, habe deshalb slackware-linux als distri installiert und nachträglich jedemenge pakete kompiliert.

Hört sich auch nach Waschmittelwerbung an, man kann jedes System schlank bauen, egal ob eine Linuxdistribution oder ein BSD. Auch eine Suse lässt sich wenn man sich damit beschäftigt sehr schlank einrichten. Gut es gibt Distributionen oder eben wie die BSD, die das von Anfang an, dem User etwas vereinfachen.

Viel interessanter, statt die Frage ob ich nun mit Compilereinstellung X oder Y noch den letzten Rest Performancerauschen hinkriege, ist wie bereits oben erwähnt die Gesamtperformance die stimmig sein muss und welchen Zeitaufwand betreibe ich als Anwender zur Pflege des Systems. Da ist wohl FreeBSD von den BSD das am pflegeleichteste genauso wie es Debian und Gentoo in der Linuxwelt ist.

mein system benötigt ca. 1min und ein paar sekunden bis es voll funktionsfähig ist!

Siehe oben was wichtig ist für Performance, deine Logik ist Rauschen.

 

[minuseins]

Was haben Compileroptionen mit Gentoo, Yopi oder Distribution XY zu tun?

Bevor Du weiter irgendwelchen Unsinn verbreitest, diese Optionen kann ich genauso bei FreeBSD in der /etc/make.conf eintragen. Oder bei System XY beim compilieren mitgeben.

Zur Erklärung des "Unsinns". Die gcc +O3 Option ist im Zusammenhang mit Gentoo zu sehen. Gentoo ließ sich lange Zeit nicht mit vorkompilierten Pakten installieren und auch heute nicht wirklich vernünftig betreiben. Sprich man kommt bei Gentoo zwangsläufig früher mit den gcc Parametern in Berührung als z.B. bei Yopi oder FreeBSD. Im Grunde bei der Installation.

Was ich generell von dieser Performancehast halte, sollte eigentlich im Posting rausgekommen sein, ein wenig Empathie vorrausgesetzt. Dadurch erklärt sich das Wörtchen "kaputt" hinter der O3 Option.

Das dies für alle Systeme gilt, habe nicht explizit erwähnt, da ich die Trennlinie gezogen habe zwischen "Machbar" und Teil des Konzepts.

Im übrigen hätte die Frage: "Wie meinst du das?" + deiner Erklärung ausgereicht um dir das zu erklären.

i²

 

[OM_A]

....
Hört sich auch nach Waschmittelwerbung an, man kann jedes System schlank bauen, egal ob eine Linuxdistribution oder ein BSD. Auch eine Suse lässt sich wenn man sich damit beschäftigt sehr schlank einrichten. Gut es gibt Distributionen oder eben wie die BSD, die das von Anfang an, dem User etwas vereinfachen.

Schlank würde ich so auslegen: Weglassen oder Entfernen nicht gewünschter Komponenten;
z.B. die GNU Compiler Collection (gcc) nicht zu installieren ist unter FreeBSD im Gegensatz zu den meisten Linux-Distribution und Net- oder OpenBSD nicht möglich. Unter Debian GNU/Linux kann man nach der Installation die nicht gewünschten Komponenten entfernen, weil alle Bestandteile die bei FreeBSD zur "world" gehören in der Paketdatenbank eingetragen sind. Will mann ein notwendiges Paket entfernen gibt es eine Warnung. dito SuSE.

....
... deine Logik ist Rauschen.

Was für Rauschen? weißes-, Funkel-, Quantisierungs- und,und Rauschen.
Man sollte keine technischen Begriffe für menschliche Eigenschaften/Tätigkeiten benutzen.

 

[chewy]

Korrigiere mich, aber unter Debian kannste wohl auch kaum den gcc weglassen. Oder kompilierst du deinen Kernel ohne compiler?

 

[OM_A]

Korrigiere mich, aber unter Debian kannste wohl auch kaum den gcc weglassen. Oder kompilierst du deinen Kernel ohne compiler?

Aber selbstverständlich kann man den weglassen. Nach dem reboot vor der abschließenden Konfiguration kann man mit dselect auch gcc abwählen. Auf Firewalls haben Compiler nichts zu suchen. Der Kernel wird auf einem anderen Rechner mit kpkg erstellt.
Und nicht nur auf Firewalls sollte man den Compiler weglassen. Wenn ich mich recht erinnere gab es Anfang 2001 eine Schwachstelle im BIND. Wer nicht schnell genug beim Aktualisieren war und noch dazu gcc installiert hatte, Pech gehabt. Ohne gcc war das script teilweise wirkungslos, aber eine Hintertür hatte man trotzdem untergewuchtet bekommen.

 

[Perdurabo]

Zur Erklärung des "Unsinns". Die gcc +O3 Option ist im Zusammenhang mit Gentoo zu sehen. Gentoo ließ sich lange Zeit nicht mit vorkompilierten Pakten installieren und auch heute nicht wirklich vernünftig betreiben. Sprich man kommt bei Gentoo zwangsläufig früher mit den gcc Parametern in Berührung als z.B. bei Yopi oder FreeBSD. Im Grunde bei der Installation.

Ich hab Dich schon richtig verstanden. Oops mein System ist ja Gentoo
Also mal kurz zur Klarstellung. Gentoo hat die gleiche Intention wie die BSD das nämlich Software nicht vorkompiliert installiert werden soll, sondern direkt über die Quellen compiliert wird. Spätestens nach der Installation komme ich auch unter FreeBSD mit der make.conf in Berührung und stell meine Compilierflags ein.
Müssen muss ich es nicht, genauso wie auch Gentoo eine Grundeinstellung in Ihrer make.conf hat. Übrigens betreibe ich seit 2 Jahren ein Gentoosystem vernünftig.

Was ich generell von dieser Performancehast halte, sollte eigentlich im Posting rausgekommen sein, ein wenig Empathie vorrausgesetzt. Dadurch erklärt sich das Wörtchen "kaputt" hinter der O3 Option.

Einen Sinn in der Ausnutzung der letzten Performancesteigernden Compilerflags sehe ich auch nicht. Wie gesagt die gleichen schwachsinnigen Flags kann ich auch unter FreeBSD einstellen. Man sollte mit seinen Assoziationen etwas vorsichtiger sein.

 

[Perdurabo]

Aber selbstverständlich kann man den weglassen. Nach dem reboot vor der abschließenden Konfiguration kann man mit dselect auch gcc abwählen. Auf Firewalls haben Compiler nichts zu suchen. Der Kernel wird auf einem anderen Rechner mit kpkg erstellt.

Na dann darf man ja gar kein OpenBSD oder *BSD als Firewallrechner betreiben. Hier wird aber auch wieder ein Quatsch runtergeleiert. Selbst bei einem Einbruchsversuch kann der Angreifer den gcc und make und... nachinstallieren und schwupp ist alles wieder drauf.

 

[OM_A]

Na dann darf man ja gar kein OpenBSD oder *BSD als Firewallrechner betreiben. Hier wird aber auch wieder ein Quatsch runtergeleiert. Selbst bei einem Einbruchsversuch kann der Angreifer den gcc und make und... nachinstallieren und schwupp ist alles wieder drauf.

Lies bitte z.B. "Building Firewalls with OpenBSD and PF" von Jacek Artymiak, oder beschäftige Dich mit der "m0n0"-Firewall oder dem Script flashdist für OpenBSD.

 

[minuseins]

Korrigiere mich, aber unter Debian kannste wohl auch kaum den gcc weglassen. Oder kompilierst du deinen Kernel ohne compiler?

Zum compilieren des Kernels brauchst du natürlich den gcc aber das ist definitiv keine Debian Eigenart.

Allerdings, für mich ist auch nicht wirklich vorstellbar, es gibt viele Debiannutzer, die die Standardkernel verwenden. (Sarge) Einfach mal in www.debianforum.de reinsehen. Da sind einige die den Standardkernel verwenden.

Da inzwischen fast alle Treiber als Module eingebunden sind, läßt sich sowas auch realisieren. "discover" tut sein übriges. Hardwaretechnisch gäbe es bei mir privat z.B. keinen Grund den Standardkernel von Debian nicht zu verwenden.

Aus Sicht eines reines Anwenders gehört der gcc auch nicht zum Konzept von Debian. Das installiert binäre Pakete und auch die Aktualisierungen sind Binär. Binäre Aktualisierungen kennt FreeBSD erst ab 5.3, Gentoo gar nicht.

Ich will mich auch nicht wirklich streiten, welches Konzept jetzt das bessere ist oder das man binäre Updates auch anderweitig realisieren kann.

 

[chewy]

Ich hab ja auch nicht behauptet, dass es eine Eigenart von Debian ist, das man den Kernel kompiliert.
Aber recht hat er, dass man ja den Kernel auch wo anders kompilieren kann.
Und das leute nen standard kernel benutzen...... Wems spass macht. Zu meiner Debian Zeit hab ich damit noch nicht wirklich viel zum Laufen gebracht. Brenner USB und sound kriegte man da noch nicht mit ans laufen. Aber Zeiten ändern sich. VOr allem wenn ich an den 2.6 er denke. Ein Grundnicht wieder zu Linux zu wechseln für mich.....

 

[Perdurabo]

Lies bitte z.B. "Building Firewalls with OpenBSD and PF" von Jacek Artymiak, oder beschäftige Dich mit der "m0n0"-Firewall oder dem Script flashdist für OpenBSD.

So und was steht in Deinem schlauen Buch drin? Nicht nur das runterleiern von irgendwelchen Dingen ist gefragt. So mal auf die schnelle ein Thread aus der BSD-Newsgroup, die das Thema betrifft.

Frage: Auf einem Server vom Internet erreichbaren Server sollte doch eignetlich kein Compiler sein. Daher meine Frage: Wie kann man denn ein FreeBSD
installieren ohne den gcc bzw diesen hinterher entfernen?

Antwort:Wer sagt denn sowas?

Wahrscheinlich wieder so ein Pseudo-Sicherheits-Statement. Wenn dir jemand
die Kiste aufmacht, dann wird er auch damit Leben können, daß du ihm keinen
Compiler hinterlassen hast und schiebt dir die trojanisierten Binaries fertig
von einem anderen Rechner drauf.

Der kurze zum nachlesen: Thread

Auf die Frage, wer das denn behauptetet kam die Antwort:
Eric "Sendmail" A. in einer Empfehlung von 1987. Habe ich ausgedruckt in
einem Bilderrahmen haengen, um mich daran zu erinnern, dass Genialitaet auch
nicht vor Ausrutschern schuetzt.

 

[OM_A]

@Perdurabo
Wie lautet das Thema dieses Threads?

Von mir die letzte Reaktion auf Deine Beiträge.
>.. und schiebt dir die trojanisierten Binaries fertig
>von einem anderen Rechner drauf.
Wie das funktionieren soll, wenn die Firewall von einer schreibgeschützten CF oder einer CD-ROM startet und in einer RAM-Disk läuft, ist mir nicht klar.

 

[Perdurabo]

Wie das funktionieren soll, wenn die Firewall von einer schreibgeschützten CF oder einer CD-ROM startet und in einer RAM-Disk läuft, ist mir nicht klar.

Soso, in eine RAM-Disk kann man nichts installieren. Wenn das Klaus Knopper wüsste. Das sind ja ganz neue Erkenntnisse die sich hier offenbaren.