Kształt instalatora

[Rafał Kleger-Rudomin]

Michal Moskal <malekith w pld.org.pl> writes:

> On Wed, Apr 11, 2001 at 12:49:20PM +0200, Rafał Kleger-Rudomin wrote:
> > Michal Moskal <malekith w pld.org.pl> writes:
> > Ja już zacząłem robić takie coś bez xml bo imho sprawa jest zbyt prosta 
> > i xml jest tu niepotrzebny.
> > Natomiast przydałby się bardziej do metakonfigów.
> 
> Prosta, nie prosta... XML rocks :> Chociaż może masz rację.

Tu uwaga ogólna: wszyscy kochamy eleganckie, spójne i przyszłościwe
rozwiązania, ja też. Ale trzeba dobierać narzędzia na miarę problemu.
Błędem IMO jest zarówno użycie narzędzia zbyt słabego a jak i zbyt
potężnego.  A shell doskonale się nadaje to takich rzeczy.

> > Asha i tak się nie pozbędziemy, może awka.
> 
> Czemu?

żebyś mógł normalnie przejść do shella i np napisac sobie, wyedytować, skopiować,
skasować i zrobić cokolwiek innego z plikami konfiguracyjnymi 

> > Michał ja prawdę mówiąc myślałem że doozy to będzie tylko taki
> > support tool - konwerter do poszczególnych konfigów, a nie samdzielne 
> > narzędzie. Widziałem to tak że metakonfigurator jest napisany w shellu
> > i tylko wywołuje 
> > # doozy jakiś_konfig_xml szablon_doozy >wyjściowy_config
> > tzn masz zbiór metakonfigów, po jednym np na każdy pliczek który trzeba wygenerować
> > (/etc/fstab, /etc/aliases itd)
> 
> To nie przejdzie. To znaczy configi sa znacznie bardziej skomplikowane,
> i.e. prosty template nie nada. Zobacz rc-inetd.doozy i zastanów się
> jakby to wyglądało z template tylko...

No to mogą być bardziej skomplikowane, mogą korzystać z wielu metakonfigów
i generować wiele plików konfiguracyjnych z jednego pliku doozy, zdaję sobie
sprawę że to jest 
konieczne (ten przykład, który podałem był bardzo uproszczony).

> > To ja to widzę inaczej, 
> > mamy trzy główne moduły:
> > 
> > 1. UI do przygotowywania pliku z opisem instalacji dla instalatora
> >    ew również do przygotowywania metakonfigów
> > 2. Wsadowy instalator
> > 3. Metakonfigurator
> [snip] 
> > Teraz o interaktywności: interaktywny byłby pkt 1.
> 
> Hmm... a co jeśli czegoś brakuje? Wiesz, wygodnie byłoby zdefiniować

To trzeba tak przygotować żeby nie brakowało :) ewentualnie jak będą
problemy to poprawiasz i instalujesz na nowo. 
Tak jak napisałem UI edytor konfiguracji + validator musiałby to maksymalnie 
ułatwiać.
Wiem że łatwo się mówi a trudno realizuje, ale spójrz dalej na zyski

> sobie 90% konfiguracji a coś tam dopowiedzieć potem. To by chyba wykrył
> dopiero validate... Chyba, że to ma być duuuży config z polami już
> wypełnionymi, ale IMHO pytania byłby lepsze.

Pytania są gorsze bo to oznacza INTERAKTYWNOŚĆ!!!
IA jest fajna - w kontaktach z ludźmi - a komputery są
po to by odwalać za nas brudną robotę i możliwe nie zawracać nam d...
Wydawało mi się że nie jestem jedynym zwolennikiem takiej filozofi :)))
Chodzi o to by interaktywność wyeliminować.
Dla tych co ją muszą mieć jest ten pierwszy element UI, który musi być jak
"najmądrzejszy"

Wyobraź sobie sytuację: masz do zainstalowania w firmie serwer.
Wygrzebujesz/kupujesz komputer, wsadzasz bootkietkę pld,
wypełniasz formularz, wciskasz instaluj i wychodzisz na kawę/herbatę/papierosa
Tą samą dyskietką instalujesz później następny serwer, już bez
żadnego wypełniania korzystasz ze sprawdzonego konfigu.

Zauważ jeszcze dodatkowe możliwośći:

1. Współdzielenie instalacji. Jeśli tak zrobimy instalator, może
któregoś dnia ujrzysz na pld-users list "czy ktoś instalował PLD na
przęcie XXX, z kartą YYY, i może podzielić się konfigami do
instalatora"

2. Rozwijając dalej tę koncepcję, można budować bazę wiedzy 
i gotowe szablony instalacyjne dla różnych sprzętów, ewentualnie
przenosić tę wiedzę do instalatora, bazując na cudzych konfigach

3. A już wszelkie sytuacje kiedy masz serię identycznych maszynek
(laboratorium na uczelni, dostawcy sprzętu, firmy wdrożeniowe) to już
po prostu jest miodnie.


Rafał


-- 
Rafał Kleger-Rudomin (klakier w pld.org.pl)