Hatte den Namen "Metisse" bisher paar Mal gelesen, aber ohne genau zu wissen, worum es sich dabei konkret handelt. Nach Wikipedia und einen YouTube-Video bin ich nun schlauer!
Metisse sieht echt interessant aus - vlt. sogar nützlicher als Compiz Fusion. Letzteres ist eine nette Spielerei, aber nur wenige Effekte erleichtern tatsächlich die Arbeit, während Metissa scheinbar echt das Arbeiten mit vielen Fenstern vereinfacht.
Kann jmd. was über die Stabilität, Performance und Nutzbarkeit sagen? Wie lässt es sich bedienen? Gibt es offizielle DEB-/RPM-Packages für andere Distributionen als Mandriva? Wie funktioniert Metisse? Ähnlich wie Compiz, d.h. setzt es auf die AIGLX-Erweiterung? (Kenne mich da nicht so gut aus)
Ich hatte mal mit der Metisse-LiveCD herumgespielt. Sie lief weitgehend stabil und vor allem lief die LiveCD schneller, als mein installiertes KDE3.5.7.
Ich bin seit Jahren Mandrake/Mandriva-User, und war immer sehr zufrieden mit der Distribution. Seit ein paar Versionen (vermutl. seit 2005.0), auch in der 2008.0-Beta, ist allerdings ein Großteil der Initskripte verpfuscht, da mit den neuen LSB-Headern gearbeitet wird, welche statt fester Start-/Stop-Reihenfolge Abhängigkeiten definieren. Die Mandriva-Pfuscher waren offensichtlich nicht in der Lage, diese Abhängigkeiten ordentlich in die Skripte einzutragen. So wird ypbind (yp-client) nach netfs (nfs-client) gestartet, was dazu führt, dass nfs-Freigaben nicht beim Booten eingehängt werden können, so man in der fstab mit Rechnernamen statt IP-Adressen arbeitet, wie es sich gehört. Auch dm (Displaymanager) wird vor ypbind gestartet, was (meist) nur deshalb gut geht, d.h., die Benutzer werden angezeigt, weil der X-Server so lange zum Starten benötigt. Das waren jetzt nur die schlimmsten Fehler diesbezüglich... Und damit nicht genug. Seit 2007.1 benötigt man in /etc/sysconfig/network-scripts/ifcfg-ethX die Option "NEEDHOSTNAME=yes", wenn man den Rechnernamen vom dhcp-Server übernehmen möchte, welche trotz default-mäßig gesetzten Häkchens im Kontrollzentrum fehlt - entfernt man das Häkchen und setzt es anschließend wieder, wird die Option in das Config-File geschrieben. Das alles sind Kleinigkeiten, die aber extrem nerven, wenn man ein Netz mit 30 Clients mit der Distri hochziehen will. Ich kann mir einfach nicht vorstellen, dass so gravierende Fehler an elementarer Stelle - vor allem die Probleme mit den Initskripten - noch von niemandem bemerkt worden sind. Die User-Zahl wird doch nicht *so* extrem zurückgegangen sein? Wie es aussieht, werde ich es wohl selbst melden müssen - hoffentlich interessiert es die Verantwortlichen. Als Stand-alone-Desktop und als Server läuft die Distri einwandfrei...
Das übliche Problem bei Mandriva - leider. Das sind letzendlich die Sachen die mich von Mandriva weggebracht haben. Debian mag nicht immer einfach sein - aber am Ende durchdacht und leicht zu administrieren. Jeder Vorteil durch einfache Handhabung geht halt flöten wenn man sowas dann selbst rausfinden muss
Andererseits wird es vielleicht mal wieder Zeit über den Tellerrand zu schauen Mal schauen ob ich Lust und Zeit habe
Leider war Mandriva 2007 auf amd64 völlig instabil. Hat zwar alles gut installiert aber danach nie wieder gebootet. Na ja 64 Bit ist unter fast jedem OS (bis auf Solaris und HP-UX) nichts weiter als eine völlige Katastrophe. Egal ob Open/Net/FreeBSD oder Linux oder WinXP. Was für ein Scheiss.
Ich nutze auf mehreren Rechnern Gentoo Linux in der x86_64 Version. Kann nicht sagen, dass das sonderlich katastrophal läuft. Wenn man mit dem Speichermehrverbrauch leben kann, ist das mitunter sogar angenehmer als i386, da in manchen Bereichen ja doch deutlich schneller.
vielleicht ist es noch nicht bei allen angekommen: 64bit ist nur sinnvoll wenn man mehr als 4 Gb Hauptspeicher ansprechen muss. Für eine Scchreibtischmaschine noch etwas unwahrscheinlich.
Weil es auch mit einem neuen Kompiler übersetzt wurde, und dieser neue Optimierungen kennt. Dies hat nichts mit der Möglichkeit zu tun das 64bit-Prozessoren mehr Speicher ansprechen können. Vorher mal Hirn einschalten, oder fragen... Manche sind schon sehr helle hier ... Mann oh mann...
> Weil es auch mit einem neuen Kompiler übersetzt wurde, und dieser neue Optimierungen > kennt.
Ah, wenn ich den gcc mit 64-bit-Flag betreibe, habe ich einen ganz neuen Compiler, der Optimierungen anwendet, die sein 32bit-Pendant nicht kennt, obwohl sie prinzipiell genauso gut auch fuer 32Bit-Architekturen funktionieren? Vermutest du nur, oder kennst du Details? Nicht das das nicht denkbar waere (beim gcc ist ja nicht immer alles "logisch"...), aber naheliegend wie du behauptest ist es auf keinen Fall.
> Manche sind schon sehr helle hier ... Mann oh mann...
> Vermutest du nur, oder kennst du Details? Gcc-interne Dokumentation lesen. Kann man sich bei einer ordentlichen Distribution nachinstallieren, oder man erzeugt sie sich selbst wenn man mal sich einen Kompiler selbst übersetzt.
Achso, na dann. Nimm eine Distribution die noch mit der 3er-Serie des gcc übersetzt würde und lass sie auf 32bit laufen. Jetzt haben wir aber schon eine Weile die 4er-Serie, hier wurde viel am Backend gemacht, also sehr viele neue Flags, was der Programmierer also selber benutzt. Und es wurde auch sehr viel im Middleend gemacht. Eine lustige Nebenerscheinung war mal das ein 3.5er gcc, also ein sich in Entwicklung befundenen Kompiler in sehr seltenen Flagkombinationen Zählvariablen wegoptimierte. Fazit: suboptimal. So, nun zum Thema 64bit: die Prozessoren haben sich im Vergleich zu i386 bis i686 sehr verändert. Ein aktueller AMD-Prozessor kann zwar noch den 386 Befehlssatz, aber noch wesentlich mehr. Ein aktueller Kompiler kann natürlich auch besser neuer Prozessoren ansprechen, also besser auf den entsprechenden Prozessor optimieren, als einer aus der 3er-Serie. Nimm jetzt mal ziehmlich identische Software, übersetze die mit den Architekturspezifischen Flags von einem alten und einem neueren Kompiler. Da kann es auf amd64 schneller sein als auf z.B. einem Celeron. Eine große Rolle spielt auch der Prozessorinterne Speicher, dauert viel länger die Befehle aus dem Arbeitsspeicher zu holen im Gegensatz dazu wenn sie noch im Prozessorinternen Speicher sind. Und ein aktueller AMD-Prozessor, jetzt mal nicht der Semptron-Kram, hat mehr internen Speicher als irgendwelche alten Pentiums.
Sinn Macht das ganze 64bit-Getönst aber erst wenn man mehr als 4GB Arbeitsspeicher ansprechen muss. Und das wird so schnell auf einem Zuhause-PC nicht passieren, vielleicht irgendwann mal bei der Daddler-Fraktion...
Heisst aber nicht im Klartext, das eine 32Bit Software weniger mit dem Prozessor anfangen kann, als die 64Bitige, wenn beide mit dem 4er gcc gebaut sind?
Bei gleicher Software, einmal für 32bit und einmal für 64bit übersetzt wird der jeweilige Befehlssatz verwendet. Wenn im 64bittigen Befehlssatz bessere Sprungvorhersagen sind kann die Software etwas schneller sein als in der 32bit-Version auf dem gleichen Prozessor. Schneller wird der Laden nur wenn das System insgesamt schneller wird, die Bitbreite ist nur für die Menge des anzusprechenden Hauptspeichers relevant.
Von Andreas B. am So, 9. September 2007 um 19:24 #
Also die Erklärung "es hat nie wieder gebootet" ist doch etwas schwach, bis wohin isser denn gekommen, war der bootloader verhunzt ? Das wäre nicht unbedingt neu bei mandrakes Bootloader Tool welches ab und zu, zu bestimmten Konfigurationen unbootbare lilos und grubs rauswirft, z.B. installierte MDK wenn man es Ihm nicht explizit gesagt hat, den Bootloader konsequent im Bootbereich der rootpartition und nicht im MBR der Platte. Also an der konf rum basteln und grub sagen husch husch da ist der MBR fass! oder falls das zu schwierig ist xfdisk (googlen) ausprobieren, und den bootloader davon benutzen und mal die rootpartition des MDK64 zu booten versuchen. Das Prog ist zwar uralt, aber es läuft hervorragend.
Wie kann es denn unstabil sein, wenn es nie wieder gebootet hat? Habe selbst noch ein Erstinstall MDV 2006 auf AMD64 laufen und bis auf Firefox ist nie was gecrasht. Macht aber nix, er startet dort neu, wo er aufhörte "Schei*" sind nur die 3th-party-Produkte, wie flash und Java-Teile, welche mit 64 Bit nicht laufen.
Von Christopher Bratusek am Mo, 10. September 2007 um 12:50 #
MDV64 ist ein biarch system, das heisst, dass du im packet manager 32bit kompatibilitäts bibliotheken installieren und so die 3rdparty software zum laufen bringen kannst.
Metisse sieht echt interessant aus - vlt. sogar nützlicher als Compiz Fusion. Letzteres ist eine nette Spielerei, aber nur wenige Effekte erleichtern tatsächlich die Arbeit, während Metissa scheinbar echt das Arbeiten mit vielen Fenstern vereinfacht.
Kann jmd. was über die Stabilität, Performance und Nutzbarkeit sagen? Wie lässt es sich bedienen?
Gibt es offizielle DEB-/RPM-Packages für andere Distributionen als Mandriva?
Wie funktioniert Metisse? Ähnlich wie Compiz, d.h. setzt es auf die AIGLX-Erweiterung? (Kenne mich da nicht so gut aus)
Würde mich echt interessieren.
http://insitu.lri.fr/metisse/
Und damit nicht genug. Seit 2007.1 benötigt man in /etc/sysconfig/network-scripts/ifcfg-ethX die Option "NEEDHOSTNAME=yes", wenn man den Rechnernamen vom dhcp-Server übernehmen möchte, welche trotz default-mäßig gesetzten Häkchens im Kontrollzentrum fehlt - entfernt man das Häkchen und setzt es anschließend wieder, wird die Option in das Config-File geschrieben.
Das alles sind Kleinigkeiten, die aber extrem nerven, wenn man ein Netz mit 30 Clients mit der Distri hochziehen will. Ich kann mir einfach nicht vorstellen, dass so gravierende Fehler an elementarer Stelle - vor allem die Probleme mit den Initskripten - noch von niemandem bemerkt worden sind. Die User-Zahl wird doch nicht *so* extrem zurückgegangen sein? Wie es aussieht, werde ich es wohl selbst melden müssen - hoffentlich interessiert es die Verantwortlichen. Als Stand-alone-Desktop und als Server läuft die Distri einwandfrei...
Andererseits wird es vielleicht mal wieder Zeit über den Tellerrand zu schauen
Mal schauen ob ich Lust und Zeit habe
http://qa.mandriva.com/
Na ja 64 Bit ist unter fast jedem OS (bis auf Solaris und HP-UX) nichts weiter als eine völlige Katastrophe. Egal ob Open/Net/FreeBSD oder Linux oder WinXP. Was für ein Scheiss.
Vorher mal Hirn einschalten, oder fragen...
Manche sind schon sehr helle hier ... Mann oh mann...
> kennt.
Ah, wenn ich den gcc mit 64-bit-Flag betreibe, habe ich einen ganz neuen Compiler, der Optimierungen anwendet, die sein 32bit-Pendant nicht kennt, obwohl sie prinzipiell genauso gut auch fuer 32Bit-Architekturen funktionieren? Vermutest du nur, oder kennst du Details?
Nicht das das nicht denkbar waere (beim gcc ist ja nicht immer alles "logisch"...), aber naheliegend wie du behauptest ist es auf keinen Fall.
> Manche sind schon sehr helle hier ... Mann oh mann...
Glashaus...
Gcc-interne Dokumentation lesen. Kann man sich bei einer ordentlichen Distribution nachinstallieren, oder man erzeugt sie sich selbst wenn man mal sich einen Kompiler selbst übersetzt.
schönen Sonntag noch
Übrigens:
> Vorher mal Hirn einschalten, oder fragen...
der Beitrag zuvor war doch wohl eine Frage, oder Klausi ??
Achso, na dann.
Nimm eine Distribution die noch mit der 3er-Serie des gcc übersetzt würde und lass sie auf 32bit laufen. Jetzt haben wir aber schon eine Weile die 4er-Serie, hier wurde viel am Backend gemacht, also sehr viele neue Flags, was der Programmierer also selber benutzt. Und es wurde auch sehr viel im Middleend gemacht. Eine lustige Nebenerscheinung war mal das ein 3.5er gcc, also ein sich in Entwicklung befundenen Kompiler in sehr seltenen Flagkombinationen Zählvariablen wegoptimierte. Fazit: suboptimal.
So, nun zum Thema 64bit: die Prozessoren haben sich im Vergleich zu i386 bis i686 sehr verändert. Ein aktueller AMD-Prozessor kann zwar noch den 386 Befehlssatz, aber noch wesentlich mehr. Ein aktueller Kompiler kann natürlich auch besser neuer Prozessoren ansprechen, also besser auf den entsprechenden Prozessor optimieren, als einer aus der 3er-Serie.
Nimm jetzt mal ziehmlich identische Software, übersetze die mit den Architekturspezifischen Flags von einem alten und einem neueren Kompiler. Da kann es auf amd64 schneller sein als auf z.B. einem Celeron. Eine große Rolle spielt auch der Prozessorinterne Speicher, dauert viel länger die Befehle aus dem Arbeitsspeicher zu holen im Gegensatz dazu wenn sie noch im Prozessorinternen Speicher sind. Und ein aktueller AMD-Prozessor, jetzt mal nicht der Semptron-Kram, hat mehr internen Speicher als irgendwelche alten Pentiums.
Sinn Macht das ganze 64bit-Getönst aber erst wenn man mehr als 4GB Arbeitsspeicher ansprechen muss. Und das wird so schnell auf einem Zuhause-PC nicht passieren, vielleicht irgendwann mal bei der Daddler-Fraktion...
So, sonst noch Fragen, Kommentare?
Heisst aber nicht im Klartext, das eine 32Bit Software weniger mit dem Prozessor anfangen kann, als die 64Bitige, wenn beide mit dem 4er gcc gebaut sind?
war der bootloader verhunzt ? Das wäre nicht unbedingt neu bei mandrakes Bootloader Tool welches
ab und zu, zu bestimmten Konfigurationen unbootbare lilos und grubs rauswirft,
z.B. installierte MDK wenn man es Ihm nicht explizit gesagt hat, den Bootloader konsequent
im Bootbereich der rootpartition und nicht im MBR der Platte. Also an der konf
rum basteln und grub sagen husch husch da ist der MBR fass! oder falls das zu schwierig ist xfdisk (googlen)
ausprobieren, und den bootloader davon benutzen und mal die rootpartition des MDK64 zu booten versuchen.
Das Prog ist zwar uralt, aber es läuft hervorragend.
Habe selbst noch ein Erstinstall MDV 2006 auf AMD64 laufen und bis auf Firefox ist nie was gecrasht. Macht aber nix, er startet dort neu, wo er aufhörte
"Schei*" sind nur die 3th-party-Produkte, wie flash und Java-Teile, welche mit 64 Bit nicht laufen.