Login
Newsletter
Werbung

Thema: XFree86 4.5.0

22 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Gast am Mo, 21. März 2005 um 12:45 #
Wenn man bedenkt, dass XFree X erst auf den Linux-PC gebracht hat, ist diese Entwicklung doch schon etwas traurig. Auch schon, der Streit unter den Entwicklern ist ja nicht so toll gewesen.
[
| Versenden | Drucken ]
  • 0
    Von Erik am Mo, 21. März 2005 um 13:25 #
    Naja. Wenn man verschiedene andere Probleme in der Vergangenheit bedenkt, zum Beispiel den Ausschluß von Keith Packard, dann war es alles in allem gut, daß es so gelaufen ist, wie es gelaufen ist. Die XFree86-Entwickler empfanden sich schon immer als etwas ganz besonderes, und die Verwendung einer BSD 1-angelehnten Klausel unterstreicht das gottgleiche Selbstempfinden. Hochmut kommt eben vor dem Fall.


    lg
    Erik

    [
    | Versenden | Drucken ]
    • 0
      Von Sascha am Di, 22. März 2005 um 07:42 #
      Jup bei XFree86 hat man alles getan um sich selbst ins eigene Bein zu schießen was ja bekanntlich in der Gründung von X.org gemündet hat. Ich hoffe das X.org auf Dauer nicht zu dem verkommt was XFree86 jetzt ist. Persönlich würde ich mir aber nach wie vor einen vektororientierten Desktop wünschen.

      Grüße
      Sascha

      [
      | Versenden | Drucken ]
