Re: dystrybucje debiana
On Fri, 9 Jan 2004, Adrian Siemieniak wrote:
> On Fri, 9 Jan 2004 07:44:06 +0100 (CET)
> Grzegorz Szyszlo <znik@wbc.lublin.pl> wrote:
>
> > 1. bezpieczenstwem (security oficjalnie wspiera tylko stable)
> Z tego co obserwuje (naprawde juz dlugo) - to czesciej pakiety
> poprawione wychodza w unstable niz w security - "dziury" oglasza sie gdy
> juz jest na nie lekarstwo (zazwyczaj)
tak, to jest prawda. ale jak sie pojawia dziura w danej paczce,
jest sprawdzany odpowiednik w paczce w edycji stabilnej.
przeciez tam chlopaki nie siedza na laurach.
> > 2. update lub upgrade moze sie rozsypac
> Moim zdaniem siedzenie na "woodym" wynika z lenistwa i niczego wiecej.
dla nie-leniwych zawsze jest do dyspozycji slackware. wszystko trzeba
robic recznie, recznie szukac nowych paczek, recznie kompilowac.
fajna dystrybucja :)
ale ja masochista nie jestem, dlatego wybralem debiana.
zreszta swego czasu przeszedlem na niego z redhata.
znik.
> Po pierwsze NAWET jesli chodzi o uslugi serwerowe woody jest daleko z
> tylu do tego co obecnie jest dostepne (a nie sa to jakies super
> nowoczesnosci - tylko wiele rzeczy jest oczekiwanych w takich php,
> postgresql, firebird czy mysql) - nie pomne tutaj desktopow.
ja sobie z tego doskonale zdaje sprawe. na desktopie zdarza mi sie
postawic testing. prawde mowiac ciezko mi jest z woodym,
bo potrzebuje perla 5.8 , python 2.3 i postgresa 7.3 lub 7.4 ,
nowego ZOPE, nowego Xservera. i dobrze wiem ze tego nie mam w woodym.
dlatego w takich przypadkach po prostu *musze* walczyc
z huraganem pakietow jaki jest w sarge/sid , albo uzywam
remake paczek do woodego. w krytycznych przypadkach
sciagam zrodlowe wersje programow i instaluje.
> Sporo razy sie zawiodlem na "upgradzie" debiana stable do wersji
> nowszych stable lub unstable - po prostu jak sie ma baze postgresa z
> kilkuset urzytkownikami i bazami to migracja o cale 2 numerki jest
> CHOLERNIE klopotliwa - przy robieniu tego malymi kroczkami jest znacznie
> latwiej.
alez o tym wiem. dlatego bede robil w przyszlosci tylko jeden
krok, upgrade z woodego do sarge. a przeniesienie danych
pomiedzy wersjami poszczegolnych aplikacji czy serwisow
to zupelnie inny problem, dobrze ze wspomniales o postgresie.
> > 3. jakies paczki moga wogole przestac dzialac
> Oczywiscie TAK - ale po to jest sie adminem/geekiem czy czym sie chce by
> umiec to naprawic - to sa TYLKO paczki.
problem w tym, ze czlowiek jest tylko czlowiekiem, a np. ja mam bardzo
ograniczony czas by zajmowac sie adminowaniem. sila wyzsza.
jak do tej pory woody a wczesniej potato istotnie przyczynil sie do tego,
ze mialem czas na bardziej istotne sprawy niz grzebanie sie w zrodlach
i walczenie z zaleznosciami. zreszta ja uzywam woodego od momentu
zanim sie jeszcze zaczal stabilizowac, ale sila rzeczy takie uzywanie
bylo okupione wiekszym nakladem pracy w roli admina. to samo jest
teraz w sarge.
> Powiem tak - w 2,5 letniej histori "unstable" na serwerach w roznych
> firmach zdarzyla sie jedna wpadka dosc niefajna (ponad 2l temu libc6 sie
> sypnelo w jednym wydaniu i bylo naprawde duzo problemow by ratowac
> system)
no wlasnie. dlatego ja w takich przypadkach na jednej maszynie instaluje
dwa razy linuxa. pierwszy to z reguly jest jakis stable, malutki,
tekstowy, pelni funkcje ostatniej deski ratunku, i systemu do
odpalania offline backup calosci. drugi system, docelowy,
jest niestabilny. przed updateami backupuje go jak jest polozony,
i w razie czego mam mozliwosc odzyskania calosci sprzed update.
taka cene place z jednej strony za utrzymanie stabilnosci, z drugiej
za uzywanie testing/unstable.
> oraz ostatnio walniety apache (przy przejsciu na osobne configi
> dla modulow) i obecnie php4-gd2. Ale te wszystki bledy to jedynie wina
> paczek i wystarczy gora 1h by je zniwelowac - dlatego mam prosty sposob.
ja niestety mam taki problem, ze czesto nie mam po prostu czasu na
myslenie, i latwiej jest mi zrzucic 1h pracy na maszyne niz grzebanie
w systemie. w tym czasie moge sie zajac czyms innym. po prostu jak
stwierdze ze cos jest walniete, to tego elementu nie updateuje i czekam
na developerow az rozwiaza problem.
> Wpierw wszystko aktualizauje na komputerze robocznym (gdzie sa testowane
> nowe wynalazki - nie mowie tutaj o "nowych paczkach") - a pozniej
> upgrade leci po serwerach.
nie mam takiego komfortu. nie mam drugiej maszyny do testowania.
ale musze przyznac ze twoj model uzywania testing/unstable do celow
produkcyjnych tez jest dobry, pod wieloma wzgledami nawet lepszy.
> Swoja droga pewnie wielu z Was bedzie mialo inne zdanie, ale dla mnie
> aktualizacja serwerow ma cykl 1-2 tygodniowy. Zapewne dla wiekszosci to
> bedzie bardzo czesto - ale rowniez takie podejscie ma naprawde WIELE
> zalet - i przy umiejetnosci "przewidywania" i naprawiania pakietow -
> strasznie malo wad.
no tak. ale na cos takiego mozna sobie pozwolic, jak jest sie tylko
adminem i w zasadzie nikim wiecej.
> Aha - co by wyjasnic - istnieje pewien typ serwerow ktory bez problemow
> moze chodzic na woodym - sa to maszyny na ktorych system jest tylko
> sprawa "rozruchowa" dla glownej funkcji systemu - oraz jesli dostep do
> systemu jest scisle ograniczony (np. do jednej aplikacji).
glownie takich systemow uzywam.
dzieki za polemike :) znik.
Reply to: