Wieso Linux?

  • Ersteller think_different
  • Erstellt am
ratti schrieb:
Du weisst, das X11 etwas anderes ist als ein Desktop, als ein Windowmanager, als ein Widgetset, als ein Filemanager?
Su hast gesagt, dass Apple Dir ein Aussehen aufzwingt. Das stimmt wegen X11 aber gerade nicht.
 
sgmelin schrieb:
Du hast doch den Speicher als Argument angebracht. Mannomann. Mir wird das hier zu doof.

HÄ?

Ich schrieb:
------------
Ja, schneller auch, und mit einem Gig Speicher brauche ich keinen Swap, und die SATA-Platten reissen etliches raus.
Ich persönlich habe mich für den 64-Bitter entschieden, weil ich
- meine Rechner immer recht lange nutze und in vier Jahren die "richtige" Plattform haben möchte
- mich für Features wie die noexec-Flag begeistere, die einen erheblichen Sicherheitsgewinn darfstellt
- der Preisunterschied marginal ist und die technologie zukunftssicher
------------
...daß ich 1 Gig RAM habe, der Rechner nie swappt und daher der Prozessor voll ausgefahren werden kann. Alles andere kommt nicht von mir.

Jeder zusätzliche Speicher wäre also unnötig.

Gruß, Ratti
 
Das stimmt wegen X11 aber gerade nicht.

Doch. Zum Glück. Die X11 Applikationen haben -zumindest die Fensterrahmen- das Aussehen von Cocoa. Und auch die X11 typischen Gadgets wie Knöpfe, Buttons und so sind Cocoa-like.
Aber gerade das macht die usability des Mac aus. Es ist eben aus einem Guss. Klar, wenn man nur basteln will, dann ist Mac OS X nicht unbedingt das OS der Wahl.
 
ocj schrieb:
Su hast gesagt, dass Apple Dir ein Aussehen aufzwingt. Das stimmt wegen X11 aber gerade nicht.

Apple hat unter OS X etliche Personalisierungen rausgeschmissen, die unter OS 9 noch drin waren. Das geht jetzt entweder gar nicht mehr (Schwarz-Weiss-Theme) oder nur noch mit Hacks (Andere Systemschrift, z.B. die deutlich besser lesbare Verdana: Buttons werden teilweise unlesbar gekürzt etc...)

Da hilft mir X11 nicht weiter. Die X11-Konfigurationen und die des verwendeten Windowmanagers wirken sich nicht auf native Software aus.

Gruß, Ratti
 
ratti schrieb:
Da hilft mir X11 nicht weiter. Die X11-Konfigurationen und die des verwendeten Windowmanagers wirken sich nicht auf native Software aus.
Du meinst: "nicht auf native Aqua-Software". Auch X11 läuft nativ auf Mac OS X.
 
-Nuke- schrieb:
Ist ja auch OK. Aber in meinen Augen ist das reine Spielerei. Aber für mich gibt es entscheidende Nachteile bei "eurem" (;)) System.

1. Durch diese ganzen Layer geht eine Menge Performance drauf.
X11->GTK+->GNome
X11->QT->KDE
etc.

Das stimmt.
Inzwischen hat sich da aber auch sehr viel getan. Zum Beispiel ging bei X11 früher alles durch den Netzwerklayer für "localhost", heute wird für lokale Kommunikation IPC verwendet, schneller geht es nicht mehr.

Das ganze mußt du aber relativieren:
Auf einem aktuellen Rechner ist ein Gnome oder KDE auch nicht langsamer als ein Mac.
Auf einem langsamen Rechner hast du unter freier Software Alternativen: Zum Beispiel XFCE erfreut sich großer Beliebtheit (Und hat schon sehr lange einen "Dock", das freut den Appleuser :) )


Ich denke aber auch, daß man da nicht bloß in "Leistung pro Rechner" kalkulieren darf, sondern ruhig auch in "Leistung pro Geld". Für das Geld, für das ich mit einem Mac gut flüssig arbeiten kann, bekomme ich locker einen Rechner, mit dem ich auch unter Linux flüssig arbeiten kann.


-Nuke- schrieb:
Alles bedingt abhängige Teile, die aber eigenständige Entwicklungen sind. Selbst GNome/GTK-Programmierer merken selbst, das GNome mit Nautilus lahm ist. Kann ich auch bestätigen. GNome auf einem P4 2Ghz fühlt sich an wie Windows2k auf einem 200 Mhz PC. Das ist jetzt kein gelame, das ist Realität. Daran wird gearbeitet, aber es dauert noch etwas.
Das selbe steht für QT/KDE. Es ist zwar etwas schneller als GTK/GNome, aber weit entfernt von "schnell". Außer ich lade mir per Einstellung das halbe KDE in den RAM und verbrate 200MB für nix.

Na, also, jetzt würde ich doch mal vorschlagen, daß du mal deine DMA-Einstellungen mit hdparm prüfst :)

Ich kann keine signifikante Leistungsunterschiede zwischen meinem 1GHz-Mac und meinem AMD unter Linux feststellen.
Was auf dem Mac schneller läuft sind Desktop-Animationen wie Expose, da sie die Hardwarebeschleunigung der der GraKa nutzen, ich aus "sittlichem Empfinden" auf meiner Linux-Kiste aber nicht den proprietären NVIDIA-Treiber installiert habe, sondern den unbeschleunigten freien.

-Nuke- schrieb:
2. Kein einheitliches Look&Feel.
Ich habe zwar die Möglichkeit mir eine Oberfläche auszusuchen, aber wenn ein benötigtes Programm eine andere Oberfläche verlangt, dann passt diese nicht in das Gesamt-System. Merkst du ja sicher selbst, bei deinem GNome und K3B.
Man kann es zwar einheitlich zu-"Themen", die ganze Anwendung ist anders. z.B. die Button-Position, etc. pp.
Das stört MICH ungemein.

FullACK. Das stört mich auch gewaltig.

Aus diesem Grund setze ich nur Gnome-Software ein und kein KDE, dann entfällt das. Ärgerlich sind Eigenbrödler wie XMMS oder Mozilla, die muß man sich dann wirklich hin-themen.

Das einzige Ei im Nest in tatsächlich noch k3b - es würde mich aber wundern, wenn da für Gnome nicht ein Äquivalent gäbe - ich bin nur zu feige zum testen. Ich brenne DVDs, bin aber nicht bereit, die kostenlose aber unfreie Lizenz für dvdrecord zu akzeptieren. Unterhalb von k3b werkelt was anderes, mkisofs, und das ist eine Kommandozeilenapplikation, die völlig unabhängig von Gnome/KDE/... ist. Es muß also auch mit Gnome gehen - an der Kommandozeile sowieso, und es gibt bestimmt was grafisches dazu. Vieleicht sollte ich nautilus-burn mal angucken.

dvdrecord geht auf jeden Fall, dann geht es auch unter Gnome. Hundertpro. Das ist dann kostenlos, aber unfrei. Will ich nicht.

-Nuke- schrieb:
3. Zu starke Modularisierung
Damit eine KDE-Anwendung auch ohne kompletten KDE läuft benötigt man halt nur die KDE-Libs und QT. D.h. die Projekte sind in sich selbst noch mal geteilt. Ist ja auch OK.
Aber wenn ich jetzt z.B. ein gutes Brennprogramm will, komme ich ja um K3B nicht rum.
Mit GNome ohne KDE-Libs kann das als ISDN-User ein Horror werden. Zu einem 4MB-Brennprogramm kommen dann noch mal 30 MB QT und 50 MB KDE-Lib hinzu.
Somit bin ich auch wieder zu "einer" Oberfläche gezwungen, bzw. mehreren Oberfläche. Oder ich gehe einen Kompromiss ein und nehme ein GNome Brennprogramm und verzichte auf Features.

Na komm. Distributions-DVDs liegen inzwischen jeder pillepalle-Computerzeitschrift bei, du brauchst wirklich kein KDE aus dem Web ziehen. Mit Tools wie apt-mirror und apt-proxy kannst du dir lokale Mirrors anlegen und beziehst nur die Security-Updates aus dem Netz. Und die sind bedeutend kleiner als die von Apple.

Etwas guter Wille, bitte! :)))))

-Nuke- schrieb:
Zum rumspielen für ein verregnetes Wochenende OK. Aber zum Arbeiten, für mich nicht ideal. Ich habe gut 2 Jahre Linux als einziges System benutzt. Nach langem hin und her, war ich dann glücklich endlich meinen Mac zu haben um von den oberen Punkten weg zu kommen.

Das ist dein gutes Recht.

Mir fehlt eigentlich nur eins: Gute Ballerspiele. Aber eigentlich sollten die ganzen gesparten Lizenzkosten langsam mal 'ne Playstation ergebn... :)

