64Bit Linux Distribution

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
Benutzeravatar
TechnoFan
Beiträge: 244
Registriert: 15.03.2004 13:13:12
Wohnort: Düren
Kontaktdaten:

64Bit Linux Distribution

Beitrag von TechnoFan » 21.08.2006 20:01:14

Hallo Leute
Ich bin auf der Suche nach einer 64 Bit Distribution, bei der man nciht auf die w32codecs und flash usw. verzichten muss.
Gibt es sowas überhaupt? Bei Debian geht das ja glaube ich noch nicht, aber SuSE gibt es doch schon lange als 64Bit Version, oder? Wobei ich kein SuSE Fan bin...

Danke schonmal.

CU David

Benutzeravatar
finupsen
Beiträge: 1327
Registriert: 21.04.2004 20:07:05
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Dortmund
Kontaktdaten:

Beitrag von finupsen » 21.08.2006 20:07:58

Niemand hat vor eine zentrale Datensammelbehörde aufzubauen. Es handelt sich vielmehr um dezentrale IT-Systeme die miteinander vernetzt werden.
... und Wasser ist naß.

Benutzeravatar
meandtheshell
Beiträge: 4054
Registriert: 14.01.2005 17:51:30

Beitrag von meandtheshell » 21.08.2006 21:07:11

Natürlich geht das mit DebianGNU/Linux. Und in der Regel ist DGL immer schneller als Suse bei neuen Innovationen.

Zu Deiner Frage:
Auf welcher Architektur willst du 64Bit nutzen?
AMD ist im Grunde eine x86_64 und der DGL Port heißt amd64.
http://www.debian.org/ports/

markus

Benutzeravatar
TechnoFan
Beiträge: 244
Registriert: 15.03.2004 13:13:12
Wohnort: Düren
Kontaktdaten:

Beitrag von TechnoFan » 21.08.2006 22:35:06

Hi
Also ich hatte eigentlich vor Debian zu nutzen, habe aber hier im Forum halt in der Suche nach 64Bit gesucht und herausgefunden, dass die w32codecs und flash usw. nicht funktionieren sollen.
Deswegen kam ich auf die Überlegung nach einer anderen Distri. Normal würde es mir NIEMALS in den Sinn kommen zu einer anderen zu wechseln ;-).
Bestehen diese Probleme immer noch oder ist die 64 Bit Version inzwischen Salonfähig?
Ich habe eine Athlon 64 Bit CPU, Single Core.

aptynux
Beiträge: 178
Registriert: 19.08.2006 00:33:38
Wohnort: Dresden
Kontaktdaten:

Beitrag von aptynux » 21.08.2006 22:40:36

TechnoFan hat geschrieben:Hi
Also ich hatte eigentlich vor Debian zu nutzen, habe aber hier im Forum halt in der Suche nach 64Bit gesucht und herausgefunden, dass die w32codecs und flash usw. nicht funktionieren sollen.
Deswegen kam ich auf die Überlegung nach einer anderen Distri. Normal würde es mir NIEMALS in den Sinn kommen zu einer anderen zu wechseln ;-).
Bestehen diese Probleme immer noch oder ist die 64 Bit Version inzwischen Salonfähig?
Ich habe eine Athlon 64 Bit CPU, Single Core.
Deine genannten Programme haben (soweit ich weiß) nichts mit den Distributionen zu tun. Deshalb wirst du auch mit anderen Distributionen nicht glücklicher. Nimm doch einfach ein 32Bit-Debian, da läuft alles und die verbrauchen nicht so viel Arbeisspeicher/Festpltenspeicher. Erst ab 4 GB Arbeitsspeicher macht 64-Bit Sinn, sonst nicht (Denn 32 Bit unterstützt nur bis zu 3 GB Arbeitsspiecher, aber so lang du nicht so viel hast ist 32 Bit BESSER).

Viele Grüße
aptynux
Zuletzt geändert von aptynux am 23.08.2006 01:15:43, insgesamt 1-mal geändert.

Benutzeravatar
meandtheshell
Beiträge: 4054
Registriert: 14.01.2005 17:51:30

Beitrag von meandtheshell » 21.08.2006 22:59:22

aptynux hat geschrieben:Nimm doch einfach ein 32Bit-Debian, da läuft alles und die verbrauchen nicht so viel Arbeisspeicher/Festpltenspeicher.
Kannst Du das erläutern?
Erst ab 4 GB Arbeitsspeicher macht 64-Bit Sinn, sonst nicht (Denn 32 Bit unterstützt nur bis zu 3 GB Arbeitsspiecher, aber so lang du nicht so viel hast ist 32 Bit BESSER).
Nein und Nein!
Du sprichst von einem kleinen Aspekt der den Unterschied zwischen einer 32 und einer 64Bit Architektur darstellt nämlich der Menge an _nativ_ addressierbaren RAM.
Ich kann auch auf 32Bit Systemen weit mehr als 2^32 Bit addressieren - mit entsprechenden paging Algorithmen ist das kein Problem. BTW - 2^32 ist nicht 3GB. Wo hast Du diesen Wert her?

Code: Alles auswählen

markusgattol@pc1:~/work/w_c$ python
Python 2.3.5 (#2, Jul 30 2006, 15:57:01)
[GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 2**32
4294967296L
>>>
markusgattol@pc1:~/work/w_c$
LANGE REDE KURZER SINN
Der 64Bit DebianGNU/Linux Port ist ausgezeichnet. Und wenn man Hardware hat die 64Bit fähig ist sollte man das auf jeden Fall nutzen. Mehr mehr über die Thematik lesen möchte kann sich in der Wikipedia glücklich lesen.

markus

Benutzeravatar
hupfdule
Beiträge: 1864
Registriert: 09.12.2002 15:04:37
Wohnort: Berlin
Kontaktdaten:

Beitrag von hupfdule » 22.08.2006 07:32:27

meandtheshell hat geschrieben: Der 64Bit DebianGNU/Linux Port ist ausgezeichnet. Und wenn man Hardware hat die 64Bit fähig ist sollte man das auf jeden Fall nutzen. Mehr mehr über die Thematik lesen möchte kann sich in der Wikipedia glücklich lesen.
Nicht unbedingt. Es gibt leider ausreichend Programme in Debian, die Bugs haben, die sie unter 64bit Systemen unbrauchbar machen (in der Regel segfaults). Auch die Benutzung eines chroot für 32bit Programme ist nicht sehr praktisch. Als Beispiel openoffice (was sicher das meist genutzte Programm unter Debian ist, das nicht für 64bit verfügbar ist). Um das sinnvoll nutzen zu können, muss man natürlich auch im chroot dann die ganzen Schriften installiert haben, eventuell noch weitere Pakete, die zwar auch unter 64bit laufen, jedoch von Programmen im 32bit chroot benötigt werden. Das führt natürlcih dazu, dass das chroot deutlich größer wird, als man eigentlich möchte.

Wie es bei einem 64bit Server aussieht, weiß ich nicht. Für ein Desktopsystem hat man mit 64bit jedoch noch recht viele Probleme.

Benutzeravatar
Joghurt
Beiträge: 5244
Registriert: 30.01.2003 15:27:31
Wohnort: Hamburg
Kontaktdaten:

Beitrag von Joghurt » 22.08.2006 10:48:46

TechnoFan hat geschrieben:Also ich hatte eigentlich vor Debian zu nutzen, habe aber hier im Forum halt in der Suche nach 64Bit gesucht und herausgefunden, dass die w32codecs und flash usw. nicht funktionieren sollen.
Sowohl Flash als auch die w32codecs sind binäry-only Pakete, und im Falle von w32codecs auch noch eigentlich Windows-Binaries. Diese sind natürlich nicht unter einem 64bit-Modus lauffähig.

Benutzeravatar
finupsen
Beiträge: 1327
Registriert: 21.04.2004 20:07:05
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Dortmund
Kontaktdaten:

Beitrag von finupsen » 22.08.2006 12:29:29

Openoffice würde ich auch nicht in einem chroot installieren wollen
http://people.debian.org/~rene/openoffi ... 0.3/amd64/

@hupfdule
> Es gibt leider ausreichend Programme in Debian, die Bugs haben, die sie
> unter 64bit Systemen unbrauchbar machen (in der Regel segfaults).

kann ich nicht nachvollziehen , sorry. Hast du zu dieser aussage quellen ?

> Das führt natürlcih dazu, dass das chroot deutlich größer wird, als man
> eigentlich möchte.

kann ich auch nicht nachvollziehen. Wo ist die grenze "dessen was man
möchte" ? In zeiten wo einem eine 80GB-platte nachgeschmissen wird
spielt das für mich keine rolle mehr.
Niemand hat vor eine zentrale Datensammelbehörde aufzubauen. Es handelt sich vielmehr um dezentrale IT-Systeme die miteinander vernetzt werden.
... und Wasser ist naß.

Benutzeravatar
hupfdule
Beiträge: 1864
Registriert: 09.12.2002 15:04:37
Wohnort: Berlin
Kontaktdaten:

Beitrag von hupfdule » 22.08.2006 18:20:46

finupsen hat geschrieben:Openoffice würde ich auch nicht in einem chroot installieren wollen
http://people.debian.org/~rene/openoffi ... 0.3/amd64/
Das heißt, es gibt openoffice für 64bit? Gibt es einen Grund, dass das nicht in main enthalten ist?
@hupfdule
> Es gibt leider ausreichend Programme in Debian, die Bugs haben, die sie
> unter 64bit Systemen unbrauchbar machen (in der Regel segfaults).

kann ich nicht nachvollziehen , sorry. Hast du zu dieser aussage quellen ?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313240
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313234
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338913

Wobei zwei davon wohl im letzten Monat behoben wurden. Jedoch waren das nur Bugs, von denen ich selbst betroffen war. Daher wird es noch einige mehr geben.

> Das führt natürlcih dazu, dass das chroot deutlich größer wird, als man
> eigentlich möchte.

kann ich auch nicht nachvollziehen. Wo ist die grenze "dessen was man
möchte" ? In zeiten wo einem eine 80GB-platte nachgeschmissen wird
spielt das für mich keine rolle mehr.
"was man möchte" bezieht sich auf die Pakete, die nicht in 64bit verfügbar sind und daher in der 32bit Version benötigt werden.

Benutzeravatar
finupsen
Beiträge: 1327
Registriert: 21.04.2004 20:07:05
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Dortmund
Kontaktdaten:

Beitrag von finupsen » 22.08.2006 18:39:23

Ok... ist ein argument, überzeugt aber nicht.
Die bugs beziehen sich nicht auf mainstream-software.
Bei mir segfault nichts, obwohl ich doch recht viel software benutze (oder nur ausprobiere). Von daher ....

>>> Das führt natürlcih dazu, dass das chroot deutlich größer wird, als man
>>> eigentlich möchte.

>> kann ich auch nicht nachvollziehen. Wo ist die grenze "dessen was man
>> möchte" ? In zeiten wo einem eine 80GB-platte nachgeschmissen wird
>> spielt das für mich keine rolle mehr.

> "was man möchte" bezieht sich auf die Pakete, die nicht in 64bit verfügbar
> sind und daher in der 32bit Version benötigt werden.

ach da liegt die grenze ... ;)
Selbst wenn man fehlende 64bit-pakete zu 100% durch 32Bittige ersetzt,
reicht immer noch eine 80er platte.

Naja, egal. Ich hoffe es ensteht nicht der falsche eindruck, amd64 sei nicht
tauglich , da alles segfault. deb-amd64 läuft mittlerweile wunderprächtig ;)
Niemand hat vor eine zentrale Datensammelbehörde aufzubauen. Es handelt sich vielmehr um dezentrale IT-Systeme die miteinander vernetzt werden.
... und Wasser ist naß.

