On Fri, 9 Jan 2004, Adrian Siemieniak wrote: > On Fri, 9 Jan 2004 07:44:06 +0100 (CET) > Grzegorz Szyszlo <[EMAIL PROTECTED]> 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.
