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

[Mariusz Mazur]

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?

> Eksperymenty? Kiedyś był nest...

A teraz nie ma. Zresztą to nie o nesta chodzi...

> Dalej póki co są to eksperymenty - bardziej nest niż trzecia wersja
> PLD...

A co mam robić, dążyć do wydania Th przed Ac? Czy może odłączyć wtyczkę i 
osoby zainteresowane gcc4 odesłać na /dev/drzewo, a sam nową automatyką bawić 
się w piwnicy? Na razie Ac spełnia większość wymagań zaś do Th dostęp mają 
chyba ze cztery osoby z czego ja pracuję nad automatyką, a pluto nad gcc4. Do 
tego po raz pierwszy mamy wersję, która jest przygotowywana na spokojnie, 
przy której można poeksperymentować organizacyjnie, a nie brać się na pałę za 
robienie czegoś, bo jest na gwałt potrzebne. Dwa lata temu zabrałem się za 
Ac, bo ktoś musiał (a i nie tylko ja się zabierałem, bo przymierzało się 
bodajże parę osób) i robiłem to kompletnie po omacku. Teraz mam doświadczenie 
i spokój, na wydłubanie pierwszej wersji pld, która nie będzie musiała się 
zastanawiać jak rozwiązywać problemy dopiero w momencie, w którym w nie 
wlezie. Może ty tego nie potrafisz docenić, ale ja tak.

> 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), 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)

> 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?

Wszystko, co się pojawi. A że w Ac jest development ciągły i pewnie też taka 
funkcjonalność prędzej czy później do niego trafi, to już nie jest moja wina.

> > 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. Na ppc masz nptla. Na sparca nie. 
Jeśli to nie jest wystarczający powód, żeby nie trzymać tego przyklejonego do 
głównych architektur, to co jest?

> 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).

Ja mam buildery do sparca i alphy i obecnie jest tam 3.4.3. Puszczenie dwóch 
zleceń z gcc4, jak to będzie miało wersję 0.x i będzie gwarantowało jakotakie 
działanie, to nie jest problem. Doprowadzeniem tych builderów do stanu 
używalności (jakiś bootstrapik) zajmę się w ciągu najbliższych paru miesięcy. 
Co się z tym stanie później, to już będzie zależało od zainteresowania.

> 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?

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...

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?) 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.


-- 
Każdy człowiek, który naprawdę żyje, nie ma charakteru, nie może go mieć.
Charakter jest zawsze martwy, otacza cię zgniła struktura przeniesiona z 
przeszłości. Jeżeli działasz zgodnie z charakterem wtedy nie działasz w ogóle
- jedynie mechanicznie reagujesz.                 { Osho }