Wayland 1.4 i Weston 1.4 z obsługą protokołu sub-surface

Prędzej doczekamy się działającego Mira od Canonicala, aniżeli Waylanda na jakimkolwiek urządzeniu, czy tym bardziej desktopie.

A co jest w Jolla?

Niby jest ten Wayland, ale korzysta ze sterowników Androida, a nie swoich. Więc żaden to w pełni działający serwer wyświetlania :)

Nie niby, tylko zwykły działający Wayland.
I nie ma żadnych specjalnych sterowników dla Wyalanda, są tylko EGL (takie same dla Wyalanda i Mira) lub androidowe (również takie same dla Wyalanda i Mira).

Normalny Wayland wymaga od kompozytora rozmów ioctrl z kms, przez co androidowe sterowniki czy sterowniki EGL Mira nie będą działać poza tymi które z KMS korzystają (a robią to otwarte sterowniki, bo inne mają KMS w poważaniu i piszą własne UMS). W Jolla Carsten Munk zmodyfikowal wayland aby to głupie założenie, które sięga początków waylanda i z którym rozstać się twórcy nie mogą olać i umożliwić normalne działanie ze sterownikami.

Mylisz Waylanda z Westonem.

Nie mylę. Kompozytor Weston jak i inne tak się komunikują, ale to nie jest ich wymysł tylko Wayland wymaga od kompozytora takiego zachowania… dlatego przymus KMS masz w E19, Weston, Mutter, KWin i dopiero zmiana Waylanda pozwoliła w Jolli wyeliminować to.

Co to za farmazony?

SailfishOS, Mir i Wayland używają z tej samej biblioteki libhybris, umożliwiającej korzystanie z tych samych sterowników z Androida.

Z tym KMS to również brednie:
http://phoronix.com/forums/showthread.php?81192-The-Wayland-Situation-Facts-About-X-vs-Wayland&s=2eda534d28b2baf7e605c2837c73e437&p=350436#post350436

http://www.reddit.com/r/linux/comments/1nq2ck/nvidia_beta_driver_33113_supports_egl_api/

Nvidia już pracuje nad jednym, uniwersalnym sterownikiem EGL dla Waylanda i Mira.

Mir i SailfishOS podobnie jak Wayland korzystają z libhybris i mogą korzystać ze sterowników Androida, ale jest taka różnica, że Wayland może korzystać tylko z tych sterowników na Androida, które korzystają z KMS, a Mir i SailfishOS nie muszą (Mir z założenia, a SailfishOS dzięki pracy Munk’a).

Co do linków to na reddit masz podstawowy błąd – sterowniki podane nie działają ani na Mir, ani na Wayland (to jedynie myślenie życzeniowe autora), a jedynie z X11 i to w wersji 32bit. Nvidia robi uniwersalny sterownik EGL dla Androida/Linuksa, ale taki działać nie będzie z Waylandem… przynajmniej do czasu kiedy zrezygnują z wymagania od kompozytora uzależnienia się od KMS jak to jest obecnie.

Co do Phoronixa to podałeś post człowieka który po prostu nie ma pojęcia o czym pisze.

„Because that’s the only sane place for this code, the nvidia and amd
proprietary drivers also place their modesetting code inside the kernel.
(in their proprietary kernel modules)”

Autor postu zapewne nigdy nie rozpakowywał instalatora i nie widział kodu modułów AMD/Nvidia do jądra, a są one bardzo proste i nie zawierają modułów modesetting – jedynie są pośrednikiem dla zamkniętych sterowników działających w userlandzie – w zamkniętych sterownikach stosuje się user-space mode-setting (UMS), a nie Kernel mode-setting. Zapewne pan piszący ten post nawet nie zna przyczyny tego czyli licencji jądra – wszystko co jest w przestrzeni jądra musi być na licencji GPL, przez co zamknięte sterowniki muszą działać w przestrzeni użytkownika.

Wayland obecnie eliminuje możliwość stosowania zamkniętych sterowników. Dopóki twórcy nie przestaną strzelać focha na to, że ich pomysł aby wszystkie sterowniki zmusić do KMS upadł zanim powstał i zamknięte sterowniki nie będą tak działać pod Linuksem i przyjmą modyfikacje Jolli + przepisane zostaną wszystkie istniejące już kompozytory waylanda (na których wymusił wymaganie KMS) nie będziesz się mógł cieszyć zamkniętymi sterownikami (zarówno desktopowymi jak i androidowymi).