Benutzeravatar
hupfdule
Beiträge: 1864
Registriert: 09.12.2002 15:04:37
Wohnort: Berlin
Kontaktdaten:

Beitrag von hupfdule » 22.08.2006 18:43:17

finupsen hat geschrieben: Die bugs beziehen sich nicht auf mainstream-software.
Trotzdem sollte man das im Hinterkopf behalten, wenn man die Entscheidung fällen will. Eventuell ist man ja doch von solchen Bugs betroffen.Selbst wenn man fehlende 64bit-pakete zu 100% durch 32Bittige ersetzt,
reicht immer noch eine 80er platte.
[/quote]
Habe nie behauptet, dass die Platte überquellen würde. Trotzdem sehe ich keinen Grund zu unnötiger Platzverschwendung.
Naja, egal. Ich hoffe es ensteht nicht der falsche eindruck, amd64 sei nicht
tauglich , da alles segfault. deb-amd64 läuft mittlerweile wunderprächtig ;)
Hatte ich mit irgendeiner Bemerkung diesen Eindruck erwecken wollen? Oder zumindest diesen Effekt gehabt?

aptynux
Beiträge: 178
Registriert: 19.08.2006 00:33:38
Wohnort: Dresden
Kontaktdaten:

Beitrag von aptynux » 22.08.2006 19:15:34

meandtheshell hat geschrieben:
aptynux hat geschrieben:Nimm doch einfach ein 32Bit-Debian, da läuft alles und die verbrauchen nicht so viel Arbeisspeicher/Festpltenspeicher.
Kannst Du das erläutern?
Ja. Vergleich mal die Größe einer x86-Distribution und einer x86-64-Distribution. Und dann die Größe eines x86-Paketes und eines x86-64-Paketes. Somit muss bei x86-64 auch mehr in den RAM geladen werden. Den Rest findest du selber heraus. Noch ein Vergleich: Vista x86 hat als Mindestanforderung 1GB RAM und die x64-Version braucht mind. 2 GB RAM.
Erst ab 4 GB Arbeitsspeicher macht 64-Bit Sinn, sonst nicht (Denn 32 Bit unterstützt nur bis zu 3 GB Arbeitsspiecher, aber so lang du nicht so viel hast ist 32 Bit BESSER).
Nein und Nein!
Du sprichst von einem kleinen Aspekt der den Unterschied zwischen einer 32 und einer 64Bit Architektur darstellt nämlich der Menge an _nativ_ addressierbaren RAM.
Ich kann auch auf 32Bit Systemen weit mehr als 2^32 Bit addressieren - mit entsprechenden paging Algorithmen ist das kein Problem. BTW - 2^32 ist nicht 3GB. Wo hast Du diesen Wert her?

Code: Alles auswählen

