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

[Jakub Bogusz]

(mocno pocięte - kiepsko z czasem i spać już mi się chce)

On Thu, May 12, 2005 at 03:00:15AM +0200, Mariusz Mazur wrote:
> On środa 11 maj 2005 21:29, Jakub Bogusz wrote:
> > I mam trochę obaw, że energia idąca w to podbijanie releasów nie jest
> > kosztem dopracowania Ac czy rzeczywistego rozwoju czegoś nowego.
> 
> Ac jest 'dopracowywane' od ponad roku. Na oko, to powinno wszystko być już 
> wypolerowane na wylot.
> Zaś pomysł z 'przerzucaniem energii' uważam za... zabawny. Znaczy jak nie dam 
> builderów z gcc4, to pluto merdając ogonkiem :) pójdzie z nudów poprawiać na 
> alphie w ac jakieś przypadkowe błędy kompilacji?

Dziwi mnie trochę kolejność.
Czy podbijanie releasów w starych wersjach pakietów jest takim
pasjonującym zajęciem? Ani to Ac, ani coś nowego - na razie wychodzi
w większości takie Ac przekompilowane gcc 4.
A można by przygotować nowe mono, dbus+hal+... itp.

> > 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).
> 
> Wymienialny zarządca demonów (tylko i wyłącznie -- nie zamiennik inita i nie 
> rc-scriptsów) wymagałby przerobienia we wszystkich naszych demonach plików 
> initowych na jakieś pliki z metadanymi, więc, jeśli zdążyłby zostać zrobiony 
> odpowiednio szybko, to w ac by pewnie wylądował.
> 
> > 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.
> 
> Spece i tak mają na sztywno np. chkconfig (co by było do zamiany na jakieś 
> metanarzędzie),

chkconfig może być takim metanarzędziem.
W aktualnych wersjach (oryginalnych, nie z PLD) oprócz init.d obsługuje
także xinetd i alternatives - więc mógłby i inne.

> więc nie wiem co z /etc/init.d/ miałoby korzystać? (acz fakt, 
> z tego co widziałem, to większość zarządców coś takiego udostępnia)

Admin?

> > > 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? ;)
> 
> Ibooka z pld masz jako desktop. Sparca nie.

Zależy jakiego (jako desktop, nie *book; fakt, że współczesnym x86* nie
dorównają).
Maszyna aktualnie znana jako builder ac-alpha swego czasu służyła także
jako desktop ;) (zanim poszła do szafy).
Zresztą "serwer" może oznaczać także serwer aplikacji dla X-terminali.

> Na ppc masz nptla. Na sparca nie. 

Na alphę mam. Na sparca IIRC na HEAD już też (po tym, jak davem chciał
dodać jakieś poprawki do linuxthreads i usłyszał, że ten kod nie będzie
miał więcej wydań po 2.3.x).

> Jeśli to nie jest wystarczający powód, żeby nie trzymać tego przyklejonego do 
> głównych architektur, to co jest?

[...]
> > 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?

BTW jak się okazuje niedawno pojawił się port FC na alphę (Alpha Core)

> Wnioskuję z tego, że uważasz, że jeśli nie zmusisz ogółu deweloperów do 
> zajmowania się sparciem i alphą, to nie znajdzie się nikt, kto będzie nimi 
> zainteresowany i one wymrą. Jeśli to ma być twój argument za zostawieniem ich 
> podpiętych pod mainstream, to...

Zły wniosek.
Jeśli w ogóle tylko nieliczne rzeczy będą szły na te buildery, to nawet
nie będzie wiadomo, co sprawia problemy (większość się sprowadza do "we
type rpmbuild...").
Utrzymywanie "starych" architektur !x86 zwiększa też trochę przenośność na
nowsze architektury (część poprawek pod kątem alphy ułatwiła port x86_64
i, niedoszły niestety, ia64).

> Wydzielenie ewidentnie serwerowych alphy i sparca, a zostawienie jednak 
> desktopowego i w miarę nowoczesnego ppc (czy przez przypadek linus nie ma 
> czegoś takiego jako desktop?)

ale ppc64, którego nadal nie mamy

Ad ppc: jakieś nadzieje na obsługę altiveca w Th?
Builder jest ten sam co ac-ppc, dopóki tam jest zwalone jądro, to w obu
liniach altivec leży i kwiczy.

> to jest według mnie najrozsądniejszy kompromis 
> pomiędzy tymi, którzy chcieliby pld x86 only (żeby development szedł 
> płynnie), a tymi, którzy potrzebują też dodatkowych arch. Jak ktoś ma lepsze 
> pomysły jak zadowolić w pełni i jednych i drugich, to ja zamieniam się w 
> słuch.

Jeśli już koniecznie część architektur traktować inaczej - to budować wszystko
(w ramach istniejących zależności i EA), jeśli coś się wywali - można nie
wstrzymywać "normalnych".


-- 
Jakub Bogusz    http://qboosh.cs.net.pl/