A nie da się, po prostu zmergować zmian z sailfisha?

da się, ale trzeba chcieć. Niestety niektórzy szczytne idee przedkładają ponad funkcjonalność.

Da się i będzie to piękny dzień kiedy programiści z red hata posłuchają tego czego chcą firmy i użytkownicy (a nie czego chce stallman i inni fanatycy) i przyjmą poprawki.

A gdyby tak spróbować zbudować forka waylanda z sailfish na poczciwym PC? Działałoby to?

Przecież napisałem że to wstępny sterownik dla EGL, a nie dla Waylanda czy Mira.

Sterowniki zamknięte też korzystają mode-setting, ale z UMS.
Uczepiłeś się tego wymaganego KMS, a to jakiś wymysł twojej wyobraźni.
A z tym libhybris to zwykły bełkot.
W SailfishOS jest ten sam Wayland i to samo libhybris.

Nie czaruj rzeczywistości. Środowisko jasno się opiera przed zamkniętymi sterownikami. To, że jeden zespół napisał nie znaczy, że wszyscy zaraz przyjmą.

Tak samo jak historia z LLVM. Apple chciało go dołączyć do GCC, na licencji GPL, ale FSF płakało, że to w C++ i że sami nie wymyślili i że modułowość jest fe.

SteamOS to Debian, w którym będzie Wayland i zamknięte sterowniki EGL. Cały wasz komentarzowy bełkot jest nieistotny.
Na szczęście osoby, od których coś należy są bardziej kompetentni.

Skąd ta bajka o SteamOS i Wayland? SteamOS to zmodyfikowany Debian, ale obecnie nie planują nawet przejścia z Xów na cokolwiek innego, a jeśli to za te 3-4 lata zdecydują czy Mir czy Wayland (jeśli twórcy waylanda przestaną walczyć o nierealne rzeczy to możliwe, że go wybiorą (tak samo możliwe wtedy, że Ubuntu zrezygnuje z Mir)).

Debian będzie miał Wyalanda i sterowniki EGL.
Debian to najbardziej stallmanowska dystrybucja (z tych wiodących), która wywaliła nawet niewolny firmware z jądra do innego (domyślnie wyłączonego) repozytorium z niewolnym oprogramowaniem.

Jakoś dla Valve to żaden kłopot, dla komentarzowych mędrców zaś to wręcz widmo niekończących się problemów.
Dziwne, że wybrali tego dziadowskiego Debiana zamiast postępowego Ubuntu ze swoimi genialnymi rozwiązaniami ;)

Debian obecnie nie ma planów nawet na porzucanie Xów (jedyną firmą zainteresowaną tym jest RedHat (bo on wydaje kasę na waylanda i jego pracownicy go piszą) i pierwszą dystrybucją z Waylandem będzie Fedora… drugą dystrybucją zainteresowaną było Ubuntu, ale ze względu na upór redhatowców postanowili stworzyć Mir) i zapewne przez 5 lat kolejnych tego nie zrobi. Debian jest odległy od stallmanowskiego wzoru (dlatego jest stosunkowo popularny, bo stallmanowski ideał to koszmar użytkowników). Sterowniki EGL już ma (tak jak i wszystkie inne dystrybucje w których zainstalujesz EGL z mesa, sterowniki Nvidii czy SDK AMD (bądź inne zamknięte implementacje EGL GPU mobinych)).

Dla Valve to żaden kłopot oprzeć swoją dystybucję na Debianie i pozostac przy Xach i swoim kompozytorze przez kolejne 5 lat, a ostatecznie przejść na Mir czy Waylanda (co będzie zupełnie niezależnym od debiana wyborem… a i nie wiadomo którego z nich Debian wybierze (tak samo jak teraz trwa debata w środowisku Debiana, czy użyć systemd od RedHata (i programisty który obecnie tworzy waylanda) czy jednak Upstart… a może pozostać przy skryptach startowych) – nie jest to łatwy wybór, bo systemd z jednej strony ssie i jest najgorszym wyborem, a z drugiej strony RedHat uzależnił rynek od tego rozwiązania (zabijając udev jako osobny projekt i integrując z systemd itp.) i opieranie się systemd wymaga dużo pracy (a nawet twórca Slackware uważa, że jeśli tak dalej pójdzie to nawet oni będą zmuszeni do przejścia na ten słaby, ale mocno wspierany projekt przez RedHata który kontroluje rozwój ważniejszych części systemu)).

Debian ma już Wyalanda i Westona w repozytorium.
Zaczyna być już powiązany z mesą, mplayerem etc.
Wszystkie wiodące dystrybucje przechodzą powoli na Waylanda, Ubuntu zaś na Mira.
Całe twoje wywody to tylko domysły, a czasem i brednie, często nie na temat, komentarzowego mędrca z osworld. pl.

Debian ma waylanda i westona (podobnie jak ma systemd w repozytorium od 2ch lat i jest prowadzona mocna dyskusja czy chcą go bo RH wymusił czy wolą inne rozwiązanie lepsze techniczne, ale trudniejsze w utrzymaniu) w repozytorium jak większość dystrybucji łącznie z Ubuntu – większość z tych dystrybucji nie zamierza zmieniać Xów na Waylanda, a Ubuntu postanowiło wejść w Mir, co nie zmienia faktu. Debian NIE PLANUJE wykorzystania waylanda, a musi po prostu go mieć, bo RedHat robi nieładną grę w postaci zagrywek monopolistycznych uzależniania od swojego rozwiązania (a ze względu, że to oni „posiadają” freedesktop.org mogą zmuszać innych do wyboru ich produktu, a odrzucać wszystkie łatki, które pochodzą od konkurencji). Wayland i weston mogą być w debianie przez nawet 10 lat i to w żaden sposób nie oznacza, że będzie on kiedykolwiek serwerem wyświetlania debiana (podobnie jak w ubuntu będzie przez lata siedział przez zagrywki RedHata, ale z niego nie skorzystają).

Całe twoje wywody to domysły typu RH wymusił włączenie przez wszystkich do pakietów swojego serwera, to wszyscy muszą na niego przejść, a jest to bzdurny tok myślenia – twórcy wielu dystrybucji, a szczególnie takich jak Slackware/Debian/Gentoo bardzo mocno sprzeciwiają się naciskom ze strony RedHata i nie są do nich pozytywnie nastawione, bo RedHat zamiast walczyć jakością rozwiązania chce walczyć swoją pozycją do przymuszenia do swojego rozwiązania niezależnie jakie by ono nie było.

„czy chcą go bo RH wymusił czy wolą inne rozwiązanie lepsze techniczne, ale trudniejsze w utrzymaniu”

Właśnie dlatego nie lubię tego twojego bełkotu. Jakie rozwiązania są lepsze od systemd? Upstart – wolne żarty. OpenRC – to tylko sysVinit na sterydach.

Sytuacja wygląda tak, że może i systemd jest inwazyjny i mało POSIX’owy
ale to najlepszy (pod względem również technicznym) wybór z aktualnie możliwych.

Zresztą dzisiaj na listach debiana rozpoczęło się głosowanie i jak na razie na prowadzeniu jest właśnie systemd.

https://lists.debian.org/debian-ctte/2014/01/msg00425.html

Wszystkie rozwiązania są lepsze od systemd! Systemd praktycznie nie ma zalet. Projektanci olali zupełnie regułę KISS, napisali projekt tak, że naprawdę ciężko później debuggować start systemu (jedyny ciężki do debuggowania init, a to jest wada wręcz dyskwalifikująca)… zrobili masę nikomu niepotrzebnych w inicie rzeczy, ale o takich podstawowych rzeczach jak rozszerzanie skryptów startowych czy takie, które wykonują kilka podskryptów to już nie.

Upstart lepszy? Jasne – łatwo debugować, łatwo pisać, łatwo rozszerzać i mniej więcej reguła KISS została zachowana. OpenRC/sysVinit też są lepsze jako initd (dlatego Debian/Gentoo się tak długo opierały, a Slackware dalej się opiera przed zmianą).

Ogólnie dyskusja na temat zmian init w Debianie nie jest prowadzona ze względu na faktyczną chęć zmiany, a jest to efekt tego o czym mówi też twórca Slackware Patrick Volkerding czyli tym, że już wszyscy poza RH są zmęczeni forkowaniem projektów którymi RH zarządza i prędzej czy później zostaną przymuszeni do zmiany. Debian wybiera więc pomiędzy upstart (w którego utrzymaniu pomoże Ubuntu) i systemd, który niekoniecznie się twórcom podoba (poczytaj listę dyskusyjną), ale nie trzeba będzie forkować nic i liczyć na współpracę z Ubuntu.

Prawdopodobnie systemd zostanie wybrany dla Debiana ze względu na mniejszą ilość pracy tworzeniem dystrybucji (forkowanie udev innych projektów) i zrezygnują w ten sposób z rozwoju Debian/Hurd i Debian/kFreeBSD.

Nie ma rozwiązań idealnych, jednak systemd jest najmniejszym złem. W dobie kiedy zdecydowana większość konkurencyjnych dla debiana graczy go używa. I kiedy pozwala on na kilkukrotne przyspieszenie startu systemu.
Do tego nie ma wygodniejszej rzeczy niż systemctl jeśli chodzi o zarządzanie daemonani.

PS. Mam nadzieje że nie będą się w decyzji kierowali użytkownikami innych niż linux, hipsterskich kerneli (których jest łącznie dziesięciu).

Nie ma rozwiązań idealnych, a systemd jest największym złem (poza tym, że nie będą musieli podobnie jak Slackware czy Gentoo forkować wszystkiego co od RH wyszło).

„W dobie kiedy zdecydowana większość konkurencyjnych dla debiana graczy go używa”
Trochę przesadziłeś. W rodzinie debianowatych praktycznie Systemd się nie używa, a spotyka się tylko sysVinit i upstart (Ubuntowate, elementary OS czy Mint). Wśród dystrybucji takich jak Slackware, Debian, Gentoo itp też będzie Ci ciężko systemd odszukać. Systemd jest popularny w postredhatowych dystrybucjach (tych które pochodzą od RedHata i dalej się za nimi ciągną czyli dystrybucje które pakiety mają RPM (Red Hat Package Manager) czyli Mageia, Fedora, openSUSE (ta jako jedyna nie wywodzi się z RH w linii prostej, ale jeszcze w poprzednim wieku się związała mocno z nim rozwojowo))… poza „własnym podwórkiem” RedHata wśród popularnych dystrybucji jest tylko w Arch Linux i Manjaro (oparta na archu)… upstart poza swoim podwórkiem jest jeszcze używany w Google ChromeOS i HP WebOS.
Zdecydowana większość jak to powiedziałeś jest dużą przesadą, a rozkłada się to mniej więcej tak, że pochodne Debiana korzystają z Upstart, a pochodne RedHata używają Systemd.

Systemctl jest raczej średnio wygodne… skrypty są dla mnie o niebo przyjaźniejsze, a sam systemctl daje mniej więcej ten sam poziom wygody co narzędzia upstartowe (start, stop, status, initctl).

Najbardziej widoczna wada konstrukcyjna Upstart’a to to że ładuje wszystko co jest w katalogu /etc/init. Nie ma prostego sposobu na wyłączenie skryptu z użycia. Nie ma czegoś takiego jak systemctl enable|disable . Trzeba stosować override’y (echo 'manual’ > /etc/init/.override).

Załóżmy że jakiś pakiet A (np. connman) zależy od pakietu B (np. bluez). Instalując connmana, bluez ładuje swojego daemona do /etc/init i przez to automatycznie się ładuje. Chociaż nikt go o to nie prosił. W systemd nic się automatycznie nie ładuje. To tylko jedna z wielu wad w zaprojektowaniu Upstarta (samo jego działanie w porównaniu do systemd to również śmiech). To dlatego RH wolał wystartować własny projekt niż łatać tę popierdułkę.

Linki, że „FSF płakało, że to w C++ i że sami nie wymyślili i że modułowość jest fe”
Nie linkuj postu z Phoronixa, bo tam nic nie ma.

Każdy sterownik graficzny musi korzystać z mode-setting (nie istnieją sterowniki, które tego nie robią, bo po prostu muszą), tylko różnica KMS i UMS w tym wypadku jest znacząca. Wymaganie KMS to nie wyobraźnia a znajomość tematu… ofc już nie jest tak źle jak kiedyś (początkowo wayland sam wymagał KMS, a obecnie zmusza kompozytor sam jednak nie wymagając (wymaga teraz jedynie pośrednio)), jednak prawda jest taka, że bez zmian w Waylandzie (które ostatecznie nastąpią, bo na warunki stawiane przez programistów RH nikt się nie zgodzi) się nie obejdzie.
W SailfishOS jest nie ten sam Wayland, a zmodyfikowany.

Gdy wyjdzie KDE workspaces 5.