markusgattol@pc1:~/work/w_c$ python
Python 2.3.5 (#2, Jul 30 2006, 15:57:01)
[GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 2**32
4294967296L
>>>
markusgattol@pc1:~/work/w_c$
1. OK, die Prozessorleistung ist besser, trotzdem wird mehr (Arbeits)speicher verbraucht (siehe oben).
2. Hast recht, da hab ich mich gerirrt. Die Grenze liegt bei 4 GB. Doch bei den normalen x86-Desktop-Mainboards ist das Maximale 3 GB, am besten sind aber 2GB, da man da Dual-Channel nutzen kann. Bei mehreren Sockeln mit mehren Prozessoren kann man auch mehr als 4 GB ansprechen.
LANGE REDE KURZER SINN
Der 64Bit DebianGNU/Linux Port ist ausgezeichnet. Und wenn man Hardware hat die 64Bit fähig ist sollte man das auf jeden Fall nutzen. Mehr mehr über die Thematik lesen möchte kann sich in der Wikipedia glücklich lesen.
Debian ist immer gut. :wink:
Zuletzt geändert von aptynux am 23.08.2006 01:18:34, insgesamt 1-mal geändert.

Benutzeravatar
meandtheshell
Beiträge: 4054
Registriert: 14.01.2005 17:51:30

Beitrag von meandtheshell » 22.08.2006 19:55:48

aptynux hat geschrieben: Ja. Vergleich mal die Größe einer x86-Distribution und einer x86-64-Distribution. Und dann die Größe eines x86-Paketes und eines x86-64-Paketes. Somit muss bei x86-64 auch mehr in den RAM geladen werden.
Und wo liegt das Problem? Du bekommst gar keine 64Bit Hardware zu kaufen die nicht übermotorisiert ist. Der "Speicherbedarf Einwand" ist somit kein in der Praxis relevanter Faktor. Das ein generic 64Bit Datentyp halt 64Bit braucht liegt in der Natur der Dinge.

Code: Alles auswählen

// test_types.c - This little neat programm prints the size of the internal
// representation of primitive C datatypes

// author: Markus Gattol
// date & time: Tue Mar  7 11:09:55 CET 2006
// Licence GPLv2 and later


char a_char = '\0';
int an_int = 0;
short a_short = 0;
long a_long = 0;
float a_float = 0.0f;
double a_double = 0.0;

main()
{
  printf("Size of char:    %d Byte(s)\n",sizeof(a_char));
  printf("Size of int:     %d Byte(s)\n",sizeof(an_int));
  printf("Size of short:   %d Byte(s)\n",sizeof(a_short));
  printf("Size of long:    %d Byte(s)\n",sizeof(a_long));
  printf("Size of float:   %d Byte(s)\n",sizeof(a_float));
  printf("Size of double:  %d Byte(s)\n",sizeof(a_double));
}
Noch ein Vergleich: Vista x86 hat als Mindestanforderung 1GB RAM und die x64-Version braucht mind. 2 GB RAM.
Ein Grund mehr es nicht zu verwenden.
1. OK, die Prozessorleistung ist besser, trotzdem wird mehr (Arbeits)speicher verbraucht (siehe oben).
Ich kenne keine Prozessorleistung und bei mir wird Arbeitsspeicher allokiert (ein Verbrauchsgegenstand sind z.B. Bremsscheiben bei meinem 996er Turbo (just kidding :) ))
Doch bei den normalen x86-Desktop-Mainboards ist das Maximale 3 GB, am besten sind aber 2GB, da man da Dual-Channel nutzen kann. Bei mehreren Sockeln mit mehren Prozessoren kann man auch mehr als 4 GB ansprechen.
?

markus

Benutzeravatar
rotwein
Beiträge: 619
Registriert: 03.06.2003 12:22:51
Wohnort: Altdorf (bei Nürtingen -> bei Stuttgart)

Beitrag von rotwein » 23.08.2006 08:14:29

aptynux hat geschrieben:Die Grenze liegt bei 4 GB. Doch bei den normalen x86-Desktop-Mainboards ist das Maximale 3 GB, am besten sind aber 2GB, da man da Dual-Channel nutzen kann. Bei mehreren Sockeln mit mehren Prozessoren kann man auch mehr als 4 GB ansprechen.
Vielleicht kann ich das mal aufdröseln; hier sind IMHO ein paar Dinge durcheinandergeraten:

- bei 32bit Systemen ist 4 GB die maximal direkt adressierbare Speichermenge (da herscht ja auch Einigkeit)

- Da das Betriebssystem aber auch Speicheradressen für sich selbst (bzw zum Ansprechen der Hardware) benötigt (irgendwas zwischen 300 - 700 MB, aber bitte nicht auf die Zahlen festlegen) können in der Praxis nicht die vollen 4 GB Arbeitsspeicher direkt adressiert werden; hier hat sich (vermutlich aus Bequemlichkeit) als sinnvoller Grenzwert 3 GB in Diskussionen/Artikeln eingebürgert.

- Der Ausbau von max. 2 GB auf den Systemen traf nur zu, als es nur max 500 MB DDR Module gab, mit DDR ist mittlerweile auch 4 GB möglich (Mainboard hat 4 Slots, DDR Module sind mit max 1 GB verfügbar). Bei DDR2 gibt es diese Grenze so nicht mehr, hier geht mehr (hängt halt immer von der Verfügbarkeit der Module ab).

Ich glaube, so hat das aptynux gemeint; kann mich aber auch irren..

Gruß rotwein
...der weiß, dass es hier eigentlich um GiB (kürzelt man das jetzt so ab, konnte mich damit noch nie anfreunden :? ) handelt, da Basis 2 und nicht 10....
If the solution is microsoft I want my problem back

Antworten