diff Ac Th (Re: SPECS: dbus.spec - next step, relese 4.2, java enabled, rebuild w/...)

[Jakub Bogusz]

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/