0
Von thomas001 am Mo, 21. März 2005 um 12:45 #
Also ich finde mitunter bessere Hardwareunterstuetzung als bei X.org schon ein ganz schoenes Feature, und bestimmt sinniger als nen Fenster mit Schatten.
[
| Versenden | Drucken ]
  • 0
    Von RvB am Mo, 21. März 2005 um 13:01 #
    Die haben bei X.Org noch Schatten? Kann man dieses Feature bei der vielen Transparenz nicht wieder verwerfen? Durchsichtiges wirft eh keine. ;)
    [
    | Versenden | Drucken ]
    • 0
      Von Anothermous am Mo, 21. März 2005 um 13:54 #
      Beides Features, die ich bisher nicht mal getestet/gesehen habe. Aber mich interessiert
      was anderes: Ich versuche gerade, das Monster für x86-64 zu übersetzen. Hat eigentlich auch
      schon geklappt. Das Problem ist, dass X.org (wahrscheinlich auch XFree) die Kompatibilitäts-
      Libraries (32-bit unter lib) nicht beim "make World" erzeugt. Stattdessen werden nur die
      64-bittigen Libs unter lib64 erzeugt. Ist ja schon mal was -- X läuft auch. Nur stehe ich
      damit vor dem Problem, dass sich gewisse andere Applikationen (z.B. mplayer) nur mit diesen
      Libs nicht übersetzen und verwenden lassen. Wie komme ich also an die 32-bit-Libs? Eine
      Vermutung wäre ein zweiter Durchlauf mit gesetzem CFLAGS="-mtune=athlon-xp -m32" (bzw.
      anders herum: erst die 32-bit-Version erzeugen und dann die 64-bit-Version, damit alle
      Applikationen ausser der Libraries überschrieben werden)!? Oder gibts da einen anderen
      Trick oder eine andere Vorgehensweise. Die Doku schweigt sich da ziemlich drüber aus. Hat
      das schon mal jemand gemacht oder hat einen Link zu einem passenden Hinweis? Google findet
      ja ziemlich viel zum Thema amd64 und 32bit, aber irgendwie nichts, was genau und präzise zu
      dieser Fragestellung passt.

      A.

      [
      | Versenden | Drucken ]
      • 0
        Von fuffy am Mo, 21. März 2005 um 14:51 #
        Der MPlayer lässt sich auch 64bittig kompilieren. Nur die Binärcodecs (Windows Media, Real Media, Quicktime) lassen sich dann nicht mehr verwenden.
        [
        | Versenden | Drucken ]
        • 0
          Von Anothermous am Mo, 21. März 2005 um 15:32 #
          Schön und gut. Für welche Codecs wird es dann problematisch? Der lavc kann afaik eine ganze
          Menge, aber kann er alles? Und wenn ich mir ansehe, wieviele 32-bit-Libs eine x86-64
          Version von Fedora oder Ubuntu so mitbringt, dann dürfte der mplayer nicht das einzige
          "Problem" darstellen. Allein schon die glibc ist unheimlich aufgeblasen und wird komplett
          in 32-bit und 64-bit installiert. Ein "make boostrap" vom gcc (3.4.3) erzeugt direkt beide
          Versionen -- einen gcc, der defaultmässig 64-bit-Code erzeugt, aber auch benötigte 32-bit
          Libs, wenn "-m32" in den CFLAGS von Nöten sein sollte. Das wird alles schon so seine Gründe
          haben. :-)

          A.

          [
          | Versenden | Drucken ]
          • 0
            Von g. am Mo, 21. März 2005 um 16:12 #
            Für welche Codecs wird es dann problematisch?

            Fuer die, die im "essential"-Paket von MPlayer sind, die anderen sind ja alle OS.


            Und wenn ich mir ansehe, wieviele 32-bit-Libs eine x86-64
            Version von Fedora oder Ubuntu so mitbringt, dann dürfte der mplayer nicht das einzige
            "Problem" darstellen. Allein schon die glibc ist unheimlich aufgeblasen und wird komplett
            in 32-bit und 64-bit installiert. Ein "make boostrap" vom gcc (3.4.3) erzeugt direkt beide
            Versionen -- einen gcc, der defaultmässig 64-bit-Code erzeugt, aber auch benötigte 32-bit
            Libs, wenn "-m32" in den CFLAGS von Nöten sein sollte. Das wird alles schon so seine Gründe
            haben.

            Hoechstwahrscheinlich deshalb, damit Closed-Source-Programme noch laufen, wie z.B. Acroread, RealPlayer, etc.

            [
            | Versenden | Drucken ]
            0
            Von fuffy am Mo, 21. März 2005 um 16:14 #
            > Für welche Codecs wird es dann problematisch?
            Wie schon gesagt: Manche Quicktime-, Real- bzw. Windows Media-Formate.
            Für alles andere gibt es OpenSource-Codecs (libavcodec, mpglib, liba52, libvorbis, ...).

            > Und wenn ich mir ansehe, wieviele 32-bit-Libs eine x86-64 Version von Fedora oder Ubuntu so mitbringt, dann dürfte der mplayer nicht das einzige "Problem" darstellen.
            Ubuntu liefert verglichen mit Fedora extrem wenig Pakete mit. Die dienen ohnehin nur dazu, unfreie Programme zum Laufen zu bewegen, da man diese natürlich nicht 64-bittig neu kompilieren kann.

            Bei Gentoo reicht es also normalerweise aus, für proprietäre Anwendungen/Spiele die paar Ebuild aus emul/... zu emergen.

            [
            | Versenden | Drucken ]
        0
        Von tom am Mo, 21. März 2005 um 15:26 #
        das mit dem "drüberkompilieren" wird wahrscheinlich nicht klappen. Damit überschreibst du die eine Version mit der anderen.

        Die bei Gentoo haben für den ganzen Kompatibilitäts-Kram ein eigenen Verzeichnisbaum namens /emul/linux/x86/. Unter dieser Root sind alle 32-bittigen libs abgelegt. Du brauchst ja auch die glibc in 32Bit, oder wohlöglich nvidia-Treiber in 32Bit, die Soundlibs etc. Diese Libraries werden wohl cross-compiled sein. Wie genau, weiss ich nicht.

        Binaries, wie der 32-Bittige Firefox liegen hingegen im ganz normalen Verzeichnis-Baum.

        Bei dem Ganzen spielt auch die Kernelerweiterung IA32-Emulation eine nicht unwesentliche Rolle.

        Wie das jetzt alles genau zusammenspielt weiss ich nicht, funktioniert aber ganz gut. Da gibt's garantiert auch Docs zu...

        Grüße und viel Spaß ;)

        Thomas

        [
        | Versenden | Drucken ]
        • 0
          Von Anothermous am Mo, 21. März 2005 um 15:47 #
          | das mit dem "drüberkompilieren" wird wahrscheinlich nicht klappen. Damit überschreibst du
          | die eine Version mit der anderen.

          Eben! Daher auch zuerst die 32-bit-Version, anschliessend die 64-bit-Version, denn bei der
          32-bit-Version landen die shared-libs automatisch in /usr/X11R6/lib, bei der 64-bit-Version
          landen die shared-libs in /usr/X11R6/lib64. Wenn die Programme in /usr/X11R6/bin überbraten
          werden, dann ist mir das herzlich egal, denn die zuletzt installierten Versionen wären ja
          die mit 64-bit. Die shared-libs mit 32-bit wären aber noch da uns man könnte dagegen
          linken.

          Trotzdem bin ich mir da immer noch nicht ganz sicher, ob ich da jetzt nicht noch einen
          Denkfehler mache. Zumindest eine Sache ist mir aufgefallen nach der Installation: Die
          Module landen ebenfalls in /usr/X11R6/lib64/X11/modules, werden aber beim Start nicht
          gefunden. Erst wenn man einen Link anlegt

          /usr/X11R6/lib/X11/modules -> /usr/X11R6/lib64/X11/modules

          startet der X-Server ohne zu meckern durch. Wenn da noch andere so kleine Tücken lauern,
          dann wirds mit dem Selberbauen problematisch.

          Cross-Compiling hatte ich auch schon mal versucht, aber verdammt schnell wieder aufgegeben.
          Das ist die Hölle! Nein danke, lieber nicht mehr. ;-)

          A.

          [
          | Versenden | Drucken ]
    0
    Von Kai F. Lahmann am Mo, 21. März 2005 um 13:48 #
    dieses Relase klingt aber nicht so, als ob man da etwas verbessert hätte. Oder wo sind Hinweise auf die obligatorischen Updates der Treiber für ATI-, nVidia-, intel-, VIA- und matrox-Chips? Nur bei nVidia steht was davon... Und so wichtig eine endlose Treiberliste ist, die *aktuelle* Hardware ist immer noch um einiges wichtiger, als alle 10 Jahre alten Exoten zusammen.
    [
    | Versenden | Drucken ]
    • 0
      Von thomas001 am Mo, 21. März 2005 um 14:50 #
      in foren anderer grosser news seiten mit erstaunlich hohem troll anteil munkelt man z.b. dualhead und so bei gewissen intel chips geht nur bei xf4.5
      [
      | Versenden | Drucken ]
      • 0
        Von g. am Mo, 21. März 2005 um 15:11 #
        Gibts ueberhaupt Produkte mit Intel-Chips, die DH hardwaremaessig koennen?
        [
        | Versenden | Drucken ]
