Kompilacja nowego mc

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Czw, 15 Kwi 1999, 10:41:06 CEST


On Wed, 14 Apr 1999, Marcin Dalecki wrote:

> Tomasz Kłoczko wrote:
> > 
> > On Wed, 14 Apr 1999, Marcin Dalecki wrote:
> > [..]
> > > Dokladnie tak postapilem :-).
> > >
> > > Zwlaszcza ze szkoda marnowac czas na GNOME, albowiem po prostu jest nie
> > > do uzytku w obecnym stanie.
> > 
> > No ja jakoś widże jednak sens inwestowania w tego stworka.
> > Powiedzmy tak .. nie widzę powodów dla których nie miałbym mu dać szansy
> > istnienia :)
> > 
> > Faktem jest, że do zrobienia jest jeszcze dużo, a oznaczanie obecnych
> > źródeł wersją 1.x jest lekko na wyrost :>
> 
> Tylko, że nie ma moim zdaniem sensu wkładanie do DYSTRYBUCJI
> programów które po prostu NIE SĄ zdatne do faktycznego ich
> użytkowania. (Są lipą, picem na wodę i fotomontarzem - mówiąc wprost.) 

W dużej części zgoda. Na razie do produkcji się to nie nadaje. Co nie
powinno chyba jednak znaczyć, że nad pakietami nie warto pracować :)

> Niestety ale inaczej nie da się określić obecnego statusu
> GNOME. Może w (moim zdaniem dalekiej) przyszłości coś z tego wyrośnie.
> Wąwczas nic nie będzie przemawiać przeciwko włączeniu tego do PLD.
> Jak narazie nie widzę szans. A dokładniej oceniam, że zanim GNOME będzie
> zdatny do czegokolwiek trzeba by poczekać jeszcze minimum ze dwa lata.
> Jednak oceniając dotychczasowe "produkty" głównych programistów z RedHat
> nad tym siedzących nie rokuję szczerze mówiąc temu projektowi
> jakiejkolwiek przyszłości. Cały ten hipe i puste obietnice 
> nt. CORBY, DOM, en(niegdy nie jestem w stanie zapamiętać tego
> pomiędzy)tment 
> window managera, a zwłaszcza tych brzydkich jak noc themesów, itp. itd.
> jest 
> nieuzasadniony i poważnie podważa wizerunek dystrybucji jako takiej.

Momet .. moment. Nie tylko enl* jest "zgodny" z GNOME. W tej chwili są to
IceWM, WM, AfterStep (>= 1.6.10), FVWM2 i szykuje się BlackBox choć tutaj
ludzie od BB bronią się (jest o tym na stronie domowej BB) i duzo wskazuje
na to, że część wymysłów rastermana pójdzieniedługo w niepamęć. Zdaje się,
że także kwm ma być także GNOME-zgodny.

> Zwykle projekty programowania odnaoszące sukces charakteryzują się tym,
> że
> rozwijają się od stabilnej wersji do rozszerzonej stabilnej wersji.
> We wiekszych projektach jest bowiem tak dobrze jak niemożliwe wycinanie
> nawet najdrobniejszych błędów. Jak narazie to GNOME rozwija się od 
> niewykończonego chłamu po niewykończony chłam z jeszcze większą 
> ilością dodatkowych niedziałajacych opcji. Ponadto widzę poważne błędy
> w całej tej koncepcji tego czym ma być GNOME:
> 
> 1. Poprzez zastąpienie np. durnych Xresourców jeszcze durniejszym
> LISP-em nie rozwiązuję się jakiegokolwiek problemu dla normalnego 
> uzytkownika, a jedynie odziewa się problemy jakie zawiera koncepcja 
> Xresourców w inne szaty.

Marcin mógłbyś coś więcej na ten temat. Porostu interesuje mnie to.

> Może niektórzy lubią edytory w których trzeba się nauczyć
> specyficznego dialektu przestarzałego języka programowania, zanim da
> się je skonfigurowac tak, aby jako tako działały bez nadwyrężania
> sobie scięgien, ale ja np. się z pewnościa do nich nie zaliczam.

Cóż prawdą jest także to, że część operacji bez takich ficzerów jakie są w
emacsach jest w innych edytorach ciężej wykonywać (albo nawet bardzo
ciężko czyli lepiej użyć [x]emacsa z braku laku). Są także ludzie którzy
uznają tylko [x]emacsa.

> Wystarczy porównać pliki konfiguracyjne w KDE z tymi z GNOME...
> 
> 2. CORBA. Śliczne piękne w założeniu. Tylko dlaczego tego nik jakoś
> za bardzo nie stosuje? Może dlatego że jest to dość stary system, 
> który już nieraz doprowadził do zawalenia całego projektu? Proszę
> uprzejmie zerknąć na to co wyszło z projektu Fresco. To miało być
> też takim uniwersalnym zwierzęciem gospodarskim dajacym:
> mleko, wełnę i szynkę naraz i oczywiście bazowało wówczas na
> świerzutkiej koncepcji CORBy...

IMHO KDE ma też "zady i walety". Jedną z takich rys na wizerunku KDE jest
realizowanie obsługi np. UTF na poziomie toolkitu lub tuż nad nim. Takie
rzeczy IMHO, żeby były maksymalnie efektywne powinny być relaizowane na
bardzo niskim poziomie. IMHO dobym rozwiązaniem byłaby tu bibliteczka
przychodząca z glibc osadzona w całości na podobnym miejscu jak obecny
crypt. W LJ chyba z przed miesiąca było dość szczegółowe porównaie KDE/Qt
vs. GNOME/Gtk+. Przyznam się, że niektóre rzeczy z omówienia KDE nie
podobały mi się (chodzi o perspektywy rozwoju  i możliwe kierunki tegoż).
W razie czego postaram się sięgnąć jeszcze raz do tego artykułu żeby
wyciągnąć kilka rzeczy, które mnie wtedy ciut niepokoiły.

> Jak ma np. się w to wszystko wgryżć ktoś chcący napisać tylko 
> prostą no choćby przeglądarkę plików dvi? Zniechęci się do reszty
> zanim cokolwiek zdziała.
> 
> 3. Stosowanie C do GUI. Obecnie istnieją już porządne kompilatory C++.
> 
> 4. Nie byłoby tak źle gdyby się faktycznie zdecydowano na C.
> Ale oni też wymagają jeszcze ponatdo IDL, LISP-a, ObjectiveC, perl-a 
> itd... Brakuje chyba jeszcze tylko Javy (tym można by się reklamować!).
> i FORTRAN-a (oczywiście dla aplikacji numerycznych typu spreadsheet ;-).

Jakiś język skryptowy trzeba było wybrać. Chodziło o coś takiego jak REX z
OS/2 AmigaOS. IMHO jest to poprawny kierunek jeśli chodzi o taktykę
tworzenia komponentów i wiązania ich sznurkiem .. gdzie tym sznurkiem ma
być jakiś język skryptowy. Obecnie w Gtk+/GNOME dużo wskazuje na to, że
będzie to raczej perl. tak czy inaczej sposób wyboru takiego języka
dokonuje się raczej drogą doboru naruralnego niż wymuszania z góry. Dobrze
to czy źle .. ciężko ocenić.

> 5. Całe to wymaganie specyficznych WM_HINTSÓW jest nieporozumieniem.
> KDE sobie doskonale bez tego radzi. Nie ma więc defakto możliwości
> obejścia się bez gówniarskiego en(wiele o wiele za wiele liter)tment-a.

Tu się zgodzę .. hinty są raczej nie potrzebne.

[..]
> Jeszcze raz powtarzam dla wyrazistości: Nie widzę sensu we 
> włańczaniu oprogramowania niegodnego stadium ALFA do jakiejkolwiek 
> dystrybucji, bo to tylko robienie w kółko i kopanie pod własną 
> reputacją. Niech sobie ludzie od GNOM-a spokojnie dalej programują. 
> Gdy faktycznie będą mieli coś do zaprezentowania, wówczas śmiało można
> się 
> podłączyć. Ale jak narazie jest to tylko zaśmiecanie depozytu CVS.
> Miejscem na pracę nad GNOME chyba nie ma być PLD?!

Mi tam miejsca nie szkoda :)

To co wejdzie do dystrybucji to tak czy inaczej wybór na innym poziomie.
Wybór ten dobrze by było robić na bazie zrobionych pakietów i decydowanie
o tym co ma wejść w ten zestaw to jakby inna para kaloszy która nie
powinna decydować o tym który pakiet się powinno robić, a który nie.
Tak czy inaczej ów wybór będzie się dokonywał za jakiś czas, a wtedy stan
poszczególnych pakietów będzie napewno mocno odbiegał od tego co jest
obecnie.

Apropo jeszcze KDE .. to może by tak osoby zainteresowane tym stuffem ciut
mocniej poszlifowały pakiety ? Tak czy inaczej KDE w szkielecie to kilka
pakietów źródłowych. Dalej inncy rzeczy opartych czy to o czyste Qt czy
także o liby KDe jest kilka setek. Czyżby nikt tego nie używał :)

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*



Więcej informacji o liście dyskusyjnej pld-devel-pl