-Nuke- schrieb:
Was der Prozessor mit dem RAM zu tun hat? Na alles! Die CPU muss diesen Adressieren. Bei 32bit kommt man gut bis 2GB, max. 4GB, aber dann gibt es Einschränkungen.
Ansonsten bringt ein 64bit-System für normale Arbeiten gar nix. Das ist nur was für´s Ego.

Stop. Die 2/4 GB gelten PRO PROZESS und sind hardwaremässig nicht veränderbar. Auch für x86 gibt es, z.B. von RedHat, einen 64GB-Patch, sodaß mehrere Instanzen eines Programms laufen können, jedes mit 4 Gigs. Aber wer braucht sowas?

Der eigentliche Vorteil eines amd64 liegt doch auf der Hand: Ich habe einen älteren Rechner gehabt und brauchte was neues. Und der Preisunterschied macht es sinnvoll, jetzt einen 64-Bitter zu kaufen, denn der soll ja wieder ein paar Jahre halten. Heute mag er eine "elitäre" Plattform sein, in drei Jahren ist das "Standard", und dann will ich nicht blöd dastehen mit meinem "ollen" x86.
Das Gerät ist ja abwärtskompatibel, und bis dahin ist es halt "nur" ein verdammt schneller x86. Und das neue Unreal kommt in zwei Versionen für Linux: 32 und 64 Bit. :)))

Natürlich war auch ein bisschen Spieltrieb dabei, aber die Entscheidung war in der Summe durchaus vernünftig.

Gruß, Ratti
 
ocj schrieb:
Du meinst: "nicht auf native Aqua-Software". Auch X11 läuft nativ auf Mac OS X.

Ja, das meinte ich. Sorry für die Ungenauigkeit.

Gruß, Ratti
 
sgmelin schrieb:
Drück doch mal ctrl-alt-apfel-8

:))) Nett.

Aber das ist nicht Schwarzweiss wie unter OS 9, da sind immer noch Verläufe und Schatten dran und so.

Das eigentliche Problem ist aber: Ich arbeite im DTP-Bereich. Nur, weil ich meinen Desktop in flach-Schwarzweiss sehen will, gilt das nicht für die Bilder, die ich gerade bearbeite.

Wieder eine Hoffnung tot. :)
 
ratti schrieb:
Das stimmt.
Inzwischen hat sich da aber auch sehr viel getan. Zum Beispiel ging bei X11 früher alles durch den Netzwerklayer für "localhost", heute wird für lokale Kommunikation IPC verwendet, schneller geht es nicht mehr.

Ja. Nur leider hängt die X11-Entwicklung etwas. Mal sehen was aus X.org wird.

ratti schrieb:
Das ganze mußt du aber relativieren:
Auf einem aktuellen Rechner ist ein Gnome oder KDE auch nicht langsamer als ein Mac.
Ich denke aber auch, daß man da nicht bloß in "Leistung pro Rechner" kalkulieren darf, sondern ruhig auch in "Leistung pro Geld". Für das Geld, für das ich mit einem Mac gut flüssig arbeiten kann, bekomme ich locker einen Rechner, mit dem ich auch unter Linux flüssig arbeiten kann.
Na, also, jetzt würde ich doch mal vorschlagen, daß du mal deine DMA-Einstellungen mit hdparm prüfst :) Ich kann keine signifikante Leistungsunterschiede zwischen meinem 1GHz-Mac und meinem AMD unter Linux feststellen.

Also nach meinen Erkenntnissen schon. Das öffnen/schließen der Programme, Dateibrowsen und allgemeines Fenster-Handling sind einfach langsamer als unterm Mac. Das mag sicher an der OpenGL-Oberfläche liegen, aber das ist ja egal.
DMA ist auf die maximalen Einstellungen eingestellt. Daran liegt es nicht.

Mal ein Beispiel.
Ich möchte eine Datei aus meinem persönlichen Ordner holen. Unter allen Systemen ist das ein einfacher Doppelklick/Einfacher Klick.

Unter OSX springt das Finder-Fenster SOFORT auf.

Unter GNome muss ich 2 Sekunden warten, bis es auf geht. Unter KDE mit Konqueror sind es 3 Sekunden.

Das lässt sich auf weitere Programme durchziehen. Z.B. FireFox, OpenOffice usw. starten unter OS X bei weitem schneller als unter Linux.

Jetzt mal alles auf meinem Mac getestet.

ratti schrieb:
Na komm. Distributions-DVDs liegen inzwischen jeder pillepalle-Computerzeitschrift bei, du brauchst wirklich kein KDE aus dem Web ziehen. Mit Tools wie apt-mirror und apt-proxy kannst du dir lokale Mirrors anlegen und beziehst nur die Security-Updates aus dem Netz. Und die sind bedeutend kleiner als die von Apple.

Dann darf ich mir also zig mal dieses Heft für ein paar Updates kaufen? Security-Updates sind unter Linux doch meist noch mal das gesamte Programm. Siehe Mozilla. Über 14 MB.
Oder auch KDE, etc. pp. da darf man sich dann 50MB besorgen. Andauernd dich die aktuellen Distributionen kaufen wird auf Dauer auch sehr teuer.


ratti schrieb:
Stop. Die 2/4 GB gelten PRO PROZESS und sind hardwaremässig nicht veränderbar. Auch für x86 gibt es, z.B. von RedHat, einen 64GB-Patch, sodaß mehrere Instanzen eines Programms laufen können, jedes mit 4 Gigs. Aber wer braucht sowas?

Die 64GB laufen aber nicht nativ (und ist auch unter Windows möglich, nur mal nebenbei). Das Ganze ist SEHR SEHR langsam. 4GB kann ein System nativ verwalten. Dabei sind 3,5GB, bzw. 3GB (je nach Kernel-Einstellung) für Programme verwendbar. 2GB kann dann ein Prozess bekommen.

ratti schrieb:
Natürlich war auch ein bisschen Spieltrieb dabei, aber die Entscheidung war in der Summe durchaus vernünftig.

Sicher. Der Athlon64 ist ein guter Prozessor. Nur die 64bit bringen nichts. Auch in naher Zukunft bleibt 64bit ne kleine Option. Solange Windows nicht durchweg 64bit ist, bleibt die PC-Masse bei 32bit. Also kann sich das noch Jahre hinziehen.
 
-Nuke- schrieb:
Ja. Nur leider hängt die X11-Entwicklung etwas. Mal sehen was aus X.org wird.

Ja, oder freedesktop. Es gibt Alternativen.

Meines Wissens haben Suse und RedHat ja schon umgestellt. Als Debianer sehe ich davon nicht viel, da demnächst, träräää, der große Sarge-Release ist und vorher garnix mehr gedreht wird - aber danach wird sich was tun.

-Nuke- schrieb:
Also nach meinen Erkenntnissen schon. Das öffnen/schließen der Programme, Dateibrowsen und allgemeines Fenster-Handling sind einfach langsamer als unterm Mac. Das mag sicher an der OpenGL-Oberfläche liegen, aber das ist ja egal.
DMA ist auf die maximalen Einstellungen eingestellt. Daran liegt es nicht.

Mal ein Beispiel.
Ich möchte eine Datei aus meinem persönlichen Ordner holen. Unter allen Systemen ist das ein einfacher Doppelklick/Einfacher Klick.

Unter OSX springt das Finder-Fenster SOFORT auf.

Unter GNome muss ich 2 Sekunden warten, bis es auf geht. Unter KDE mit Konqueror sind es 3 Sekunden.

Hmm... ich habe keine Uhr greifbar und habe einfach Sekundenzählen gemacht ("Einundzwanzig...."). Nach "Einu..." war das Fenster da. Es war nichts im Cache, denn ich nutze normalerweise gar keinen Nautilus, sondern das Terminal für Dateioperationen.

Wenn ich es jetzt nochmal probiere, ist das aufpoppen praktisch nicht messbar.

Geöffnet ist derzeit der Gnome-Desktop, drei Mozilla-Fenster und das Mail-Programm "Evolution", welches immerhin eine Mailbase von 3,4 Gigabyte zu verwalten hat.
460MB Ram sind in use, der Rest "free".

-Nuke- schrieb:
Das lässt sich auf weitere Programme durchziehen. Z.B. FireFox, OpenOffice usw. starten unter OS X bei weitem schneller als unter Linux.

Kann ich nicht bestätigen. Mozilla und FireFox - kein Unterschied. Beide starten natürlich langsamer als Safari, weil sie größer sind und mehr Features haben (Als Webentwickler bin ich begeisterter Anhänger des DOM-Inspectors und als Surfer werde ich nie mehr ohne "Adblock"-Plugin leben wollen http://adblock.mozdev.org )

OpenOffice können wir nicht vernünftig vergleichen, denn ich habe schon ein X11 am laufen, welches du erst noch starten musst. Trotzdem, zum Test... Mist .....Ich hatte ein Update aufgespielt und es danach nie gestartet. Jetzt gehen hier erst die großen Konvertierereien los, und er braucht über 10 Sekunden. Jetzt ist es natürlich im RAMcache, und wenn ich es nochmal starte, ist es unmessbar schnell offen. Der Wert ist natürlich nicht echt. OK, den Test müssen wir verschieben bis auf nach dem nächsten Neustart. Und da heisst es immer, Unix-System müssen nicht rebootet werden. :)

-Nuke- schrieb:
Dann darf ich mir also zig mal dieses Heft für ein paar Updates kaufen? Security-Updates sind unter Linux doch meist noch mal das gesamte Programm. Siehe Mozilla. Über 14 MB.
Oder auch KDE, etc. pp. da darf man sich dann 50MB besorgen. Andauernd dich die aktuellen Distributionen kaufen wird auf Dauer auch sehr teuer.

Wieso dauernd? Wenn du Updates machst, ist das sehr, sehr wenig. Wenn du natürlich neue Versionen haben willst, mußt du dir natürlich dicke Pakete ziehen. Verwechsle aber bitte nicht Updates und Upgrades! Die UPDATES sind zusammen schon deutlich kleiner als das, was Apple dir allein schon mit solchen Paketen wie 10.3.4Combo, Java oder Quicktime rüberschiebt. (Unter anderem schon deswegen, weil die eben auch nicht zwischen Upgrades und Updates unterscheiden und statt Bugfixes neue Versionen liefern).

Gegenbeispiel: Debian Stable enthält Mozilla 1.0. Der war aktuell, als die Distri vor 2,5 Jahren rauskam. Es werden nur Bugfixes rückportiert, du bekommst keine neuen Features. Das senkt natürlich die Menge der Fixes ganz erheblich (Weil Bugs meistens in den neuen Funktionen enthalten sind)
[Natürlich gibt es Quellen für aktuelle Versionen, aber das ist die von dir gewünschte "Spar-Option"]

-Nuke- schrieb:
Die 64GB laufen aber nicht nativ (und ist auch unter Windows möglich, nur mal nebenbei). Das Ganze ist SEHR SEHR langsam. 4GB kann ein System nativ verwalten. Dabei sind 3,5GB, bzw. 3GB (je nach Kernel-Einstellung) für Programme verwendbar. 2GB kann dann ein Prozess bekommen.

Ja, wie gesagt: Die 4 Gigs sind Hardwarelimitation für x86, man kann nur die Grenzen innerhalb dieser 4 Gigs verschieben (Ich glaube, code, data und stack zusammen...)

Aber klar: Niemand kann ernsthaft x86 als eine geniale Hardware bezeichnen. Das läuft zwar alles DEUTLICH besser als vor Jahren, als wir noch unsere Interrupts auf einem Zettel aufmalen mußten und Jumper umstecken, aber letztlich ist es eben doch ein erweiterte Erweiterung einer angeflanschten Extension einer...
Aber es läuft! Es weiss nur keiner mehr, wieso! :)

Das ist für mich übrigens ein Grund für Linux auf Macs: Die Hardware ist deutlich hochwertiger. Viele PPC-Debianer haben sich PowerBooks gekauft und sich die OS X CD aufs Klo gehängt. :)

-Nuke- schrieb:
Sicher. Der Athlon64 ist ein guter Prozessor. Nur die 64bit bringen nichts. Auch in naher Zukunft bleibt 64bit ne kleine Option. Solange Windows nicht durchweg 64bit ist, bleibt die PC-Masse bei 32bit. Also kann sich das noch Jahre hinziehen.

Ich sehe das anders - aber das wird die Zeit zeigen.

Eine nicht unbeträchliche Zahl von Freaks, die ein enormes Kundenpotential repräsentieren, schrauben, tweaken, overclocken und tunen ihre Systeme, um irgendwo auf Kosten der Stabilität 5% rauszuholen, und hinterher brauchen sie eine CO2-Kühlung, so groß wie ein Altpapiercontainer... Wenn das nicht wichtig wäre, hätten wir heutzutage andere Rechner, denn die meisten Kisten haben eigentlich viel zu viel Krempel drin, den der Anwender nicht braucht. Guck dir die ALDI-Kisten an: Grafik-Karte für digitalen Videoschnitt - die Leute haben nichtmal 'ne Digitalkamera. 10-Kanal-Surround-Sound-Stero - und drangehängt werden 8-Watt-Brüllwürfel vom Grabbeltisch. 3D-Beschleunigung, die Muttern beim Surfen nicht wirklich weiterhilft... TV-Ausgang, obwohl praktisch niemand seinen Rechner neben den Fernseher stellt... etc...pp...

Trotzdem "muß" man das alles haben. Hehe, deswegen war meinen Kiste ja so billig. Eigenbau ohne Overhead.

Gruß, Ratti
 
ratti schrieb:
Ja, das geht - das meinte ich mit "Hack".
Ich habe 3 Optionen genannt. Davon ist nur eine ein Hack (Finder-Datei durch eine andere ersetzen).
Durch Anpassen der Boot-Konfig in den Startprozess einzugreifen ist kein Hack, sondern Unix-Standard.
Wenn man die dritte Variante benutzt - nämlich den Finder zu beenden und was anderes zu starten, dann ist das ebenfalls kein Hack. Das Beenden einer Anwendung ist ebenso ein normaler Vorgang, wie das Starten von einer Anwendung. Wenn man das z.B. über ein Script automatisiert, dann ist das auch kein Hack, sondern Standard-Verfahren von fast jedem OS (inkl. Unix-Systemen).


ratti schrieb:
Man kann natürlich mit einem Installer Prozesse auf eigene Software verbiegen. Das bringt aber sehr viele Probleme mit sich:
- Was, wenn zwei Programme das versuchen?
Wieso sollen Installer irgendwelche Prozesse verbiegen? Wenn du dich auf die PathFinder-Methode beziehst (bin mir da nicht sicher, du drückst dich reichlich unklar aus), dann wird der Finder ganz einfach beendet. Nix wird umgebogen.
Wenn zwei Anwendungen versuchen sollten, den Finder zu beenden, dann wird das gleiche passieren, als wenn du mit kill einen nicht vorhandenen Prozess abschießt. Einfach nichts.
Darüber hinaus haben Anwendungen sowas nicht selbst zu entscheiden. Das entscheide ich selbst. PathFinder macht auch nur das was ich ihm sage (bzw. sagen würde, weil ich PathFinder nicht installiert habe).


ratti schrieb:
- Was, wenn man das wieder rückgängig machen will?
1.) Boot-Konfig zurück-ändern. Oder
2.) Doppelklick auf Finder.app bzw. aus dem Terminal heraus starten. Oder
3.) Wenn man den Finder gelöscht hat: Neu installieren bzw. Back-Up wiederherstellen.

Du stellst echt komische Fragen.


ratti schrieb:
- Die Modifikation erfolgt an nicht dokumentierter Stelle, also kann sie mit jedem Update Probleme verursachen.
Welche Mod denn?
Boot-Konfig ändern ist und bleibt dokumentierter Unix-Standard.
Das Beenden einer Anwendung auch.


ratti schrieb:
Das "saubere" Verfahren wäre, wenn man, als Beispiel, irgendwo eine Konfigurationsdatei hat, in der der Name des Finder-Binaries drinsteht
Und woher willste wissen, dass es die nicht gibt? Ich habe kein Bedürfnis diese Konfig zu ändern also habe ich mich auch nicht schlau gemacht ob es so eine Datei gibt. Und nur für dich werde ich mich nicht bemühen das herauszufinden.
Kannste selbst machen.


ratti schrieb:
Ich weise dezent darauf hin, daß (nach x86) die PowerPC-Community jahrelang die zweitgrößte Debian-Linux-Anwendergruppe war, bis sie diesen Monat von amd64 überholt wurden.
AMD64 (sowie die neuen Xeon- und P4-CPUs) sind auch weiterhin x86-CPUs. Da gibt es also nichts zu überholen.
Wenn die von Debian eine Unterscheidung zwischen x86 und AMD64 machen, dann vermutlich auch nur, weil die AMD64-Anpassungen noch nicht reif für x86 sind. Oder so.