0
Von Rohrmann Andreas am Di, 22. März 2005 um 09:34 #
Hallo.
Mal eine vielleicht dumme Frage:

Ist es einfach, ein bestehendes XFree-System auf X.org umzustellen und ist das sinnvoll?
Derzeit läuft bei mir ein Kanotix 8/2004 mit XFree.
Kann man zum "pobieren" auch beide XFree und X.org parallel betreiben?

Danke für die Antwort.
Vielleicht kennt jemand einen guten Link auf eine Anleitung zu den o.g. Fragen...

[
| Versenden | Drucken ]
  • 0
    Von hjb am Di, 22. März 2005 um 10:37 #
    Hi,

    Parallelbetrieb ist nicht möglich, da beide /usr/X11R6 als Pfad verwenden und dies in zahlreichen Stellen im Code verankert ist. Man könnte natürlich X.org selbst kompilieren mit anderem Pfad...

    Aus diesem Grund ist der Update auf X.org auch recht einfach. Die Konfigurationsdatei heißt jetzt xorg.conf, aber die Syntax ist gleich geblieben und auch die sonstigen Strukturen sind weitgehend identisch.

    [
    | Versenden | Drucken ]
    • 0
      Von Rohrmann Andreas am Di, 22. März 2005 um 11:27 #
      hjb, danke für den Hinweis.

      Würde ein apt-get install "x.org" (oder wie auch immer das Paket heißt) und cp XF86Config-4 xorg.conf reichen?

      Erscheint mir zu einfach ;-)

      [
      | Versenden | Drucken ]
      • 0
        Von hjb am Di, 22. März 2005 um 14:31 #
        Hi,

        so ähnlich habe ich es gemacht und es gab keine Probleme außer daß manche Tastenkombinationen mit Shift+Ctrl erst nach mehrmaligem Drücken erkannt werden. Keine Ahnung, warum. Im Prinzip habe ich nur meine sources.list erweitert:

        # Unofficial X.org

        deb http://debian.linux-systeme.com unstable main

        [
        | Versenden | Drucken ]
        • 0
          Von g. am Di, 22. März 2005 um 15:08 #
          Bezueglich der Umstellung auf X.org habe ich diese Variante gewaehlt.
          Es ging mir allerdings dabei weniger darum, X.org zu installieren, sondern ich brauchte einigermassen aktuelle DRI-Treiber, um die 3D-Beschleunigung meiner Radeon 9250 zu nutzen. Die damit verbundene Umstellung auf X.org war dabei eine nette "Dreingabe".
          Bisher hat sich diese Loesung als voellig problemlos erwiesen und ich hatte auch mit keinen Tastenkombinationen bisher Probleme.
          [
          | Versenden | Drucken ]
    0
    Von Rohrmann Andreas am Di, 22. März 2005 um 17:21 #
    Vielen Dank für die Tipps!

    Bin immer wieder und jeden Tag mit ProLinux zufrieden... !

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung