Mir 0.1.2

Rozumiem, że różnica w użytych językach programowania nie jest tu problemem :D

Zapraszam do przeczytania sekcji "Software architecture": http://en.wikipedia.org/wiki/Mir_%28software%29

Wiem, że to tylko Wikipedia, ale są podane źródła informacji. Nikt nie robi serwera wyświetlania od zera w tak krótkim czasie przy użyciu garstki programistów.

I co tam można przeczytać, że wzięli serwer X i dopisali do niego backend Mira, tak samo jak zrobił to Wayland?
I to jest ten cały kod Waylanda?

Gdzie tam wyczytałeś, że Mir opiera się o kod Wayland? Problem w tym, że gdyby deweloperzy Canonical umieli czytać kod Waylanda, to nie powstałby Mir tylko dopisaliby to czego potrzebują. ;)
A tak to sami go napisali, użyli tylko kodu XWayland do XMir, a patrząc na wczesną wersję według numerka i fakt, że Mir nie pojawi się w 14.04 to wygląda, że daleko mu do końca.

Z drugiej strony opieranie się na C w dzisiejszych czasach to spora katastrofa (Nawet GCC nie wytrzymało).
Zresztą system okienkowy na własne potrzeby, zespół opłacanych ludzi napisałby wydajniej.

Jak się patrzy na takie statystyki jak na Tiobe to wygląda, że C trzyma się mocno. Widocznie wielu programistów nie widzi potrzeby uczyć się C++. Swoją drogą mają powód, gdyby C++ wyglądał jak Vala nie było by takiego oporu :-)

C przeżywa teraz renesans, przynajmniej na rynku pracy. Model obiektowy w c++ na pewno nie spełnia wymagań XXI wieku. Lepiej używać C niż się bawić w te obleśne hacki jakie dodali w c++11.

Linus Torvalds dobitnie się wypowiedział na ten temat
http://thread.gmane.org/gmane.comp.version-contro…

"I've come to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with."

Pozdro dla wszystkich którzy tak się jarają przewagą c++ w QT4 nad składnią c w GTK2

To nie jest kwestia "jarania się" (cóż za argumenty), tylko doboru właściwego narzędzia do zadania. Interfejs graficzny to obiekty, więc GTK- to błąd u samych założeń, i zresztą "naprawiany" licznymi hackami jak GObject. GTK- samo siebie wyśmiewa.

Co do zacytowanej wypowiedzi: jak wyżej. Jeśli projekt nie wymaga C++, to OK, nikt nie powinien na siłę go używać. Jeśli projektowo jest to właściwy wybór (obiektowość), to wtedy trzeba być idiotą by użyć C (tak jak programiści GTK- i Gnome).

Whatever, jeśli uważasz że c++ jest właściwym językiem do programowania interfejsu to jesteś trochę ograniczony.

Interface wymaga wręcz programowania obiektowego i język C++ jest tu idealny. Do pisania jądra systemu C++ nie bardzo się nadaje, bo tu wydajność ponad wszystko i wirtualne klasy z narzutem na wyszukiwanie wskaźnika na metode w vtable jest nie do przyjęcia, to w wielu innych programach jest to wręcz przymus projektowy. Właśnie dlatego, wspomniane GTK w języku C dodała obiektywność za pomocą GObject… i przejeła wszystko to czego nie lubi Linus w C++, z wielokrotnie większym narzutem niż ma czyste C++. Wybór języka C do GTK i próba rekompensowania sobie tego implementując ręcznie to co ma C++, z dużo gorszym efektem niż robią to kompilatory jest największym błędem projektowym o jakim słyszał świat.

"programowania interfejsu"?
Chodzi ci o opis layoutu i obsługę zdarzeń? To nie.
Jeśli chodzi o programowanie biblioteki GUI, takiej jak Qt czy GTK-, to obiektowość jest tu wręcz niezbędna i C++ nadaje się idealnie: obiektowe i bardzo szybkie.

A sorry nie popatrzyłem na nick, gdybym wcześniej ogarnął kto to napisał to bym nawet nie odpowiadał

Ej, ale C++ nie wymusza pisania klas. Ma za to bardzo wydajne elementy jak Vector i wydajne implementacje oparte na porównaniach. Jak się nie nadużywa virtual, to wszystko idzie świetnie.
Nie wspominając już o szablonach w STD::, które ładnie kompilują się do kodu natywnego.

