suck

[Tomasz Kłoczko]

On Mon, 29 Jan 2001, Paweł Kołodziej wrote:

> Dnia Mon, Jan 29, 2001 at 11:47:53AM +0100, Tomasz Kłoczko napisał(a):
> > On Sun, 28 Jan 2001, Paweł Kołodziej wrote:
> > [..]
> > > > Przy okazji w wuchu nie działa jesze i18n bo w kilku miejscach trzaba
> > > > będzie poprzerabiać nieco źródła.
> > > 
> > > Moglbys przyblizyc jakiego typu zmiany sa jeszcze konieczne ?
> > 
> > W każdym pliku który będzie miał ciagi znaków podlegające
> > umiędzynarodowieniu na pocżatku sekcji dołączanych plikół nagłóewkowych
> > trzeba bezie dodać:
> > 
> > #include <config.h>
> > 
> > i na końcu:
> > 
> > #include "defines.h"
> 
> na końcu pliku ???

 .. no na końcu obecnej sekwencji z #include :)

[..]
> > W razie czego parser powinno się dać napisać w kilku linijkach
> > flexa/yacca.
> 
> Mozna. Ale czy warto ? Jakos nie widze zastosownia do makr.
> No chyba że przewidujesz ogormny rozwoj tego programu...

Jeżeli będzie nam zależeć na obciążęniu pamieci to libfl.a ma:

$ ls -l /usr/lib/libfl.a
-rw-r--r--    1 root     root         1764 cze 19  2000 /usr/lib/libfl.a
                                      ^^^^
Kilka przykładów tego typu rzeczy widziałem w kilku miejscach i bazujac na
tym nie powinno być trudno coś takiego zmontować (wczoraj chyba widziałem
parser z czymś podobnym w mwm w lesstifie choć nie pamietam dokładnej
definicji tego jakie funkcjonalności miała mieć obsługa tego pliku :).

[..]
> > Moze co najwyżej zawierać kilka funkcji które bęnda
> > użyteczne dla modułów.
> 
> Jakiego typu moduły widzisz (przegladanie, instalacja pakietów,
> konfiguracja sieci, demonow ??? tego typu ?)

O całkiem sporo. Presizer do zakładania wolumenów na dostepnych dyskach,
konfigurator do miedzymordzi sieciowych, tuneli itd., zarządzanie fontami,
konfigurator do drukarek - tu generalnie chodziłoby o kilka modułów które
są realizowane przez różne kawałki pakietów z RH (w tym sensie nawet
łatwiej nawet byłoby to napisać), potem takze inne moduły jakie są
realizowane przez LC czy webmina. Na pewno jednym z pierwszych potrzabnych
modułów byłby moduł do zarządzania konf FW.
Do dobrego wykorzystania spraw zwiazanych z zarządzaniem po SNMP też
przydałby sie jakiś moduł do konfigurowania agenta SNMP czy np. moduł do
zarządania konf amandy (automat do backupów jaby ktoś nie wiedział).

Łazi mi też po głowie oprócz engine znakowego i graficznego (pod FB czy
X11) także wersja która umożliwiałaby używanie funkcji zawartych w
modułach czysto wsadowo gdzie to co miałby byść zmodyfikowane/wygenerowane
w konf byłoby podawane w linii poleceń (w końcu obecny wuch też ma funkcje
wsadowego/non-interactiv upgrade :). O .. wyobraźnie w tym temacie to mogę
mieć bogatą ;_) Z rzeczy które nie musiałbym wymyślać to np. przy dużej i
barzo dużej ilosci dysków np. przydałoby sie narzędzia jakie zapewne zna
ktokolwiek kto zetknął się z metadev na Solku do zarządzania konf RAID
(IMHO genitalne narzędzie bez którego niwyobrażam sobie bezpiecznego
grzebania w konf RAID przy ilości dysków większej niż kilknaście, a miałem
już okazję grzebać w konf gdzie było fizycznych dysków ponad dwieście
.. bajdełejem ciekaw jestem czy Linux obecnie tyle by już udźwignął :).

Tak wogóle właśnie nasuwa mi się na czoło to, że .. kto wie czy obsługa
miedzymordzia (curses, wsadowego, FB, X11) nie mogłaby być także w module
:) (?) co pozwoliłoby zachować zapewn małe/ultra małe rozmiary całej
czapy.

Tak czy inaczje to jest absolutna przyszłość/dalsza perspektywa nad którą
można bąć nie sie zastanawiać (bo akurat jest juz taki czas że można to
wreszcie zacząć robić :). Na razie wartoby sie skupić na obecnych
funkcjach wucha majac pod czaszką te wszystkie perspektywy (a moze jeszcze
i inne ?) po to żeby być może całość szła w tym kierunku czy też
przynajmniej nie przeszkadzała w ramach prac na najbliżesze kilak miesięcy
w realizacji kiedyś zarysu jaki z powyższego sie wyłania. Skompletowanie
tych wszystkich pomysłów wyobrażam sobie nie inaczej jak ewolucyjnie .. w
miarę wzrostu potrzeb i możliwości. Mówiąc inaczej wersja wuchaw kilku
najbliśzych wersjach wcale nie musi iść stricte w powyższym kierunku ..
wystarczy żeby porządkowała zaplecze API do takiej formy żeby potem
odpowiednie przekształcenie w coś bardziej ogólnego było możliwe. Poprostu
powyższe o tylko Chciejstwa w najgorszym tego słowa znaczeniu. Nawet nie
wiem czy i jakie obciażenie na rozmiar kodu będzie wnosić
wprowadzenie/sprawdzanie poszczególnych kawałków idei. To wszystko po
części będzie wymagało kilku eksperymentów czy przybliżeń. Być może w
trakcie okaże sie że jest wogóle nierealne .. choć podskórnie czuję, że
jednak jest możliwe w formie którą zaakceptować byłoby w stanie naprawdę
dużo ludzi :_)

[..]
> > Nie wiem czy nie przydałoby sie tu coś wątkowego co sprawdzałoby w wątku
> > zależności tego co zostało zaznaczone i resztą w razie czego raportujące w
> > osobnym okienku jakieś wydażenia (głośno myślę).
> 
> Tzn. że ktoś zaznacza jakis pakiet, i juz od tego momentu rozpoczyna się
> w tle procedura wyszukiwania zaleznosci ? Jakoś nie jestem przekonany.

Ano. Chodzi o niemarnowanie czasu. Nie zastanawiałem sie nad tym czy jest
to realne ale może warto się nad tym kilka minut zastanowić (w razie czego
pomysł do kosza czy do odłozenia na lepsze czasy).

Jeszcze jeden pomysł. Po instalacji modułu pakiet go instalaujacji mógłby
wykonywać w %post "killall -HUP wuch || :" żeby uruchomione wuchy mogły
przeczytać ponownie dostepna lisę modułów. Umożliwiłoby to np. taki trik
jaki jest zdaje sie w instalatorze Caldery (nie miałem okazji go oglądać
"własnorecznie" ale troche na temat tego narzędzia czytałem i słyszałem),
że w trakcie instalacji pakietów na osobnym terminalu/w osobnym okienku
jest już możliwe konfigurowanie tego co jest już zainstalowane (IMHO
bardzo sprytna funkcjonalność). Czapa na moduły mogłaby mieć specjalny
tryb pracy w którym po otrzymaniu -HUP dokładałaby sobie do kolejki moduł
w którym użytkownik musiałby coś interakcyjnie zrobić (choćby zatwierdzić
konfigurację jaka jest w danym momencie po to żeby bez pytanai skończyć
pracę z całoscią).

> Na razie poza przyśpieszweniem (Jeśłi dzisiejszy patch malekitha na rpm'a
> dziala, to IMHO powinien zostać jak nakszybciej wrzucony do dystrybucyjnego
> rpm'a a ten wyslany na buildery -- umożliwi to _znaczace_ przyśpieszenie
> zależności w wuchu'). Poza tym pozostaje kwestia pokazania userowi do
> wyboru kilku pakietow np. demonow smtp -- tu niestety tez pez poprawki w 
> rpm'ie sie nie obejdzie.

IMHO w rpm-ie jest jeszcze do dorobienie też pole Priority/Urgency: z
domyślną wartościa normal i w razie czego możliwym do wstawienia importand
(AKA securyty update). Możliwość wyszukiwania i instalcji o ile
Priority/Urgency = importand bylaby bardzo cenna. Może zreszta ilość
poziomów mogłaby być zreszta większa niż dwa.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*