Przyszłość graficznego instalatora Debiana zagrożona [aktualizacja]
- Dodano: 31 stycznia 2010
- Wprowadził: azhag
- Komentarze: 59
Obecny status graficznego instalatora Debiana jest bardzo niepokojący, zauważa w blogowej notce Josselin Mouette. Biblioteka GTK+ w wersji z aktualnej gałęzi testowej (2.18, wkrótce 2.20) posiada poważne błędy w module DirectFB, które czynią ją niezdatną dla instalatora. Z tego powodu pierwsze wydanie alfa instalatora nie będzie posiadało graficznego trybu.
O ile — jak pisze Mouette — „ktoś czegoś nie zrobi”, graficzny instalator Debiana może zakończyć swoją karierę. Oprócz oczywistych konsekwencji, oznaczałoby to również koniec obsługi niektórych lokalizacji: indyjskich, tajskiej, amharskiej i wszystkich o kierunku pisma od prawej do lewej. Z tego powodu deweloper Debiana apeluje o ocalenie trybu graficznego trybu instalatora. Podsuwa w tym celu kilka propozycji:
1. Naprawa obsługi DirectFB w GTK+
Dotychczas zawsze zgłaszał się ochotnik, który przystosowywał ponownie GTK+ dla potrzeb instalatora Debiana. Dotychczas zajmowali się tym Attilio Fiandrotti oraz Sven Neumann, jednak tym razem zajęci są innymi czynnościami.
Gdyby ktoś przejął po nich zadanie poprawiania DirectFB, Projekt Debian będzie mógł wydać instalator z dwoma trybami przynajmniej w wersji Squeeze. Prace wymagać będą bardzo dobrej znajomości DirectFB oraz GDK.
2. Migracja na X11
Skoro GTK+ nie działa poprawnie z DirectFB, można zmodyfikować instalator, aby używał graficznego środowiska X11. Zmiana ta wymagać szybkiego tempa prac, jednak ma tę przewagę, że środowisko X11 jest dobrze znane i dojrzałe, podobnie jak obsługa GTK+ w nim. Skutkiem ubocznym jednak będzie zwiększenie rozmiaru mediów instalacyjnych.
Zadanie to będzie wymagało prac nad pakietami udeb:
- spakietowanie kilku bibliotek:
- co najmniej: libx11, libxi, libxext, libxrender, libxft, libdrm, libgcrypt, libpciaccess, libpixman, libxau, libxfont, libudev
- prawdopodobnie również: libxcursor oraz dmz-cursor-theme (ładny kursor), libxrandr (możliwość wybrania rozdzielczości), libthai (obsługa języka tajskiego)
- spakietowanie serwera X: xorg-server, xserver-xorg-video-fbdev
- zmiany w skryptach konfigurujących pakiet gtk+2.0, aby zbędne w instalatorze rozszerzenia X11 mogły zostać wyłączone
- przebudowa pakietów udeb zawierających cairo, pango1.0 oraz gtk+2.0 aby były budowane z obsługą X11
- przebudowa instalatora do GTK+ używającego X11
- zmiany w skryptach startowych instalatora: uruchomienie serwera X, konfiguracja klawiatury dla X11, itp.
Wydaje się, że to dużo pracy, jednak — jak zapewnia Josselin Mouette — nie jest to nic skomplikowanego. Każda osoba wystarczająco obeznana z Debianem jest w stanie sprostać tym zadaniom, z niewielką pomocą opiekunów wymienionych pakietów.
Aktualizacja:
Cyril Brulebois rozpoczął przygotowania do migracji instalatora na X11. Zdał już pierwszą relację z postępu prac.
Więcej informacji: http://np237.livejournal.com/27459.html
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
59 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Zgodnie z nową świecką tradycją, treść wiadomości na LinuxNews się nie pokazuje… Próbowałem edytować na LN — na próżno. Jakby ktoś mógł coś zrobić, byłbym dźwięczny.
Jak dla mnie, porzucenie graficznego instalatora nie byłoby żadną stratą. Przecież te znakowe okienka zwykłego instalatora nie są ani trudne ani kłopotliwe w obsłudze. Dublowanie czegoś co już istnieje i dobrze działa jest wyłącznie marnowaniem czasu.
Czytasz ze zrozumieniem?:
"oznaczałoby to również koniec obsługi niektórych lokalizacji: indyjskich, tajskiej, amharskiej i wszystkich o kierunku pisma od prawej do lewej."
Nalezaloby sie zastanowic, dlaczego Linuksowa konsola – wspierajaca podobno UTF-8 – z w/w nie dziala.
3. porzucenie GTK+; instalacja FLTK.
Zastrzeżenia prawdopodobnie analogiczne do użycia Qt (patrz komentarze w podlinkowanej notce) — wymagałoby to nie tyle przeportowania do innej biblioteki graficznej, co przepisania praktycznie całego instalatora w C++.
Tu powtórzę za Mouette'em — jeśli ktoś chce się podjąć zadania przepisania instalatora oraz dbania o jego nową wersję, nie ma przeszkód (poza ogromem potrzebnych prac, co najpewniej oznacza, że taki instalator pojawiłby się najwcześniej w wydaniu Squeeze+1).
Trzeba było go pisać od początku w C++. Użycie przestarzałego GTK+ używającego C nie wymaga pisania całego instalatora w C.
Instalator, to nie jest tylko interfejs(chociaż pewnie wiele kodu za niego odpowiada). Instalator, to również inne bebechy. C++, a ANSI C, to prawie to samo(tzn. można powiedzieć, że ANSI C jest podzbiorem C++).
oO, C nie jest przestarzałe, jest ultrastare, ale przynajmniej jest dobre w tym, do czego się nadaje. Natomiast C++ jest mocno przestarzałe, a na dodatek od początku źle zrobione, i w związku z tym, nie widzę sensu pisania czegokolwiek w tym języku (oprócz dużych programów, które od zawsze były pisane w C++), a zwłaszcza graficznego interfejsu programu.
Sławku, to, że kompilatory C++ generalnie umieją skompilować programy pisane w C, nie znaczy, że program (w tym przypadku instalator Debiana) napisany w C nagle jakimś magicznym sposobem stanie się obiektowy.
Co takiego złego jest w C++? (lol)
A co takiego dobrego
? Są ludzie, którzy wolą stare dobre C (jak ja) – naprawdę 
. Choć i C++ się posługuję.
Co złego w C++? Poważnie pytasz? Pisałeś w tym cokolwiek dużego?
Różne API uniksowe z których program ma korzystać są napisane w C a nie w C++ (chociażby użycie pthread czy ustawienie blokady dla pliku w programie C++ nie jest proste), poza tym nie każdemu chce się ciągle pisać std:: czy używać idiotycznych szablonów zamiast prostych makr takich jak w C.
W C++ nie ma też realloc() i trzeba ciągle ręcznie tworzyć, kopiować i usuwać tablice, aby zmienić ich rozmiar.
itoa() i atoi() z C też są prostsze w użyciu niż stringstream z C++.
Fragment jednego programu w C++:
throw std::bad_cast( (std::string("cannot cast from [") +
typeid(this).name() + "] into [" + typeid(type_holder<T> *).name() +
"]").c_str() );
czyli zupełnie nieczytelny kod, nawet dla zaawansowanego programisty C.
No i kompilatory C++ używają kilkanaście razy więcej RAM-u niż kompilatory C.
Skrytykowałeś STL a nie C++.
W C podobny przyklad napiszesz (z void* i C-castami, tablicami funkcji itp.).
Makra nie sa typesafe jak wiesz.
"No i kompilatory C++ używają kilkanaście razy więcej RAM-u niż kompilatory C."
Aż tyle więcej nie, poza tym takie gcc rozbija kompilację na zadania co zresztą umożliwia równoległą kompilację. Zakładam, że nie masz pojedynczego pliku .cpp z 1MB kodu?
Przeglądarka której używasz zapewne używa go też sporo. W każdym razie jest tańszy niż czas programisty.
@oO "Co takiego złego jest w C++? (lol)"
Może za odpowiedź niech posłuży zawartość mojej półki?
* Klasyczne wydanie K&R Ansi C, około 250 stron w całości opisujące język.
* Obok cegła opisująca C++, prawie 1000 stron, liczne braki, np nie ma opisu STL.
Twórcy C++ zachowali się jak dziewica, która chciała by, ale się boi.
* Z jednej strony uznali wskaźniki za zło, postanowili zastąpić je referencjami, ale nie mieli odwagi ich usunąć.
* Makra? Zło, lepsze jest używanie const, inline, stl… Tu także nie mieli odwagi na cięcia.
W efekcie powstało monstrum, które do wszystkich problemów C dodaje cały szereg własnych…
Stworzenie kompilatora C od podstaw, nie jest łatwe, ale wykonalne nawet dla jednej osoby. Jednak nie wyobrażam sobie by ktoś podjął się podobnego zadania w przypadku C++
… ach i na koniec, w C++ ze zwględu na STL odradza się używanie przyrostkowego operatora inkrementacji, tego samego który jest w jego nazwie.
To może po prostu Tk? Czemu nie? Czego więcej potrzeba do instalatora?
> 3. porzucenie GTK+; instalacja FLTK.
Widze jeszcze lepsze, Qt + framebuffer. Jesli do tego pojdzie na tym PyQT
to po co sie babrac w jakims niedorobionym, niskopoziomowym badziewiu?
jak by tam mieli dać pajtona to chyba szybciej przerzucą się na xorg…
Mi stary instalator odpowiadał. Po przejściu na x11, w takim razie będzie coś w stylu ubuntu like.
> będzie coś w stylu ubuntu like
Bynajmniej, będzie to taki sam instalator. Po prostu okna będą tworzone w X, a nie DirectFB.
Poza tym słuchajcie — ja rozumiem, że wolicie instalator tekstowy, a graficzny jest wam zbędny (sam należę do tej grupy użytkowników, ba! zalecam używanie właśnie tekstowego). Ale miejcie na uwadze, że koniec instalatora graficznego, niesie za sobą inne konsekwencje. My akurat mamy to szczęście, że tekstowy instalator może zostać spolonizowany, ale nie wszystkie nacje również je mają. Debian bez możliwości graficznej instalacji będzie odrobinę mniej „uniwersalnym systemem operacyjnym”.
Z jednej strony tak, ale z drugiej jeśli ktoś się chce bawić czymkolwiek trochę bardziej zaawansowanym technologicznie (a Debian nie jest dla ZU), to i tak musi znać angielski; a język może sobie zmienić po instalacji. Także nie wyolbrzymiałbym problemu.
Trzecie rozwiązanie:
Zrezygnować wreszcie z gtk+, które dawno już powinno umrzeć. Kto to słyszał, żeby biblioteka widgetów nie opierała się na klasach i dziedziczeniu, tylko używała czystego C?! Do tego ma mnóstwo błędów i jest stosunkowo wolna. Przecież to jest żałosne.
Może wreszcie czas się obudzić i przerzucić na Qt (obsługuje directfb)?
Nie skomentuję tej wypowiedzi, bo nie znajduję w niej nic wartego komentarza. Chciałbym tylko zauważyć, że zwolennika Qt walczącego na śmierć i życie z GTK+ spodziewałem się wcześniej. Prawdopodobnie świadczy to o delikatnie podnoszącym się poziomie serwisu.
Kto to widział, żeby krytykować, nie mając pojęcia o czym się pisze?!
> Aktualizacja:
> Cyril Brulebois rozpoczął przygotowania
> do migracji instalatora na X11.
Wybór X11 jest bez sensu. FB zadziała praktycznie zawsze. X11 wymaga sterowników, nie zawsze ruszy, czasem kończy się czarnym ekranem (np. na ATI).
Na prawdę tak bardzo kochają gtk+, że nie mogą wreszcie wejść w 21 wiek i go porzucić?
Może niedługo zobaczymy totalne hacki, byleby tylko nie przyznać, że gtk+ nie działa i nie zostawić go wreszcie na śmietniku historii? Ew. w muzeum jako ciekawa wewnętrzna biblioteka Gimpa, skąd nigdy nie powinna była się ruszać (a wtedy Gimp już dawno byłby przeportowany na Qt i nie wywalałby się co jakiś czas przy drag&drop i innych "trudnych" sytuacjach).
Gdyby tak wszyscy myśleli to ani koło ani GNOME nie zostało by wynalezione.
I nie wiem czy wiecie ale będzie coś takiego jak GTK3 i tyle w tym temacie.
A ja lubię korzystać z graficznego instalatora w debianie, podoba mi się i szkoda by go było
Mówisz o jakim sterowniku? Bo dla instalatowa wystarczy X11 oparte np. o vesę/vga.
gtk+ na X11/Win32 działa całkiem nieźle. Nie mam z GNOME żadnych problemów (no dobrze – jak korzystam z alfy/gita to zdarzają się
). DirectFB nie jest dobrze przetestowany… bo mało kto z niego korzysta. N900 ma X11, openmoko ma x11 (nie żeby to był znaczące ilości), wszyscy na desktopach używają X11. Używają tego niektóre instalatory graficzne.
GIMPa mało używam ale nigdy przy żadnej operacji się nie wywalał. Za to 'cudowne' KDE 4.0 miało szereg błędów (tak wiem że w 4.x naprawili ale jak flame to flame
). Wniosek – sam fakt napisania czegoś w C++ nie powoduje że coś jest bez błędów.
> X11 wymaga sterowników, nie zawsze ruszy
najpewniej zostanie użyty uniwersalny sterownik fbdev
c jest be, c++ także, java to kobyła, więc jaki język programowania jest ok ? Może jakby to było napisane w assemblerze to było by ok ? Chociaż i tu pewnie znaleźli by się tacy co by stwierdzili że i on jest be.
Więĸsza część jądra linuksa jest napisana w c i c++, tak samo jak i większość jego oprogramowania, a wiek języka nie świadczy o jego jakości.
Co do samego instalatora, to można zrezygnować z jego graficznej odmiany tak jak i można w ogóle zrezygnować ze środowisk graficznych w debianie. Tylko czy o to chodzi ? Ja trochę nie rozumiem takiego podejścia ludzi którzy gdzieś się zatrzymali na jakimś etapie i wydaje im się, że więcej nikomu już do szczęścia nie trzeba.
Rozwój komputerów i oprogramowania wydaje mi się wymusza niejako właśnie graficzne gadżety bez których to system zostanie w kręgu zainteresowań co najwyżej pasjonatów. Jeżeli dana dystrybucja linuxa czy w ogóle jakikolwiek inny system operacyjny chce być więcej niż niszowy to musi być przyjazny także dla osób mniej obeznanych w temacie systemów operacyjnych, programowania i radzenia sobie z problemami.
Reasumując, to właśnie z tego powodu rezygnacja z graficznego instalatora nie jest dobrym pomysłem.
Wiek języka może tylko świadczyć o budowie, składni, itp. Czym nowszy język tym teoretycznie powinien wnosić wygodniejsze wyżej wymienione elementy ale jak historia pokazała – nie zawsze tak jest. Może też dziwić czemu nie napisali tego w np. pygtk lub perl::Gtk2 (większa zajętość ramu, dużo plików na nośniku, wolniejsze działanie?). Niemniej jednak nie ma to znaczenia, ponieważ nie w tym problem.
IMHO bardzo fajnie że przechodzą na x11. Też ktoś tam się dziwił, że czemu nie na fbdev ale z tego co mi wiadomo są sterowniki fbdev do xorga, które po prostu działają (już nie wspominając o vga).
a wlasciwie co zlego w tym, ze debian bylby znow niszowy? jest przeciez ubuntu, ma graficzny instalator, apta, bajery… wydaje mi sie (moje subiektywne zdanie), ze kiedys, kiedy malo kto radzil sobie z instalacja debiana (czasy dselecta), dzialal jakby stabilniej…
Większe znaczenie ma raczej rozmiar Debiana.
Ostatnim „przedaptowym” wydaniem był Hamm — dwie architektury (x86 i m68k), nieco ponad 1500 pakietów. Obecnie Debian obsługuje 19 architektur i portów (11 oficjalnie, 8 na różnym stopniu rozwoju — od gotowych do wydania, po ledwo rozpoczęte) i posiada ponad 33 tysiącu pakietów. Za Hamm na jednego dewelopera przypadało statystycznie 3,75 pakietu, obecnie około 20 pakietów.
to nie wrozy za dobrze na przyszlosc
Przepiszcie do php i jest moduł dla php gtk, będzie cacy.
Farmazony opowiadacie, aż się słuchać nie chce. Jak arabi itp nie znają ang i sobie z instalatorem nie pomogą to już ich problem. Amen.
A może ten pomysł nie jest zły?
Może tylko zrezygnować z PHP i GTK?
Instalator, który odpala httpd i odpowiednie skrzypty cgi/cokolwiek?
Użytkownik mógł by się podłączyć z przeglądarki na drugim komputerze i skonfigurować tak jak teraz to się robi z routerami, lub odpalić na tym samym komputerze XWindow+Przeglądarka, lub konsolę+links/lynx
Rozwiązanie wydaje się być zarówno łatwiejsze w rozwijaniu i bardziej uniwersalne…
Gratuluje, wlasnie wymysliliscie bsdinstaller z DragonflyBSD.
Gtk się sypie i ciągnie ze sobą wiele ciekawych projektów.
Ciekawe czy ich deweloperzy w porę się ockną i przeproszą się z Qt, czy
też będą czekać aż ich dzieła osiągną całkowite dno.
I nie chodzi tu o to czy nowocześniejszy jest C++ czy C czy może jeszcze
assembler, tylko o to w czym się najszybciej pisze i co ma najlepsze
wsparcie.
Tak w uproszczeniu to chodzi o pieniążki.
Gtk ich niema a Qt je ma.
GNOME ich niema a KDE je ma.
Pieniążki to ma Steve Jobs. Co on tam ma, Cocoa? W każdym razie, przerzućmy się na to, bo on ma pieniążki!
Albo na WinAPI!
Jeszcze lepiej – czas wrócić do ery MS-DOS-a łupanego. Ups, FreeDOS-a…
"GNOME ich niema a KDE je ma."
No patrz, a zupełnie nie widać. Hmm…
Jest trochę inaczej, może się zdziwisz: GNOME je miał bo to fundacja dobrze radząca sobie z pozyskiwaniem sponsorów w zamian za wpływy ale płaci pensję managera dla Stormy
Sam bonus wyniósł >10k dolarów w 2009.
Pieniądze nie idą w takim stopniu jak na w KDE na samo tworzenie oprogramowania.
Plany na 2010 to lekko mówiąc m.in. wyciąg z haseł znanych na studiach MBA: http://bit.ly/bBrYZO
Nie widżę sensu rozwijania instalatora graficznego (jakiegokolwiek w sumie) napisanego w tak niskopoziomowym języku jak C/C++ – idealnym byłby Python + PyQ4/PyGTK według mnie.
A czy to aż tak ważne jak język? Ktoś zna i lubi C++ to czemu ma się uczyć Pythona? Fakt sam jestem sympatykiem tego języka i też uważam, że prościej dla mnie by było pisać w Pythonie, ale każdy robi jak lubi
Nie jestem pewien czy użycie Pythona, Perla czy podobnego języka jest dobrym pomysłem. Ich interpretery i dowiązania do odpowiednich bibliotek zajmują trochę miejsca — na DVD narzut instalatora może i by „utonął”, ale bussinesscard (< 50 MB) zginąłby śmiercią naturalną, netinstall (~ 180 MB) drastycznie zwiększył swój rozmiar.
na bc i netinstall nie trzeba wrzucać g-i
Czyli proponujesz rozwijanie dwóch różnych instalatorów niezależnie? d-i w czym-tam-jest-obecnie-pisany oraz g-i w Pythonie/Perlu/…, będący nakładką? Nie uważam aby to był dobry pomysł.
z tego co wiem to tekstowy i tak zostanie, więc będą rozwijane dwa instalatory…
Cyril Brulebois zdał pierwszą relację z postępu prac nad migracją na X11: http://ikibiki.org//blog/2010/02/01/GI_part_1/
Prac ciąg dalszy, udało się uruchomić X na instalatorze:
http://ikibiki.org//blog/2010/02/03/GI_part_2/
Tu jest bardzo proste i dobre rozwiązanie
, które w każdym innym zdrowym systemie byłoby już dawno wykorzystane.
No ale niestety linux, a zwłaszcza debian do systemów zdrowych
ideologicznie nie należą.
Tak więc poprawniejsze ideologicznie będzie pewnie władowanie
dużych środków w naprawianie Gtk niż wykorzystanie gotowych
narzędzi opartych o Qt.
Chore podejście, ale niestety w linuxie prawdziwe.
> Tak więc poprawniejsze ideologicznie będzie pewnie władowanie
> dużych środków w naprawianie Gtk niż wykorzystanie gotowych
> narzędzi opartych o Qt.
Na kilka miesięcy przed wydaniem, lepszym wyjściem jest poprawienie istniejącego i — poza problemem z DirectFB — dotychczas działającego rozwiązania, niż władowanie ogromnych środków na pisanie nowego rozwiązania od zera, choćby niewiadomo jak było ono poprawne ideologicznie dla Ciebie. Nie ma żadnych przeszkód, żeby zamiast GTK+ użyć diabli wiedzą czego — ale żeby użyć diabli wiedzą czego, należy instalator do diabli wiedzą czego przepisać i zapewnić jego utrzymanie (vide: #4994612).
Czytasz, piszesz ale nic z tego nie rozumiesz.
Przecież wystarczy wejść na stronę która jest podlinkowana w
tym newsie żeby się przekonać że oni tam we wszystkim mogą pisać
tylko nie w Qt. Chcesz pisać w Qt to sobie pisz, ale nas to
nie obchodzi. Czy to nie jest fanatyzm?
Napisanie w Qt prostego instalatora graficznego który stanowi
nakładkę graficzną na instalator konsolowy to pryszcz.
Zapewnienie stabilnego działania Qt Embedded należy już do
deweloperów Qt, którzy to dobrze się wywiązują ze swoich obowiązków.
> Czytasz, piszesz ale nic z tego nie rozumiesz.
Sądząc z powyższego komentarza, rozumiem więcej niż Ty.
> Chcesz pisać w Qt to sobie pisz, ale nas to nie obchodzi. Czy to
> nie jest fanatyzm?
Nie, to się nazywa pragmatyzm. Co mu do tego jak graficzny instalator zostanie poprawiony/przepisany jeśli będzie działał? Joss sam się tym nie zajmuje, więc dlaczego ma go obchodzić użyte narzędzie?
Dlaczego *teraz* nie jest czas na przepisywanie do czegoś innego już pisałem.
> Napisanie w Qt prostego instalatora graficznego który stanowi
> nakładkę graficzną na instalator konsolowy to pryszcz.
I rozwijać de facto dwa instalatory (ściśle jeden instalator i osobną nakładkę)? Doskonały pomysł…
Miałem kilka razy problemy z instalatorem debiana, mianowicie zmieniało mi język na inny podczas instalacji i musialem cofać się w niej by to zmienić może to była wina cd ale wątpie bo na kilku róznych cd instalowałem rózne wersje i to dalej występowało od wersji 5,0. W moich oczach debian 4,0 był lepszy stabilniejszy i bardziej dopracowany….
I’m impressed, I must say. Genuinely hardly ever do I encounter a blog page which is the two educative and entertaining, and allow me to tell you, you have hit the nail around the head. Your imagined is outstanding; the situation is a thing that not adequate persons are chatting intelligently about. I am incredibly blissful that I stumbled all through this in my hunt for a person thing referring to this
Heya i am for the first time here. I came across this board and I find It truly useful & it helped me out a lot. I hope to give something back and aid others like you aided me.
I’ve learned new things from a blog post. One more thing to I have found is that normally, FSBO sellers will reject you actually. Remember, they’d prefer to never use your companies. But if you maintain a stable, professional relationship, offering help and staying in contact for about four to five weeks, you will usually have the ability to win a conversation. From there, a listing follows. Thanks