Login
Newsletter
Werbung

Thema: Lumina-Desktop 1.1.0 erschienen

38 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Asmish am Mo, 24. Oktober 2016 um 15:52 #

Unterstützt Lumina wie KDE Plasma und Gnome vollständig Wayland und bietet es Double Hi-DPI für 4K TV Geräte über HDMI2.0b?
Bisher wird nur KDE Plasma 5.8.1 sowie Gnome 3.22 richtig auf den 55Zoll TV dargestellt. Mit den bisher weiteren getesteten Oberflächen Xfce, Mate und Cinnamon werden die Symbole oder die Schriftzeichen nicht richtig dargestellt (verpixelt, zu groß oder zu klein, oder die Medieninhalte von Videomaterial in 1080p bzw. 4K sind in in schnellen Szenen verwaschenen bzw es entstehen Artefakt.

[
| Versenden | Drucken ]
  • 0
    Von da-real-lala am Mo, 24. Oktober 2016 um 17:38 #

    Wayland kommt automatisch durch qt5. Hidpi weiß ich nicht.

    [
    | Versenden | Drucken ]
    • 0
      Von ich am Mo, 24. Oktober 2016 um 17:44 #

      Nein, Qt5 heißt nur die Anwendungen laufen nativ unter Wayland. Knackpunkt ist der Window Manager und der bislang von Lumina verwendete Fluxbox läuft nur unter X. Vielleicht kann man, analog zu LXQt, ja KWin benutzen. Dann geht auch Wayland.

      [
      | Versenden | Drucken ]
      • 0
        Von XYZ am Mo, 24. Oktober 2016 um 18:19 #

        Stellt sich die Frage, ob BSD das "hochgelobte" Wayland überhaupt haben will. Bisher ist Wayland eher ein Experiment, dass sich erstmal behaupten muss. X abzulösen bedeutet erstmal in große Fußstapfen zu treten und das sehe ich erstmal für die kommenden Jahre nicht!

        [
        | Versenden | Drucken ]
        • 0
          Von da-real-lala am Mo, 24. Oktober 2016 um 19:54 #

          "Bisher ist Wayland eher ein Experiment, dass sich erstmal behaupten muss"

          Übertreibung. Wayland funktioniert für so wenig Entwicklung schon sehr gut. Ich glaube 2017 wird das Jahr, in dem Waylands Macken und dessen Rückwärtskompatibilität mit XWayland ausgebügelt werden. 2018 kann ich mir vorstellen, Xorg nur noch für ältere Videospiele über XWayland zu benutzen. An Programmen fehlen eigentlich nur ein paar, die GTK2 benutzen und noch nicht auf GTK3 oder QT portiert sind.

          [
          | Versenden | Drucken ]
          0
          Von kraileth am Di, 25. Oktober 2016 um 09:36 #

          Allgemein zum Wayland-Unterstützung und *BSD: Nach meinem Empfinden reißen sich die meisten Projekte nicht gerade darum. Ausnahme ist FreeBSD, wo doch ein paar Leute an der Wayland-Unterstützung basteln. Für TrueOS (FreeBSD-basiert) hat allerdings der leitende Entwickler wiederholt großes Interesse an Wayland geäußert, es ist also insbesondere in Bezug auf Lumina davon auszugehen, daß das irgendwann(tm) passieren wird. Bei OpenBSD sehe ich eine Hinwendung zu Wayland nicht wirklich. Net- und DragenFlyBSD kann ich diesbezüglich nicht einschätzen, würde es DragonFly aber eher zutrauen (die waren immer schon sehr aktiv am Grafikstack und haben ein paar Leute, die das - wenn es sie interessiert - hinbekommen dürften.

          [
          | Versenden | Drucken ]
        0
        Von da-real-lala am Mo, 24. Oktober 2016 um 19:55 #

        Statt Fluxbox Kwin einsetzen und dann sollte das klappen. Aber ja, die Frage nach dem Hidpi ist damit noch nicht gelöst.

        [
        | Versenden | Drucken ]
        • 0
          Von Baldr am Di, 25. Oktober 2016 um 07:14 #

          Ich habe unter Lumina bisher keine Möglichkeit gefunden den Windowmanager auszutauschen. Weist du die eine Lösung?

          [
          | Versenden | Drucken ]
          • 0
            Von mgraesslin am Di, 25. Oktober 2016 um 09:00 #

            Unter der Annahme, dass Fluxbox das unterstuetzt: fenstermanager --replace

            [
            | Versenden | Drucken ]
            • 0
              Von kraileth am Di, 25. Oktober 2016 um 09:35 #

              Das klappt nach meiner Erfahrung nicht. Ich habe seit einiger Zeit TrueOS am Laufen, um die aktuelle Entwicklung zu verfolgen, habe aber Probleme mit Fluxbox (mein Terminalemulator Terminator z.B. bekommt aus unerfindlichen Gründen keine Fensterdekoration und läßt sich damit weder in der Größe verändern noch maximieren). Hatte versucht, stattdessen Sawfish zu verwenden, jedoch funktionierte „sawfish --replace“ nicht. Habe es dann auf die harte Tour gemacht: „sudo killall fluxbox“ und anschließend „sawfish &“. So kann man den WM austauschen - es hat aber (zumindest mit dem erwähnten Sawfish) Nebenwirkungen: Abmelden um den Benutzer zu wechseln geht nicht mehr und das sonst stabil laufende Insight crasht beim Öffnen bestimmter Verzeichnisse (habe allerdings keine Gemeinsamkeit dieser Verzeichnisse festgestellt). Ob Lumina mit kwin unproblematisch läuft, weiß ich nicht. Das wäre auszuprobieren.

              [
              | Versenden | Drucken ]
              0
              Von da-real-lala am Di, 25. Oktober 2016 um 13:54 #

              @Baldr, ich weiß da leider keine Lösung. Habe Lumina nie benutzt.

              @mgraesslin Aber wie soll das gehen, wenn es hier darum geht, Wayland zu benutzen?

              [
              | Versenden | Drucken ]
        0
        Von mnbvcxy am Mo, 24. Oktober 2016 um 21:06 #

        Man wollte ja von KDE weg, deshalb hat man überhaupt erst Lumina entwickelt. Da wird man nicht durch die Hintertür über KWin wieder zu KDE zurückkehren.

        Die freien Grafiktreiber sind unter den BSDs so schlecht, dass man mit den ganzen Grafikfeatures von KDE unter den BSDs nur sehr wenig anfangen kann.

        Alleine schon der Hinweis, dass man Lumina ohne Compositing betreiben kann, sollte hellhörig werden lassen.

        Zudem ist KDE Plasma auch schwer (da arbeitsintensiv) zu warten, der Upstream-Support für einzelne KDE-Versionen ist meist sehr kurz.

        [
        | Versenden | Drucken ]
        • 0
          Von mgraesslin am Mo, 24. Oktober 2016 um 21:14 #

          Lts mit zwei Jahren Support ist sehr kurz? Nun denn...

          [
          | Versenden | Drucken ]
          • 0
            Von mnbvcxy am Di, 25. Oktober 2016 um 21:31 #

            Ja, das ist es. Zum einen betrifft das nur vereinzelte Versionen, zum anderen ist KDE Plasma zur Zeit ja eher eine Art Rolling Release, weil man anders gar nicht den Bugs entkommen kann.

            Überdies ist zwei Jahre Support gemeinhin kein LTS, sondern STS.

            Nur in der KDE-Welt ist so etwas LTS.

            Schau Dir doch einmal die Relaität an, z.B. in RHEL.

            Würdest Du "Deinem" KDE3 in RHEL5 oder KDE 4.3.x in RHEL6 sicherheitstechnisch noch über den Weg trauen? Ich nicht, so kompetent in KDE-Belangen ist selbst Red Hat nicht. KDE 4 in RHEL7 steht schon jetzt dasselbe Schicksal bevor.

            Ähnlich war es mit KDE 4.1.x und KDE 4.3.x in SLES 11. In SLES 12 hat man deshalb KDE weggelassen, die Wartung von KDE über einen LTS-Zeitraum von zehn Jahren ist viel zu aufwendig.

            In Kurzzeit-Distros wie Opensuse Leap, die etwa ein Jahr alt werden, da kann man so etwas einsetzen. Da passt z.B. KDE PLasma 5 ganz hervorragend.

            [
            | Versenden | Drucken ]
          0
          Von Gameover am Mo, 24. Oktober 2016 um 21:53 #

          Lumina sieht ähnlich aus wie meine damaligen Hobbyversuche :/
          Ich habe mir mal vorhin in den Quellcode angeschaut, da tat sich kaum was . Ich will keine voreiligen Schlüsse ziehen, aber ich könnte mir denken, dass die nicht mehr lange durchhalten.Viele professionelle Kommentare sieht man im Code leider nicht.

          Die großen Linux Desktops ( u.a GNOME und KDE) bedienen sich hingegen immer mehr tiefer liegende Funktionen des Systems (Linux, Systemd, Wayland usw.) So wird ein portieren nach BSD immer Aufwändiger. Schließlich hat bisher BSD keinen eigenen Desktop, sondern müssen für sie ungeliebtes GPL-Zeugs verwenden.

          [
          | Versenden | Drucken ]
          • 0
            Von mgraesslin am Di, 25. Oktober 2016 um 08:40 #

            Die großen Linux Desktops ( u.a GNOME und KDE) bedienen sich hingegen immer mehr tiefer liegende Funktionen des Systems (Linux, Systemd, Wayland usw.) So wird ein portieren nach BSD immer Aufwändiger. Schließlich hat bisher BSD keinen eigenen Desktop, sondern müssen für sie ungeliebtes GPL-Zeugs verwenden

            So jetzt mein grosser BSD Rant. Das wäre alles kein Problem wenn die zusammenarbeiten würden und koordiniert die Software portieren würden. Stattdessen sitzt jeder in seiner Ecke und redet nicht mit den anderen. Da ist der Austausch der Linux Distros massiv besser. Stattdessen sehen wir dass die BSDs sogar auf die Idee kommen einen eigenen Desktop zu entwickeln, weil angeblich die Linux Desktops nicht portierbar sind. Da wird dann Entwicklungszeit verschwendet, die man zum Beispiel zum Portieren einsetzen könnte. Und dass man nicht portieren kann, ist ein hausgemachtes Problem der BSDs.

            Wie sieht denn so was in der Realität aus. Martin sendet Mail raus: "hey wir wollen jetzt libwayland einsetzen. In einem Jahr werden wir davon dependen. BSDs: ist das ein Problem für euch? Könnt ihr das schaffen?"

            Entweder es kommt dann keine Antwort oder sowas wie: "Ja macht nur, wir packetieren eh noch Qt 5, betrifft uns nicht".

            Zwei Jahre später, dann: "Buuuuuh, Linux ist so böse, jetzt dependen die auf Wayland und das ist nicht portierbar! Voll gemein, alles kaputt" - "Aber wir haben euch doch gefragt?!?" Ist so bei uns geschehen

            Anderer Fall aus Plasma. KWin dependet optional auf udev. Das ist optional um BSDs zu unterstützen. Vor Kurzem hab ich festgestellt, dass powerdevil hard auf udev dependet. Hey supper, BSDs können das jetzt, kann ich ja die optionale auf eine hard dependency ändern.

            Sichherheitshalber frag ich mal einen BSD Paketierer: "hey cool, seit wann habt ihr den udev?" - "Haben wir nicht" - "Aber wie baut ihr dann powerdevil?" - "Bauen wir nicht, haben wir disabled weil es auf udev dependet" - "Warum habt ihr das nicht gemeldet?" - "hmmm...."

            Das Problem der nicht Portierbarkeit ist haus gemacht. Wenn man nicht mal die Rückmeldung gibt, das was nicht mehr baut, braucht man sich nicht wundern, wenn immer mehr kaputt geht. Dann muss man halt einen eigenen Desktop schreiben, weil man nicht mit den Upstream Entwicklern spricht. Ist ok von mir aus.

            So an der Stelle noch der Hinweis, dass besonders aus dem FreeBSD Lager ich in letzter Zeit sehe, dass das besser wird. Da gibt es mittlerweile ein paar Entwickler, die bei uns auch regelmäßig nachfragen und die man erreichen kann. Inklusive Vortrag auf QtCon.

            [
            | Versenden | Drucken ]
            • 0
              Von dark am Di, 25. Oktober 2016 um 09:20 #

              Weil du Martin nach all den Jahren immer noch nicht verstanden hast, wie SW Entwicklung funktioniert. Wenn jemand seine Software voller Linuxismen spickt, dann kann man nicht damit werben ein UNIX-DE zu sein. Auch ist das nicht die Aufgabe der vielen Freiwilligen deinen Code und Bauanleitungen zu verstehen und passend für ihre Paketverwaltung zu bauen. Das mag für überschaubare Projekte ein paar Tage in Anspruch nehmen aber für KDE sind das oft Monate. Also mach den harten Schnitt, ertrage das Gejammere und nimm die Patches an die folgen werden. Alternativ schaue mal die Patches an die in den Ports stecken. Es kann auch nie schaden wenn SW mehr als nur eine Plattform unterstützt und man wenigstens den Bau getestet hat.

              Und mal ein Rant in eigenen Sache, liebe SW-Entwickler. Wenn ihr nicht das Wissen besitzt und das Interesse und ihr bekommt Patches, die eure Nutzerbasis vergrößern weil mehr Systeme unterstützt werden, dann nehmt das Geschenk an, statt rumzumosern ob es nicht einen allgemeineren Weg gibt oder man nicht auch gleich andere Systeme unterstützen kann. Ich mach die Arbeit für lau, in der Freizeit, selten habe ich Zeit ausgiebig zu testen. Getestet habe ich das für MEINE Plattform evtl. kann ich mal drüberschauen was andere BSDs an Patches noch rumliegen haben.

              [
              | Versenden | Drucken ]
              • 0
                Von luebking am Di, 25. Oktober 2016 um 09:47 #

                Korrektur, wie was läuft:

                Wer was will, macht es.
                Wer was nicht will, ersetzt es.
                Wer rumheult, läßt es besser ganz.

                Du willst A *und* B?
                Sieh zu, daß es läuft oder entscheide Dich.
                Beschweren darfst Du Dich, wenn Patches (ohne Qualitätsmängel) zurückgewiesen werden. Sonst nicht.

                /rant

                [
                | Versenden | Drucken ]
                • 0
                  Von dark am Di, 25. Oktober 2016 um 09:59 #

                  Danach müsste die KDE Entwickler Community ein wenig mehr tun als nix. Ich zitiere mal das Selbstverständnis von KDE[wikipedia]:

                  "KDE (/ˌkeɪdiːˈiː/) is an international free software community[1] producing free and libre software like Plasma Desktop, KDE Frameworks, and many cross-platform applications designed to run on modern Unix-like and Microsoft Windows systems. The Plasma Desktop is a desktop environment provided as the default work environment on many Linux distributions, such as openSUSE, Mageia, Kubuntu, and Manjaro Linux and is also the default desktop environment on PC-BSD, a BSD operating system.[2]"

                  Mir ist jedenfalls nicht bekannt, dass da irgendwo ein System bei den KDE Entwicklern existiert was nicht Linux ist.

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von mgraesslin am Di, 25. Oktober 2016 um 11:14 #

                    Auch hier mal ein Gegenbeispiel wo ich aktiv einen Linuxism entfernt habe, damit es unter BSD besser funktioniert: 73f110c7f

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von dark am Di, 25. Oktober 2016 um 17:18 #

                      Martin, ich empfehle dir, schnapp dir bei der nächsten Messe mal einen Paketierer aus dem BSD Umfeld und hör ihm zu wo die Schwerpunkte der Schmerzen bei KDE liegen. Das bei FreeBSD, gesponsert und mit einen großen Team vieles einfacher geht, leuchtet mir ein, die haben auch mit TrueOS eine große und professionelle Nutzerbasis.
                      Ich finde es nur erstaunlich, dass abseits davon so ein Projekt wie KDE mit zig Teilprojekten hunderte Patches in den Paketsystemen von Ports und Pkgsrc schlummern & geringe bis keine Aktivität von KDE-Leuten in den Mailinglisten stattfindet. Langfristig gesehen wird hier Lumina KDE den Rang ablaufen weil es hier wesentlich einfacher ist als Paketierer Schritt zu halten.

                      http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/x11/kdelibs4/patches/
                      http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/x11/kde4/libs/patches/

                      [
                      | Versenden | Drucken ]
                0
                Von mgraesslin am Di, 25. Oktober 2016 um 11:11 #

                Wenn jemand seine Software voller Linuxismen spickt, dann kann man nicht damit werben ein UNIX-DE zu sein.

                Niemand baut Linuxismen absichtlich ein. Das ist meistens Unwissenheit. Wenn ich was aus libc verwende, dann gehe ich mal nicht davon aus, dass das ein Linuxism ist, sondern auch unter BSDs kein Problem ist.

                Was kann man dagegen machen: CI! Haben wir, nur nicht fuer die BSDs, die es nicht schaffen uns das aufzusetzen. Ist nicht dass wir alle paar Monate darauf hinweisen. Aber was viel einfacher ist: Meckern, dass die boesen KDE Entwickler Linuxism einbauen.

                Wenn dir das oben nicht aufgefallen ist, wir fragen aktiv nach, bevor wir Aenderungen machen, insbesondere fuer die BSDs.

                Wenn ihr nicht das Wissen besitzt und das Interesse und ihr bekommt Patches, die eure Nutzerbasis vergrößern weil mehr Systeme unterstützt werden, dann nehmt das Geschenk an, statt rumzumosern ob es nicht einen allgemeineren Weg gibt oder man nicht auch gleich andere Systeme unterstützen kann.

                Nun, das machen wir ja. Ich koennte dir jetzt eine ganze Liste von Patches zeigen, die ich fuer die BSDs aufgenommen habe. Beispiel: 2ea5feb35b6703087f1a46eb83beb8126997e048

                Wie ich oben schrieb: das Problem ist hausgemacht durch fehlende Kommunikation. Wenn man nicht zurueckmeldet, dass was kaputt geht, kann man es nicht beheben. Wenn man nicht mal in der Lage ist ein CI einzurichten, dann kann man das auch automatisch nicht finden. Und dann kommen die falschen Annahmen dazu wie "ist nur fuer Linux", anstatt, dass man mal die Klappe aufmacht und sagt, dass funktioniert so nicht. Komisch, dass so etwas mit den Linux Distros immer funkioniert. Plasma verschiebt Release von Plasma 5.8 fuer OpenSUSE - kein Problem, weil man miteinander spricht.

                Wie gesagt mit FreeBSD wird das zur Zeit besser, siehe z.B. http://euroquis.nl/bobulate/?p=1518

                Aber von den TrueOS Leuten kam nie auch nur eine Rueckmeldung zu womit sie Probleme haben, als sie ihren eigenen Desktop gestartet haben. Mit der Erfahrung der Interaktion mit BSDs ueber die letzten Jahre muss ich davon ausgehen, dass sie das auch hauptsaechlich aus Unwissenheit gestartet haben.

                [
                | Versenden | Drucken ]
                • 0
                  Von holgerw am Di, 25. Oktober 2016 um 11:57 #

                  Hallo Martin,

                  das hatten wir schonmal.

                  KDE tritt mit dem Anspruch auf, ein DE für unixoide Systeme zu sein. Sorry, wenn ein Projekt aus diversen Entwicklerinnen und Entwicklern mit diesem Anspruch auftritt, dann haben sich einige Leute wenigstens auch zu bequemen, und etwa FreeBSD nativ auf die eigene Maschine zu installieren und darunter zu entwickeln und gerade der Hauptentwickler einer Kernkomponente wie kwin sollte das (nur unter Linux den Kram machen und bei FreeBSD sich lediglich auf Feedback von Leuten verlassen, da ist es ziemlich wahrscheinlich, das FreeBSD immer das Nachsehen hat). Manche Linuxismen würde so gar nicht entstehen, weil man auf einem*BSD schon als Entwickler sehen würde, dass es da klemmt.

                  Und FreeBSD aufzusetzen soll doch einfacher sein, als es oft behauptet wird, damit sollte ein SW Entwickler wohl nicht zeitmäßig überfordert sein, FreeBSD ist da sehr logisch aufgebaut und gut dokumentiert.

                  Ob etwas mit der Kommunikation zwischen BSD-Leuten und KDE-Entwicklern nicht stimmt, kann ich nicht beurteilen, aber nur einer Seite den schwarzen Peter zu zu schieben, ist meines Erachtens ein wenig zu einfach.

                  Viele Grüße,
                  Holger

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von mgraesslin am Di, 25. Oktober 2016 um 12:10 #

                    Klar man kann sagen, ich soll FreeBSD auf meinem System installieren und das testen. Dem halte ich entgegen, dass ich auch nicht fuer die Linux Distributionen teste. Weder habe ich OpenSUSE installiert, noch Gentoo, noch Ubuntu, Mageia, Fedora oder sonst was. Da funktioniert das alles mit dem Feedback. OpenSUSE kompiliert mit aelterem Compiler, halbe Stunde nach dem Commit kommt ein "Martin this breaks with gcc 4.x" - ich schau es mir an und behebe es. So sieht das mit jeder Linux Distribution aus, nur die BSDs bekommen das nicht hin.

                    In dem Punkt bekommen die BSDs von mir die gleiche Aufmerksamkeit wie die Linux Distributionen: sie werden alle gleich behandelt. Ich gehe keine extra Meile um da was zu testen. Die Zeit tausende von Distros zu testen hab ich nicht.

                    Ich glaube auch, dass das nicht im Interesse unserer Nutzer waere: die Zeit, die ich mich nur mit der Installation beschaeftige, koennte ich fuer sinnvolleres einsetzen.

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von holgerw am Di, 25. Oktober 2016 um 12:37 #

                      Martin,

                      das ließt sich: "Ich entwickle unter neutraler Plattform a" und Distributoren von Plattform b (GNU/Linux) liefern schön Feedback, aber von Plattform c (*BSD) kommt kaum was. Der Punkt ist, Du entwickelst schon nativ unter einem Linux. Ob das OpenSUSE, Debian, Arch oder was auch immer ist - und von einigen kleinen Unstimmigkeiten abgesehen passt dass, was Du unter Deiner Linuxinstallation entwickelsts, zu jedem anderen einigermaßen aktuellen Linux, alle haben udev, hald, sytemd u.s.f. auch und die meisten Rückmeldungen anderer GNU/Linux Distributoeren dürften weitaus häufiger mehr kosmetischer Natur sein. Kurz gesagt: Du musst als Entwickler auf einem nativen Linux gar nicht groß für verschiedene Linuxe testen.

                      FreeBSD als meisten verbreitetes BSD ist aber in einigen Punkten ganz anders, als GNU/Linux - und dann lese ich wieder den Anspruch, mit dem Euer Projekt auftritt.

                      Sorry, aber das ist wieder o.g. schwarzer Peter, der BSD zugeschoben werden soll und da sage ich Einspruch Euer Ehren.

                      Was Ihr macht, ist Eure Sache, aber Aspruch und Machen sollten im Groben wenigsten kompatibel zueinander sein. Und wenn ein Großteil der KDE-Leute sich regelrecht einem FreeBSD verweigern, als hole man sich damit die Cholera auf den Rechner - so liest sich das teilweise - dann ist KDE ein reines Linux DE, was mit Glück als Nebenprodukt auch unter FreeBSD läuft und sollte auch so auf Eurer Seite kommuniziert werden.

                      [
                      | Versenden | Drucken ]
                      • 0
                        Von mgraeslin am Di, 25. Oktober 2016 um 12:45 #

                        Wir haben mehrere Entwickler, die FreeBSD verwenden - so ist es ja nicht. Am bekanntesten duerfe Ade sein, dessen Blog ich ja schon oben verlinkt habe.

                        Ich hab ueber mich obendran gesprochen und nein, ich werde kein FreeBSD einsetzen. Ob ich FreeBSD einsetze oder nicht, hat nichts mit der Aussage zu tun, ob wir als Projekt nun BSD unterstuetzen oder nicht. Ich bin nur einer von hunderten Entwicklern.

                        [
                        | Versenden | Drucken ]
                        • 0
                          Von holgerw am Di, 25. Oktober 2016 um 13:20 #

                          Martin, aber Du bist als Entwickler von kwin einer der Kernentwickler. Und in der Zeit, in der Du hier ein paar Kommentare schreibst, ist neben GNU/Linux ein FreeBSD aufgesetzt samt xorg und Werkzeugen - in Tagen von DSL kein großer Zeitaufwand, und auch kein Hexenwerk, wenn ich als ambitionierter Anwender das in 15 Minuten hinbekomme, dürfte das für Dich ein Klacks sein. Diese "keine Zeit für sowas haben" oder "zu kompliziert" nehme ich Dir deshalb nicht ab, weil ich Dich da für viel zu kompetent halte.

                          Du schreibst: "[...]Wir haben mehrere Entwickler, die FreeBSD verwenden - so ist es ja nicht. Am bekanntesten duerfe Ade sein, dessen Blog ich ja schon oben verlinkt habe.[...]"

                          Gut, mir ist nur dann nicht so recht klar, wo nun die Kommunikationsprobleme liegen, die Du angesprochen hast. Liegen sie innerhalb des KDE-Projektes zwischen Leuten, die unter FreeBSD entwickeln und Leuten, die unter GNU/Linux entwickeln oder zwischen KDE-Projekt und BSD-Distributoren?

                          Zur Klarstellung: Dieses Bohren hier von mir hat damit zu tun, dass ich mich für Euer DE einfach am meisten im positven Sinn interessiere. Ich will Dich damit weder ärgern (und denke, Du weißt das auch, sonst würdest Du wohl kaum so detailliert antworten), noch die BSD-Seite als makellos hochstilisieren, ich finde es nur schade, wenn Kritik sehr einseitig immer nur auf ein Projekt gerichtet ist.

                          Und KDE, Plasma5 / kf5 sind meine Favoriten - auch unter FreeBSD, ich habe mich schon vor Wochen in die Mailingliste des FreeBSD-KDE Projektes eingetragen, neulich schon mal aus area51 ein Plasma5 samt kf5 unter FreeBSD gebaut und ans Laufen bekommen. Gerade Leute wie Tobias Berner sind sehr engagiert, was "KDE5" auf FreeBSD betrifft.

                          Na ja, mal abwarten, wann Plasma5 in den offiziellen Ports ist.

                          [
                          | Versenden | Drucken ]
                          • 0
                            Von mgraesslin am Di, 25. Oktober 2016 um 14:08 #

                            Martin, aber Du bist als Entwickler von kwin einer der Kernentwickler.

                            Ja, und? Die NVIDIA Nutzer hätten gerne, dass ich mit ihrer Hardware und prop und freiem Treiber teste. Die AMD Nutzer hätten gerne, dass ich mit admgpu und radeon teste, die Intel Nutzer hätten gerne, dass ich mit Sandybridge, Ivybridge Haswell und schlagmichtodbridge teste. Und die BSD Nutzer hätten gerne noch, dass ich mit BSD teste (natürlich in gleicher Hardware Combo). Irgendwann ist man dann aber nur noch am Testen. Ich bin wie du richtig feststellst einer der Kernentwickler und nicht das QA Departement.

                            Und in der Zeit, in der Du hier ein paar Kommentare schreibst, ist neben GNU/Linux ein FreeBSD aufgesetzt samt xorg und Werkzeugen

                            Ich kommentiere hier, wenn ich gerade z.B. mal code compiliere und mein System ausgelastet ist. Nein, das ist nicht parallelisierbar.

                            Gut, mir ist nur dann nicht so recht klar, wo nun die Kommunikationsprobleme liegen, die Du angesprochen hast

                            Nun das hab ich ja schon gesagt. Die Kommunikation zwischen den verschiedenen BSDs funktioniert nicht. Das bestätigt dir auch jeder BSD Entwickler. Dadurch wird viel Entwicklungsarbeit verschwendet, da immer wieder die gleichen Probleme gelöst werden, anstatt das man zusammenarbeitet. Das ist nicht nur bei KDE Software so, sondern im kompletten Stack. Siehe DRM, etc. etc.

                            Dazu kommt, dass die Kommunikation zwischen BSDs und Upstream oft nicht funktioniert. Das ist so in der Art wir rufen in den Raum rein "Hallo jemand da!" und es kommt nichts zurück. Wie gesagt mit FreeBSD ist das im letzten halben Jahr signifikant besser geworden. Und natürlich bekommen wir oft nicht zurückgemeldet das etwas nicht funktioniert. Wie die powerdevil+udev Geschichte. Das ist was mit schlechter Kommunikation gemeint ist. Wir können nur Probleme beheben, die uns gemeldet werden.

                            Von den BSDs, welche nicht FreeBSD sind, hab ich in den letzten Jahren auf keine meiner Fragen eine Antwort bekommen. Warum? Keine Ahnung. Mehr machen als aktiv fragen, können wir kaum.

                            [
                            | Versenden | Drucken ]
                            • 0
                              Von holgerw am Di, 25. Oktober 2016 um 15:12 #

                              Oh weia:

                              Dein Beispiel powerdevil+udev kann nicht funktionieren, warum wohl nicht? Es ist simpelstes Grundwissen, dass FreeBSD kein udev hat, noch jemals hatte. Wenn es seitens des KDE-Projektes beim Wissen um solchen Basics schon scheitert, würde ich mir als Entwickler bei FreeBSD veralbert vorkommen.

                              Es mag unter anderem an Kommunikationsschwierigkeiten liegen, das glaube ich Dir auch, Martin. Dein Beispiel zeigt mir aber, dass es neben Kommunikation an etwas ganz anderem hapert, u.z. einem Mangel an Grundwissen zu Unix/BSD. powerdevil+udev ist ein gutes Beispiel für diesen Mangel, Ihr wollt Rückmeldung zu einer Sache, die ein eindeutiger Hinweis auf Unwissenheit qua Ignoranz gegenüber Basics ist, tretet aber mit dem Anspruch auf:
                              "For users on Linux and Unix, KDE offers a full suite of user workspace applications which allow interaction with these operating systems in a modern, graphical user interface."

                              Ich finde das Schade.

                              [
                              | Versenden | Drucken ]
                              • 0
                                Von mgraesslin am Di, 25. Oktober 2016 um 15:48 #

                                Es ist simpelstes Grundwissen, dass FreeBSD kein udev hat, noch jemals hatte.

                                Kann ich so nicht unterschreiben. Nur weil FreeBSD kein udev hatte, heisst es nicht, dass es auch immer so sein muss. FreeBSD hatte auch mal kein DRM, hat es nun. Ich war vor kurzem sehr ueberrascht, dass FreeBSD sogar linux/input.h hat. Also daher: nein, kann man nicht davon ausgehen.

                                Ausserdem: Fehler passieren. Sowas passiert ja nicht mit Absicht. Hei komm, wir machen das mal Linux only. Nein, das sind Fehler. Und dann braucht man die Rueckmeldung. Wenn dann die BSDler beleidigte Leberwurst machen, wie du das gerade darstellt, statt einfach mal zu sagen: hey ihr habt das gerade kaputt gemacht, dann wird das halt nichts.

                                Ganz klar: der Fehler mit udev war auf unserer Seite. Dass der Fehler uns gegenueber nicht kommuniziert wurde, ist auf BSDs Seite.

                                [
                                | Versenden | Drucken ]
              0
              Von Anonymous am Di, 25. Oktober 2016 um 11:03 #

              So jetzt mein grosser BSD Rant. Das wäre alles kein Problem wenn die zusammenarbeiten würden und koordiniert die Software portieren würden. Stattdessen sitzt jeder in seiner Ecke und redet nicht mit den anderen.

              Sagt einer, dessen Projekt sich in 3 Subprojekte gespalten hat, damit man möglichst wenig miteinander reden muss. Nicht mal auf ein einheitliches Versionierungsschema haben sich die Subprojekte geeinigt; das spricht doch Bände.

              [
              | Versenden | Drucken ]
              • 0
                Von Kay am Di, 25. Oktober 2016 um 14:32 #

                Wäre mir jetzt neu, dass sich "Martin's Projekt" in 3 Teile gespalten hat. Zumindest hab ich noch nix von mehreren Kwins gehört. :huh:

                Du meinst bestimmt die Aufteilung von KDE in Applications, Framework und Plasma, oder? Falls ja, dann zeigt die Erwähnung im aktuellen Kontext, dass du nicht wirklich verstanden hast (hast du die Begründung überhaupt gelesen? Oder haust du nur ein paar Schulhof-Parolen raus?), warum dies passiert ist. Gerade bei der Zusammenarbeit von so vielen Beteiligten, macht das Sinn, denn gerade so kann man miteinander sprechen und blockiert nicht die Arbeit des anderen, da ja immerhin die drei Dinge eine jeweils andere Ausrichtung haben.

                Nun ja, scheint ja zu klappen, ne?

                [
                | Versenden | Drucken ]
                • 1
                  Von Anonymous am Mi, 26. Oktober 2016 um 12:16 #

                  Meines Wissens hat Martin schon vor der Aufteilung in 3 Subprojekte an KDE mitgearbeitet.

                  Und zum Kontext: die 3 KDE-Subprojekte hatten sich ebenfalls in 3 Ecken zurückgezogen, werkelten vor sich hin und überliessen es den Distributionen, aus den unterschiedlichen Versionsständen der 3 Software-Haufen was funktionierendes zusammenzustellen.

                  Da das nicht besonders gut geklappt hat (was freilich voraussehbar war),rudern sie nun wieder ein Stück in die Gegenrichtung.

                  [
                  | Versenden | Drucken ]
                  0
                  Von krake am Mi, 26. Oktober 2016 um 22:25 #

                  Du meinst bestimmt die Aufteilung von KDE in Applications, Framework und Plasma, oder?

                  Denke ich nicht, das würde keinen Sinn ergeben.

                  Sowohl Frameworks als auch Applications sind Produktkategorien und bestehen aus duzenden Projekten.

                  [
                  | Versenden | Drucken ]
                0
                Von krake am Mi, 26. Oktober 2016 um 22:18 #

                dessen Projekt sich in 3 Subprojekte gespalten hat

                Welche drei Subprojekte?

                Das kwindowsystems Framework, kwin_x11 und kwin_wayland?

                Nicht mal auf ein einheitliches Versionierungsschema haben sich die Subprojekte geeinigt; das spricht doch Bände.

                Die Anwendung KWin ist nicht der einzige Benutzer des KWindowSystems Frameworks, es macht schon Sinn, letzteres öfter zu veröffentlichen, damit andere Programme nicht an KWin's Zyklus gebunden sind.

                Und ja, es spricht Bände, dass man gegenüber den Bedürfnissen anderer Entwickler aufgeschlossen ist und ihnen bei der Freigabe neuer Funktionalität oder Verbesserungen entgegen kommt.

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