Co mamy w zamian w C? Cale cache zamiast wypełniać danymi, wypełniamy wskaźnikami na wskaźniki ;-)

> Co mamy w zamian w C?

Mały język z czystą składnią. Ani jednego ani drugiego nie można powiedzieć o jego rozszerzeniu.

Jak robisz wydajne kontenery i struktury drzewiaste w tej czystej składni? Nie wspominając o stringach.
To ja już wolę JS. Bo jego prostota idzie w parze z elastycznością.

Pyknij im tam petycje żeby przepisali Waylanda do Javascriptu ;)). A tak na poważnie to, do pewnego stopnia nie chodzi w wyborze języka o to który więcej potrafi, tylko który nie powoduje ostrego krwawienia z oczu.

Albo raczej powoduje mniejsze krwawienie w tym przypadku.

Wydajne kontenery i struktury drzewiaste ja piszę właśnie w C… co prawda dla wygodniejszego wykorzystywania przeciążam operatory, ale tu nie ma żadnego narzutu dodatkowego, ale funkcje z 2ma argumentami czyli wskaźniki struktur, będą tak samo wydajne… C++ nie ma tu, żadnej zalety wydajnościowej… poza tym, że jest dużo wygodniejsze.

Język C jest świetny, jednak C++ nie jest dużo bardziej skomplikowanym językiem… ba jest to po prostu nakładka na czyste C, dodająca kilka możliwości (których nie musisz użyć i będzie to dalej czyste C), które przy rozwoju aplikacji są bardzo pomocne… OFC można świadomie z nich zrezygnować, i troszkę się pomęczyć, ale mieć większą wydajność… jednak rezygnowanie z C++ dla C, aby napisać ręcznie koślawe protezy obiektywności działające dużo wolniej niż w C++ to już jest po prostu idiotyzm.

Coś za coś, oba toolkity używają podobne ilości ramu i mocy obliczeniowej, więc jak widać narzut nie jest problemem.

GTK (podkreślmy że chodzi o wersję drugą) jednak biblioteką nie zmuszająca programisty do pójścia jedną dobrą drogą (nie pakuje się nieproszona w drogę), obyło się bez dodatkowych kompilatorów (skoro cpp jest taki świetny to po co stosować kompilator metaobiektów, czyżby żeby przykryć jego wady?) a do tego ma o wiele większą skalowalność, czego dowodem są bindingi do prawie wszystkich dostępnych języków programowania.

Qt ma dużo większe możliwości, jest łatwiejszy w użyciu, a wymaga mniejszej mocy obliczeniowej (dopiero KDELibs niezależne od Qt wymagają większej mocy).

GTK2 opiera się w całości o GObject i nie masz możliwości iść inną drogą niż obiektową.
"Kompilacja" metaobiektów ciężko nazwać kompilacją (prędzej preprocesorem tekstu), bo jest to po prostu przetwarzanie tekstu na tekst. Język C i C++ nie mają czegoś takiego jak sloty i sygnały, a pisanie tego ręcznie przez programistę nie jest zbyt wygodne, dlatego programista pisze w rozszerzonej składni C++ o nie, a moc przetwarza łatwy do pisania kod, na kod C++ (pisze kod slotów i sygnałów za programistę… i w gruncie rzeczy jest to kod C (wykorzystywana jest tylko biblioteka standardowa języka C, ale pakuje to do metod (nie wirtualnych, więc po kompilacji wygląda to po prostu jak zwykła funkcja języka C))) i piecze dwie pieczenie na jednym ogniu. Łatwy do pisania kod i wydajna dobra implementacja. GTK niestety robi coś zupełnie odwrotnego, bo sygnały z GObject są zaimplementowane strasznie powoli, a korzystanie z nich to przeżycie traumatyczne.

> a wymaga mniejszej mocy obliczeniowej

Nie chce dalej ciągnąć tego oftopu ale pokaż jakiś benchmark bo brzmi jak bajki

Niestety – testy własne (kiedyś pisałem w GTK (od 1.x), później w Wx (zmieniłem w czasach GTK2.x), a od przejścia Qt na LGPL w Qt) i robiłem własne benchmarki… jednak jest to łatwe do zauważenia w programach z UI w 2ch wersjach (przykładowo PCManFM po porcie do Qt zmniejszył zapotrzebowanie na cykle proceosra)… a spór pomiędzy twórcami GTK i Qt jest od lat taki sam "Qt jest wydajniejsze!" a druga strona "GTK potrzebuje mniej pamięci!" i nie było tu wielkich zmian według testów, które przeprowadzałem.

Co do sporów o języki w tym wątku, kolega przypomniał mi pewien prześmiewczy tekst. http://tajemnice.atari8.info/4_92/4_92_program.ht…

Zamiast głupkowato drwić, zapoznaj się z faktami:
"Mir only exists because of all the work Wayland devs have done around the Linux graphics stack. It uses exactly the same stack that Weston's drm backend does."

"The Mir EGL platform looks almost exactly the same as the Wayland EGL platform. Which looks almost exactly the same as the GBM EGL platform, which looks almost exactly the same as the X11 EGL platform." http://blog.cooperteam.net/2013/03/mir-and-you.ht…

"We have integrated X, leveraging the prior XWayland work, to run on top of Mir (XMir)" https://samohtv.wordpress.com/2013/03/04/mir-an-o…

Plany koncepcyjne wykonali twórcy Waylanda, ale w niektórych sprawach się mylili. Nic dziwnego też, że używają tych samych bibliotek w końcu to Open Source. A to, że EGL działa podobnie w obydwu projektach zawdzięczamy właśnie zamieszaniu jakie pojawiło się po ogłoszeniu Mira. Wayland miał działać w oparciu o KMS i dopiero po pojawieniu się Mira deweloperzy Wayland skorzystali z wcześniej odrzuconej biblioteki, z której również skorzystał Mir. Ale, żeby twierdzić że kod został skopiowany trzeba mieć jakieś poszlaki.
Więc jak można poważnie traktować wypowiedź o kopiowania kodu?

EGL nie działa podobnie, bo w Waylandzie wymaga pewnego rozszerzenia :-)
Tam jest duży nacisk społeczności, by Wayland zmuszał do otwartych sterów.

Nie do końca. EGL to standard i jego API jest takie samo niezależnie czy z Mesy/Nvidii/AMD czy innych. Wayland nie może tu nic więcej wymagać. Wayland jednak wymaga na kompozytorze, aby ten rozmawiał z KMS, który wymaga GEM, przez co sterowniki graficzne muszą wykorzystywać KMS/GEM, a sam EGL nie ma tu nic z tym wspólnego. http://upload.wikimedia.org/wikipedia/commons/thu…

Chyba z "faktami". Mir może korzystać z projektu Eagle czyli EGL z Mesy (jednego z programistów RedHata, który stworzył go przed rozpoczęciem prac nad Waylandem), ale nie musi i może korzystać z EGL producentów SoC (implementacje EGL przygotowane pod Androida działają z Mir), a od początku wiadomo, że Mir nie powstaje dla Eagle, a dla zamkniętych sterowników EGL Nvidii/AMD (i zamkniętych sterowników EGL z Androida), które są w drodze… więc pisanie o tym, że nie istniałby bez pracy jaką wykonano przy otwartych sterownikach (którą niezależnie czy Wayland by powstawał i tak by zrobiono… nawet dla samych Xów) jest trochę śmieszne.

Co do Mir EGL platform, wygląda podobnie jak Wayland EGL platform, który wygląda podobie do Mesa EGL platform, a wszystkie wyglądają podobnie do wzorcowego Khronosowego połączenia Khronos EGL z Khronos OpenWF… szokujące. Jedyne co smuci to to, że cała ta banda robi bezsensowne nowe API, aby mieć wyłączność, zamiast pisać po prostu swoje implementacje OpenWF i walczyć na jakość implementacji, które łatwo wymienić na inne jeśli będzie lepsze, zamiast przeciągać linę… "to my chcemy zarządzać rozwojem i wymuszać nasze rozwiązania na innych".

Co do XWayland/XMir to ciężko mi je traktować jako część tych projektów – to po prostu chwilowa kompatybilność wsteczna, która czym prędzej musi iść do kosza.