A propos pierwotnego tematu - mono do Th też poszło stare... Mimo, że deweloperzy tegoż mocno zalecają używanie wersji 1.1.x. Leci podbijanie releasów nawet bez sprawdzenia istnienia nowych wersji (choćby modułów perla jest >200 do uaktualnienia, całe update-TODO ma już ponad 1000 linii w stosunku do utrzymującego się długo ~600 w 2003/2004)
I mam trochę obaw, że energia idąca w to podbijanie releasów nie jest kosztem dopracowania Ac czy rzeczywistego rozwoju czegoś nowego. On Wed, May 11, 2005 at 12:35:46PM +0200, Mariusz Mazur wrote: > On środa 11 maj 2005 10:19, Jakub Bogusz wrote: > > Co takiego ma wnosić Th w stosunku do Ac oprócz gcc 4.0? > > Ani więcej wspieranych rozwiązań, ani architektur... > > a nawet mniej. Za to więcej wymagań. > > Jak na razie w ac jest (ojej) rozwój ciągły i coś nie widzę żadnych ruchów w > kierunku 'chodźmy to wydać'. Ale jeśli takowe się jednak zdarzą, to chyba > pamiętasz jak to było za czasów ra, gdy po mrożeniu nie mieliśmy żadnej innej > distro do zabawy? > Druga kwestia -- snapy kde/qt4. Jeśli to już wyjdzie (a nawet zanim wyjdzie > -- > rozwój snapów) to upgrejd do qt4 byłby trochę wstrząsający dla ac, natomiast > w th to żaden problem. Takich rzeczy będzie się robiło coraz więcej (na razie > ac jest dwie linie gcc za headem... za jakiś czas będzie trzy). Eksperymenty? Kiedyś był nest... gcc OK, ale to jedna rzecz. > Trzecia -- th daje mi możliwość przygotowywania lepszej automatyki. I takowa > już jest działająca (ja jej używam). Niedługo pewnie zrobi się na jeden dzień > przerwę w puszczaniu zleceń do ac i przeflancuję całe ac na nową automatykę, > a wtedy (a) przenoszenie paczek będzie zabierało minut 30, a nie 300 i (b) ac > będzie mogło od razu korzystać z poprawek, jakie będę wprowadzał. > Ostatnia rzecz -- na wakacjach mam zamiar się zabrać za zrobienie > odpowiednika > rc-inetd dla obsługi demonów (tzn. że jak ktoś będzie chciał, to będzie miał > startowanie demonów takie jak jest teraz, inny będzie mógł sobie podłączyć > freedt, czy co tam jeszcze i to będzie zawsze działało od kopa) oraz > przepisanie anacondy, żeby się dogadywała z poldkiem. Gdzie mam to robić? W > ra? Dalej póki co są to eksperymenty - bardziej nest niż trzecia wersja PLD... Wymienialny init mógłby być do sportowania także do Ac (zależy od realizacji - nie musiałby obejmować zmian w dużej liczbie pakietów). BTW: nawet jeśli sposób uruchamiania usług przy starcie systemu byłby inny, to ich ręczna obsługa przez "service usługa akcja" czy "/etc/init.d/usługa akcja" jest ustandaryzowana, więc nadal powinna być dostępna. Tak dla porównania - np. kolejne wersje RHL/FC oraz RHEL wnosiły (do dystrybucji jako całości): - NPTL - SELinuksa - exec-shield - audyt U nas: NPTL w końcu się pojawiło w Ac (z bólami), SELinux niby w Ac, ale tak naprawdę nie wspierany (brak jądra, brak atrybutów w pakietach, polityki prawie nikt nie tknął), niewykonywalny stosu i sterta pojawiły się w Ac "po cichu" (po wejściu do linusowego jądra) na architekturach obsługujących NX (aka x86_64) bez przygotowania w pakietach (a tak nagle mint przestał działać na amd64... inaczej bym nawet nie wiedział). W Ac pojawił się kerberos (podobno gdzieniegdzie działający), jakieś przybliżenie do LSB (dostosowanie skryptów startowych) i specyfikacji z freedesktop.org (.desktopy). Co z takich rzeczy może wnieść Th? > > W Th? i486 (*3), x86_64, ppc. > > Na alphę ani sparca (nawet 32) nie ma nic. > > Nawet jeśli mają być "nie wszystkie pakiety", to przy coraz większej > > liczbie pakietów lecących do Th nadrobienie może być trudne. > > > > (swoją drogą dlaczego 32-bitowe ppc tak, a alpha i sparc(64) nie? > > alpha chyba nie jest już rozwijana, ale dostępne maszyny (za hp.com) nie > > ustępują raczej dostępnym opartym na 32-bitowym ppc; > > sparc64 jest nadal rozwijaną architekturą) > > Założenie jest takie, że ludzie nie wykorzystują sparca i alphy tak samo, jak > ppc i *x86, ppc? Ile jest ppc z PLD (>Ra) w stosunku do sparców? Zwłaszcza po ostatnim zasileniu deweloperów w ileś sztuk Sunów Ultra 5 z allegro? ;) > więc będzie znacznym ułatwieniem dla rozwoju dystrybucji, jeśli > się je wydzieli. Nawet Debian, przy ich zasobach ludzkich, doszedł do > podobnego wniosku. Druga sprawa jest taka, że z punktu widzenia zastosowań > serwerowych ac pewnie przez dłuższy czas będzie sparcowcom i alphowcom > wystarczało, więc w th tego nawet nie dotykam, póki rzeczywiście nie zajdzie > potrzeba. A jak zajdzie, to bootstrap się okaże już niezbyt wykonalny. Podobnie jakby teraz próbować zasoby Ac budować od podstaw na Ra... abstrakcja. Już teraz gcc 4.0 z HEAD się nie bootstrapuje na 3.3.5 (na alphie; ia64 pewnie też, ale nie mam maszyny). A jak już pozbędziemy(cie?) się na dobre wszystkich "niemainstreamowych" architektur - co takiego PLD będzie wnosić w stosunku do np. FC czy Mandrivy? -- Jakub Bogusz http://qboosh.cs.net.pl/ _______________________________________________ pld-devel-pl mailing list pld-devel-pl@pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