Wieso drehst du diesen Thread eigentlich in Richtung Linux auf Athlon64-PC gegen Mac? Falls du es noch nicht bemerkt hast: Das ist das Unterforum "Linux am Mac".
Linux auf einem x86-PC zu installieren ist eine Sache, Linux auf einem Mac zu installieren, ist IMO grober Unfug.
(Linux testhalber auf einem x86-PC zu installieren, um zu sehen, ob es Mac-tauglich ist, ist kein Thema x86-PC vs. Mac)
 
Zuletzt bearbeitet:
Linux auf einem x86-PC zu installieren ist eine Sache, Linux auf einem Mac zu installieren, ist IMO grober Unfug.

Unfug würde ich es nicht nennen, aber meiner Meinung nach definitiv überflüssig.
 
KAMiKAZOW schrieb:
Ich habe 3 Optionen genannt. Davon ist nur eine ein Hack (Finder-Datei durch eine andere ersetzen).
Durch Anpassen der Boot-Konfig in den Startprozess einzugreifen ist kein Hack, sondern Unix-Standard.
Wenn man die dritte Variante benutzt - nämlich den Finder zu beenden und was anderes zu starten, dann ist das ebenfalls kein Hack. Das Beenden einer Anwendung ist ebenso ein normaler Vorgang, wie das Starten von einer Anwendung. Wenn man das z.B. über ein Script automatisiert, dann ist das auch kein Hack, sondern Standard-Verfahren von fast jedem OS (inkl. Unix-Systemen).

Das sind alles QuicknDirty-Hacks, denn sie sind durch den Distributor der Software nicht dokumentierte Funktionen. Weder nehmen Systemupgrades Rücksicht darauf, noch ist die Software kooperativ zueinander. Das ein normales "kill" funktioniert, heisst nicht, daß es ein sauberes Verfahren ist. Da gehört eine dokumentierte Schnittstelle hin, und die gibt es nicht,weil sie vom Distributor nicht gewollt ist.

KAMiKAZOW schrieb:
AMD64 (sowie die neuen Xeon- und P4-CPUs) sind auch weiterhin x86-CPUs. Da gibt es also nichts zu überholen.
Wenn die von Debian eine Unterscheidung zwischen x86 und AMD64 machen, dann vermutlich auch nur, weil die AMD64-Anpassungen noch nicht reif für x86 sind. Oder so.

Der war gut! Aua!

Der AMD64 hat einen 32-Bit Emulationsmodus, ist aber ein reinrassiger 64-Bit-Prozessor. Er hat doppelte Registerbreite, zusätzliche Befehle und Erweiterungen. Er stellt in allen Distris, die ihn unterstützen, eine eigene Platform dar, für die alle Binaries komplett neu kompiliert werden. Dabei muß etliches umgeschrieben werden, weil an etlichen Stellen ein Autor davon ausgegangen ist, ein "integer" seien 32 Bit.
Der entstehende Binärcode ist für x86 unbrauchbar.

Es ist alles ziemlich genau das selbe, wie es auf dem Mac mit dem G5 sein wird, wenn demnächst Tiger kommt. Derzeit ziehe ich auch G4-Rechner mit einer G5-CD hoch, und das wird dann vorbei sein.

KAMiKAZOW schrieb:
Linux auf einem x86-PC zu installieren ist eine Sache, Linux auf einem Mac zu installieren, ist IMO grober Unfug.

Du kannst für Unfug halten, was du willst.
In der echten Welt benutzen das viele Leute: http://popcon.debian.org/ , inklusiver meiner Person.

Gruß, Ratti
 
ratti schrieb:
Der war gut! Aua!

Der AMD64 hat einen 32-Bit Emulationsmodus, ist aber ein reinrassiger 64-Bit-Prozessor. Er hat doppelte Registerbreite, zusätzliche Befehle und Erweiterungen. Er stellt in allen Distris, die ihn unterstützen, eine eigene Platform dar, für die alle Binaries komplett neu kompiliert werden. Dabei muß etliches umgeschrieben werden, weil an etlichen Stellen ein Autor davon ausgegangen ist, ein "integer" seien 32 Bit.
Der entstehende Binärcode ist für x86 unbrauchbar.
OK, jetzt weiß ich's sicher. Vorher hatte ich's nur vermutet, aber jetzt bin ich mir zu 100% sicher: Du bist ein Ahnungsloser Linux-"Checker".

Die AMD64-Palttform unterstützt x86-32Bit nativ, ohne Emulation. Das ist auch nicht großartig anders als beim PPC970.
Dass man die Binaries nicht auf einem Pentium2-System ausführen kann, ist doch normal. Das war bei Sprung von 2x86 (16 Bit) zu 3x86 (32 Bit) auch nicht anders.
Und wenn du versuchst eine Anwendung, die du für einen Pentium 4 mit MMX, SSE, SSE2 optimiert hast, auf einem 3x86, 4x86, Pentium (5x86),... auszuführen, dann geht das auch nicht.
Der 64Bit-Modus von AMD64-CPUs ist lediglich eine Erweiterung - keine komplett neue Architektur.
Klar muss vieles für die 64Bit-Erweiterungen umgeschrieben werden, um richtig optimiert werden zu können. Das bekräftigt doch gerade meine Annahme, dass wohl die "AMD64-Anpassungen noch nicht reif für x86 sind".


"AMD64 bietet die marktführende Performance für all Ihre Software-Anwendungen. Sowohl der AMD Opteron als auch die neuen AMD Athlon 64 Prozessoren verarbeiten moderne x86-Software nativ und nicht im „Emulationsmodus“, was die Performance erheblich steigert." Zitat von AMD.com

Du hast keinen Peil, bist nicht einmal in der Lage AMD64 und IA64 (Itanium - der hat Pentium-Emulation) auseinander zu halten und gehst mit deiner Trollerei auch noch hausieren.

Es gibt keinen Grund noch weiter auf dich zu reagieren. Zeitverschwendung. Trolle woanders herum.
 
Zuletzt bearbeitet von einem Moderator:
KAMiKAZOW schrieb:
Die AMD64-Palttform unterstützt x86-32Bit nativ, ohne Emulation. Das ist auch nicht großartig anders als beim PPC970.
Dass man die Binaries nicht auf einem Pentium2-System ausführen kann, ist doch normal. Das war bei Sprung von 2x86 (16 Bit) zu 3x86 (32 Bit) auch nicht anders.

Du hast recht, ich habe mich nicht korrekt ausgedrückt.
Das rechtfertigt aber nicht sowas:

KAMiKAZOW schrieb:
Du hast keinen Peil, bist nicht einmal in der Lage AMD64 und IA64 (Itanium - der hat Pentium-Emulation) auseinander zu halten und gehst mit deiner Trollerei auch noch hausieren.

Es gibt keinen Grund noch weiter auf dich zu reagieren. Zeitverschwendung. Trolle woanders herum.

Nachdem hier etliche Nachrichten lang "auf doof gemacht hast", fängst du JETZT an, plötzlich den Fachmann raushängen zu lassen - nachdem ich es möglichst einfach zu erklären versucht habe. Toll. Danke.

Ach, und nochwas:
Die persönlichen Angriffe ("Troll") disqualifizieren dich. Leute wie du machen die Kommunikation im Netz kaputt. Sowas finde ich Scheisse.

http://www.leckse.net/profilieren/

Gruß, Ratti
 
Also ich lese hier von Ratti NUR negatives. Er hat immer Recht. OK. Es ist sein gutes Recht anderer Meinung zu sein. Wenn er Mac OS X nicht mag muss er es nicht benutzen. Fakt ist Linux ist gerade durch seine Felixibilität nicht reif für den Anwenderdesktop. Solange sich die Community nicht auf einheitliche Designrichtlinien einigt wird das auch nix. Im Netzwerkumfeld und Serverbereich hat es nicht nur seine Daseinsberechtigung sondern ist zwischenzeitlich auch dort zuhause. Wenn er Linux auf der PPC Architektur nutzen will kann er das auch gerne tun. Ich werde es nicht machen. Dafür ist mir die Plattform zu kostspielig. Wenn ich spielen will nehme ich meinen PC. Mein privater File- und Druckserver hier läuft übrigends auch auf Linux. Für solche lächerlichen Aufgaben wäre mir ein aktueller Mac zu schade.
Ich denke nicht, daß es wirklich was bringt sich noch weiter mit ihm zu unterhalten.
 
@kamikazow:

das war zwar technisch gut aber ein bisschen ruppig am ende. schäm dich.

;)

@ratti

du wirst zugeben müssen, dass deine aussagen jetzt schon mehrfach
widerlegt wurden, und du jedesmal sagst: "stimmt, ich habe mich
nicht korrekt ausgedrückt." wunder dich also nicht, wenn du die
entsprechenden reaktionen bekommst. so sind die jungs nun mal.

:)
 
Zurück
Oben Unten