http://www.winntmag.com/Articles/Index.cfm?ArticleID=5048

Ale wiem i tak, ze niektorzy ajatollahowie linuxa nie odpowiedza w ogole.
Ale dobrze, z rzeczami oczywistymi sie nie dyskutuje...

Pozdrawia,
Przemek

Ktos sie pytal o rzeczowy artykul na ten temat. Prosze bardzo, dobry,
merytoryczny artykul.

http://www.winntmag.com/Articles/Index.cfm?ArticleID=5048

Ale wiem i tak, ze niektorzy ajatollahowie linuxa nie odpowiedza w ogole.
Ale dobrze, z rzeczami oczywistymi sie nie dyskutuje...

Dla Lukasza: jest cos o kernel reentrancy nawet.... read() i write() nie sa
reentrant a to podstawa wlasnie, o jaka kupa.... A ze nie wyszla, coz nikt
nie robil testow linuxa na 4ro procesorowych maszynach. Polecam fragment co
robi serializacja funkcji w jadrze na przykladzie konkurowania wydajnosci
sieciowe Solarisa z NT:

"NT's write function for network I/O was reentrant except for the part of
the function that NIC drivers (network device interface
specification-NDIS-drivers) handled, wherein they transfer data to their
network hardware. Making this small part of the entire write function
non-reentrant was enough to prevent NT from competing effectively with Sun's
Solaris OS on enterprise applications executing on 4-way multiprocessors. To
remedy the situation, Microsoft let NDIS drivers have deserialized, or
reentrant, write paths in NT 4.0 Service Pack 4 (SP4) and Windows 2000
(Win2K). In Linux 2.2, several functions, in addition to read and write, are
still not reentrant, and each time a Linux server application uses such a
function, the function's non-reentrancy hampers multiprocessor scalability."

Oj boli.

Podsumowanie:
"Linux is not engineered with enterprise computing in mind, nor has the OS
been present in enterprise environments where administrators, programmers,
and users can notice its limitations"

Solaris i Win2K Server daja rade, linux ssie z limitami w kernelu.

Pozdrawiam
Przemek

Ktos sie pytal o rzeczowy artykul na ten temat. Prosze bardzo, dobry,
merytoryczny artykul.

W teorii. Stos TCP Solarisa choĂŚ jest "wielowÂątkowy", ma masĂŞ innych wad,
miêdzy innymi zasobo¿ernoœÌ (bufory zaalokowane na jedno po³¹czenie pod
Solarisem zajmujÂą bodajrze 8 razy wiĂŞcej niÂż pod Linuksem, co przy
du¿ej iloœci po³¹czeù znakomicie zjada RAM) i w praktyce E4500 z
czterema prockami i 8GB RAMu radzi sobie gorzej z paroma tysiÂącami
przychodz¹cych po³¹czeù na minutê, ni¿ marny pojedynczy PIII 550 MHz
z 1GB RAMu pracujÂący pod kontrolÂą Linuksa z kernelem 2.2

| Ktos sie pytal o rzeczowy artykul na ten temat. Prosze bardzo, dobry,
| merytoryczny artykul.

poza tym, autor caly czas popelnia jeden zasadniczy blad, twierdzac,
jakoby wydajnosc serwerowa byla uzalezniona od efektywnych watkow.
otoz tak _nie jest_, przynajmniej nie w systemach posiadajacych fork(2).

| http://www.winntmag.com/Articles/Index.cfm?ArticleID=5048

| Ale wiem i tak, ze niektorzy ajatollahowie linuxa nie odpowiedza w ogole.
| Ale dobrze, z rzeczami oczywistymi sie nie dyskutuje...

Dla chetnych i kumatych (tak Lukaszu D, do Ciebie tez, hehe ;): wyjasnienie
terminu 'completion ports' w dzialce asycnchronous i/o (czegos czego w

linuxie w ogole nie ma badz raczkuje ) Jedna z prob implementacji na linuxie
to KAIO zrobione przez SGI, jak widac pryszcate promaisty byly za slabe. W

aplikacjach bazodanowych z kontrolerem SCSI dalo to 35% wieksza wydajnosc.
Wiec jednak jest to potrzebne, nie bez kozery team Win2K Server + SQL Server
jest nie do pobicia w testach TPC. Tylko nie mowcie, ze skoro jest
nieblokujace i/o to oznacza to ze  i asynchroniczne. Niestety nie....

Dla Lukasza: jest cos o kernel reentrancy nawet.... read() i write() nie sa
reentrant a to podstawa wlasnie, o jaka kupa.... A ze nie wyszla, coz nikt

nie robil testow linuxa na 4ro procesorowych maszynach. Polecam fragment co

[..]

Podsumowanie:
"Linux is not engineered with enterprise computing in mind, nor has the OS
been present in enterprise environments where administrators, programmers,
and users can notice its limitations"

Solaris i Win2K Server daja rade, linux ssie z limitami w kernelu.

Ktos sie pytal o rzeczowy artykul na ten temat. Prosze bardzo, dobry,
merytoryczny artykul.

Ktos sie pytal o rzeczowy artykul na ten temat. Prosze bardzo, dobry,
merytoryczny artykul.

http://www.winntmag.com/Articles/Index.cfm?ArticleID=5048

Ale wiem i tak, ze niektorzy ajatollahowie linuxa nie odpowiedza w ogole.
Ale dobrze, z rzeczami oczywistymi sie nie dyskutuje...

Przemek

Ktos sie pytal o rzeczowy artykul na ten temat. Prosze bardzo, dobry,
merytoryczny artykul.

http://www.winntmag.com/Articles/Index.cfm?ArticleID=5048

Ale wiem i tak, ze niektorzy ajatollahowie linuxa nie odpowiedza w ogole.

Ale dobrze, z rzeczami oczywistymi sie nie dyskutuje...

Andrzej

Ktos sie pytal o rzeczowy artykul na ten temat. Prosze bardzo, dobry,
merytoryczny artykul.

http://www.winntmag.com/Articles/Index.cfm?ArticleID=5048

Ale wiem i tak, ze niektorzy ajatollahowie linuxa nie odpowiedza w ogole.
Ale dobrze, z rzeczami oczywistymi sie nie dyskutuje...

pozdrawiam
qdlaty

| Ktos sie pytal o rzeczowy artykul na ten temat. Prosze bardzo, dobry,
| merytoryczny artykul.
Sprzed trzech lat.

| Ktos sie pytal o rzeczowy artykul na ten temat. Prosze bardzo, dobry,
| merytoryczny artykul.
| Sprzed trzech lat.
Zdezaktualizował się? Które z zawartych w nim informacji są już
nieaktualne?

Popraw mnie, ale tam jest chyba o kernelu 2.2, gdzy już od jakiegoś
czasu mamy "real stable" 2.4.18.

Oczywiście fakt, że człowiek pisze o kernelu 2.2 to drobiazg bez
znaczenia?

Kernel 2.2 jest nieaktualny.

OK, a widziałeś coś większego, i co ważniejsze dotyczącego z jednej
strony: całości funkcjonalności jądra a z drugiej  może jednak 2.4?
(tak tylko pytam. Z tezą tego tekstu trochę cięzko polemizować, zresztą,
podobnie z autorem ;-).

| Kernel 2.2 jest nieaktualny.

Ale za to stabilny.

ps. I nie odsylaj mnie do czytania listy, czytam i wlasnie _dlatego_ pytam.

problem w tym, ze nieco historyczny. wiekszosc pracy nad 2.4 skupiala
sie wlasnie na skalowalnosci i innych 'enterprise features'. problemy
takie jak wakeup_one, kiepski locking czy niepotrzebne kopiowanie
danych przy sendfile(2) od pewnego czasu sa nieaktualne. (wlasciwie
z jednym wyjatkiem - braku mozliwosci doczepienia naglowka do danych
wysylanych w ten sposob, przez co z jednego wywolania systemowego
robia sie dwa. na szczescie szybkie sprawdzenie czasu wykonywania
odpowiednich funcji na windows nt i linuksie upewniaja w przekonaniu,
ze linux moglby spokojnie pozwolic sobie na jeszcze jednego syscalla
i nadal byc szybszy. ;-)

asynchroniczne i/o musial zrobic SGI bo to co bylo zrobione to partanina
(jakies slave threads w userlandzie, kaszana do kwadratu)

Dalej:
"Linux version 2.4.15 contained a bug that was arguably worse than the VM
bug. Essentially, if you unmounted a file system via reboot -- or any
another common method -- you would get filesystem corruption. A fix, called
kernel 2.4.16, was released 24 hours later."

I to jest powazne robienie kernela ? To jakas dzecinada za przeproszeniem.
Caly rok kernel ktory mial status 'stable' byl tak naprawde unstable i do
bani. Smieszne i zalosne w porownaniu do rozwoju kernela np. FreeBSD.

Jak widac kernele 2.4 zanaja sie tylko do desktopow lub jakis light-serwerow
bo twarde zwieszki jeszcze sie zdarzaja. Porownywanie do kernela 2.2 jest
jak najbardziej uzasadnione gdyz reszta to gruszki na wierzbie.

poza tym, autor caly czas popelnia jeden zasadniczy blad, twierdzac,
jakoby wydajnosc serwerowa byla uzalezniona od efektywnych watkow.
otoz tak _nie jest_, przynajmniej nie w systemach posiadajacych fork(2).

nie wiem czy wiesz, ale 'pryszczaci' to mit wymyslony przez WO. wiekszosc
developerow kernela ma sporo lat i gdzies - sgi, ibm, redhat - pracuje.
wiekszosc z nich ma calkiem spore doswiadczenie z systemami operacyjnymi.

kolejny przyklad, ze autor byl dosc nowy w unixach. nieblokujace i/o
ma z cech wspolnych z asynchronicznym jedynie podobna nazwe, co jest
dosc oczywiste dla kazdego, kto zrozumial mana.

w 2.2 moze nie byly. nie jestem historykiem.

jakis czas temu ktos podawal przyklad benchmarkow 2.4 na maszynach
szesnastoprocesorowych. w kwestii httpd skalowal sie prawie liniowo.

zadanie domowe: poszukaj informacji o tux2. potem wklej tu jakies
porownanie wydajnosci tego z windows nt i wytlumacz, dlaczego windows
jest takie wolne. w szczegolnosci odnies sie do poronionego pomyslow
zorganizowania calego i/o systemie w jako-tako-asynchroniczne irp'y.

co rozumiesz przez 'jako-tako-asynchroniczne irp'y'

Pozdrawiam
Przemek

| OK, a widziałeś coś większego, i co ważniejsze dotyczącego z jednej
| strony: całości funkcjonalności jądra a z drugiej  może jednak 2.4?
| (tak tylko pytam. Z tezą tego tekstu trochę cięzko polemizować, zresztą,
| podobnie z autorem ;-).

tak tak, ale 2.4 to dalej ma chorobki wieku dzieciecego...

| Oczywiście fakt, że człowiek pisze o kernelu 2.2 to drobiazg bez
| znaczenia?

Oczywiście. Bo możesz mieć 2.4 ale będzie stabilne inaczej.

Marcin Wieczorek  "T-1000"  DELPHI FAQ http://delphi.cartall.com.pl

W twojej wyobraźni.

| W twojej wyobraźni.

jak na razie to zes sie do _zadnego_ argumentu rzeczowo nie odniosl.

Czy w
ogole wiesz o czym tu jest mowa czy jest to dla Ciebie zbior pustych
sloganow ?

| W twojej wyobraźni.

| jak na razie to zes sie do _zadnego_ argumentu rzeczowo nie odniosl.

Ciężko się odnieść do czegoś, co nie zaistniało.

: Oczywiście. Bo możesz mieć 2.4 ale będzie stabilne inaczej.

s/będzie/być może &/ albo szukaj wysokiego stołu, żebyś
nie musiał się za bardzo męczyć... ;)))

| W twojej wyobraźni.

| jak na razie to zes sie do _zadnego_ argumentu rzeczowo nie odniosl.

| Ciężko się odnieść do czegoś, co nie zaistniało.

Hehe, jasne, prawda w oczy kole. Powiedz mi co we wspomnianym artykule 'nie
zaistnialo' ?

| Kernel 2.2 jest nieaktualny.

| Ale za to stabilny.

Skad wiesz?

| problem w tym, ze nieco historyczny. wiekszosc pracy nad 2.4 skupiala
| sie wlasnie na skalowalnosci i innych 'enterprise features'. problemy
| takie jak wakeup_one, kiepski locking czy niepotrzebne kopiowanie
| danych przy sendfile(2) od pewnego czasu sa nieaktualne. (wlasciwie
| z jednym wyjatkiem - braku mozliwosci doczepienia naglowka do danych
| wysylanych w ten sposob, przez co z jednego wywolania systemowego
| robia sie dwa. na szczescie szybkie sprawdzenie czasu wykonywania
| odpowiednich funcji na windows nt i linuksie upewniaja w przekonaniu,
| ze linux moglby spokojnie pozwolic sobie na jeszcze jednego syscalla
| i nadal byc szybszy. ;-)

Smiem watpic. maly cytat z pisma LinuxWorld: 'For large servers, the 2.4
kernel has been a disaster.' Dziekuje.

sync() bug ktory byl obecny az do 2.4.6

2.5 VM Implementation: totalna kupa.

I Ty mowisz ze pisze o jakis starociach ? Artykul traktuje o stabilnym
jadrze linuxa, 2.2 wielu ludzi uzywa w serwerach (serwerach != maszynkach
podlaczonych do sdi i majacych mySQLa)

asynchroniczne i/o musial zrobic SGI bo to co bylo zrobione to partanina
(jakies slave threads w userlandzie, kaszana do kwadratu)

Dalej:
"Linux version 2.4.15 contained a bug that was arguably worse than the VM
bug. Essentially, if you unmounted a file system via reboot -- or any
another common method -- you would get filesystem corruption. A fix, called
kernel 2.4.16, was released 24 hours later."

I to jest powazne robienie kernela ? To jakas dzecinada za przeproszeniem.
Caly rok kernel ktory mial status 'stable' byl tak naprawde unstable i do
bani. Smieszne i zalosne w porownaniu do rozwoju kernela np. FreeBSD.

Jak widac kernele 2.4 zanaja sie tylko do desktopow lub jakis light-serwerow
bo twarde zwieszki jeszcze sie zdarzaja. Porownywanie do kernela 2.2 jest
jak najbardziej uzasadnione gdyz reszta to gruszki na wierzbie.

| poza tym, autor caly czas popelnia jeden zasadniczy blad, twierdzac,
| jakoby wydajnosc serwerowa byla uzalezniona od efektywnych watkow.
| otoz tak _nie jest_, przynajmniej nie w systemach posiadajacych fork(2).

Jakies dowody moze ?

| nie wiem czy wiesz, ale 'pryszczaci' to mit wymyslony przez WO. wiekszosc
| developerow kernela ma sporo lat i gdzies - sgi, ibm, redhat - pracuje.
| wiekszosc z nich ma calkiem spore doswiadczenie z systemami operacyjnymi.

Pryszcate lub nie (chociaz przewinal sie jakis 18telni gosc z Brazylii) ale

realizacja aio w userladnzie wytknal tym (juz w ") "pryszcatym" SGI.

| kolejny przyklad, ze autor byl dosc nowy w unixach. nieblokujace i/o
| ma z cech wspolnych z asynchronicznym jedynie podobna nazwe, co jest
| dosc oczywiste dla kazdego, kto zrozumial mana.

Nie kazdy jednak zrozumial mana skoro autor wspomnanego artykulu otrzymal
sporo listow od 'fanuf' linuxa na ten temat.

| w 2.2 moze nie byly. nie jestem historykiem.

Ale badaczem gruszek na wierzbie moze ;)

| jakis czas temu ktos podawal przyklad benchmarkow 2.4 na maszynach
| szesnastoprocesorowych. w kwestii httpd skalowal sie prawie liniowo.

A jak ze stabilnoscia ?

| zadanie domowe: poszukaj informacji o tux2. potem wklej tu jakies
| porownanie wydajnosci tego z windows nt i wytlumacz, dlaczego windows
| jest takie wolne. w szczegolnosci odnies sie do poronionego pomyslow
| zorganizowania calego i/o systemie w jako-tako-asynchroniczne irp'y.

tux2 - nowy filesystem (organizacaj danych), co to ma do reszty ?

co rozumiesz przez 'jako-tako-asynchroniczne irp'y'

| OK, a widziałeś coś większego, i co ważniejsze dotyczącego z jednej
| strony: całości funkcjonalności jądra a z drugiej  może jednak 2.4?
| (tak tylko pytam. Z tezą tego tekstu trochę cięzko polemizować, zresztą,
| podobnie z autorem ;-).

tak tak, ale 2.4 to dalej ma chorobki wieku dzieciecego...

Artykuł odnosi się do historii, nie współczesności, a twoje pozostałe
"argumenty" nie odnoszą się do niczego.

: Oczywiście. Bo możesz mieć 2.4 ale będzie stabilne inaczej.
s/będzie/być może &/ albo szukaj wysokiego stołu, żebyś
nie musiał się za bardzo męczyć... ;)))

| Kernel 2.2 jest nieaktualny.
| Ale za to stabilny.
Skad wiesz? Przeczytales na stronie www.microsoft.com czy wiesz z
doswiadczenia?

Oto kolejny etyczny post Lecha:
| : Oczywiście. Bo możesz mieć 2.4 ale będzie stabilne inaczej.
| s/będzie/być może &/ albo szukaj wysokiego stołu, żebyś
| nie musiał się za bardzo męczyć... ;)))
Problemy z jądrem 2.4 są faktem.

To, że akurat u kogoś nie pada nie znaczy,
że nagle stało się stabilne tylko, że akurat nie trafiłeś na błąd w jądrze.

przy okazji:
wlasnie mialem okazje zobaczyc jak wyglada ogladanie demek pod win98
(polecam ftp://ftp.pl.scene.org). po kilku restartach (czarny ekran,
klawiatura nie dziala) dalem sobie spokoj (tak wiem ze to sie robi
pod dosem)

i jeszcze jedno mi sie nasunelo:
czy jest pod windowsem jakis program w stylu linuxowego 'crashme'?
"crashme generates strings of random bytes and then attempts to execute
them. Used to test kernel stability"

chetnie pomeczylbym tym 2k i xp-a :D
ja sobie robilem taki test ze puszczalem kompilacje jadra w kolko +
mp3 + kilka programow w opengl-u + mozilla z wlaczonym reloadowaniem
losowych stron + wlasnie crashme i tak przez iles godzin.
nie udalo sie go zawiesic.

A ja przekonałem się na własnej skórze. W czasa pierwszych 2.2, na
dwuprocesorowym serwerze, który obsługiwał komercyjnych klientów
Onetu. W sumie to do końca swego żywota chodził na 2.0. Tyle że 2.0
miało beznadziejną obsługę SMP.

:  "stabilności inaczej" 2.4. Stąd wnoszę, że 2.2 jest dużo stabilniejsze niż
:  2.4. Może faktycznie samo "stabilny" było zbyt mocnym stwierdzeniem.

W tej chwili 2.4.x (x 17) jest równie stabilne jak 2.2.x (x 11, bodajrze).

Użytkownik "Bartlomiej Lidke"

tylko prosze mi nie mowic
ze to wina sprzetu bo na tym samym chodzi bezblednie debian)

W tej chwili 2.4.x (x 17) jest równie stabilne jak 2.2.x (x 11, bodajrze).

: Oto kolejny etyczny post Lecha:
:: Oczywiście. Bo możesz mieć 2.4 ale będzie stabilne inaczej.
:s/będzie/być może &/ albo szukaj wysokiego stołu, żebyś
:nie musiał się za bardzo męczyć... ;)))
:
: Problemy z jądrem 2.4 są faktem. To, że akurat u kogoś nie pada nie znaczy,
: że nagle stało się stabilne tylko, że akurat nie trafiłeś na błąd w jądrze.

Marcinie, zastąp napisy "jądrem 2.4" i "jądrze" napisem "Windows",
a otrzymasz stwierdzenie o wartości logicznej takiej samej, jak
przed zastąpieniem. Naprawdę. Są bardzo padliwe wersje 2.4.x, są
i mało padliwe. Jeśli chodzi o moje własne doświadczenia, to
ostatni pad, jaki pamiętam (używam -ac), miał miejsce bodajże
we wtorek i zawdzięczam go próbie jednoczesnego użycia AGPx2,
Quake3 i mplayera z CVS-u. Daty poprzedniego padu nie pamiętam,
ale AFAIR zdarzył się w zimie.

Czy kernel 2.4 jest bezbłedny? Nie. Czy zazwyczaj sypie się
jak drzewiej śnieg w zimie? Nie. Czy może się wysypać? Tak.

:  "stabilności inaczej" 2.4. Stąd wnoszę, że 2.2 jest dużo
:  stabilniejsze niż 2.4. Może faktycznie samo "stabilny" było zbyt
:  mocnym stwierdzeniem.
W tej chwili 2.4.x (x 17) jest równie stabilne jak 2.2.x (x 11,
bodajrze).

To z 2.2.x też są TAKIE problemy?

zalezy co rozumiemy pod pojeciem 'problemy'. jade na serii 2.4 od jej
zarania do 2.4.18 z przeskokiem co kilka numerkow. trafilem na ta
felerna wersje ktora nie robila synca ale w 5 minut sobie to
naprawilem (recznie sync i flush dysku w skryptach robiacych reboot i
halt). akurat windowsy w kwestii uszkadzania systemow plikow sa
lepsze. pare lat temu na sobie to przezylem: moj dysk z 95 i fat
zostal wlozony do kompa w98 i fat32. no wiec jak win98 bez pytania
(!!!) zaczal mielic moim dyskiem to stracilem ok 30% zawartosci

co do stabilnosci to nie moge nic zarzucic (a dosc ostro wykorzystuje
komputer: od oracla, db2 przez openoffice'y, lyx-y az do gier). chodzi
bezblednie. czego np. o NT ktore mam w pracy nie moge powiedziec
(srednio raz na miesiac/dwa niebieski ekran - tylko prosze mi nie
mowic ze to wina sprzetu bo na tym samym chodzi bezblednie debian)

przy okazji:
wlasnie mialem okazje zobaczyc jak wyglada ogladanie demek pod win98
(polecam ftp://ftp.pl.scene.org). po kilku restartach (czarny ekran,
klawiatura nie dziala) dalem sobie spokoj (tak wiem ze to sie robi
pod dosem)

i jeszcze jedno mi sie nasunelo:
czy jest pod windowsem jakis program w stylu linuxowego 'crashme'?
"crashme generates strings of random bytes and then attempts to
execute them. Used to test kernel stability"

chetnie pomeczylbym tym 2k i xp-a :D
ja sobie robilem taki test ze puszczalem kompilacje jadra w kolko +
mp3 + kilka programow w opengl-u + mozilla z wlaczonym reloadowaniem
losowych stron + wlasnie crashme i tak przez iles godzin.
nie udalo sie go zawiesic.

Marcinie, zastąp napisy "jądrem 2.4" i "jądrze" napisem "Windows",
a otrzymasz stwierdzenie o wartości logicznej takiej samej, jak
przed zastąpieniem. Naprawdę. Są bardzo padliwe wersje 2.4.x, są
i mało padliwe. Jeśli chodzi o moje własne doświadczenia, to
ostatni pad, jaki pamiętam (używam -ac), miał miejsce bodajże
we wtorek i zawdzięczam go próbie jednoczesnego użycia AGPx2,
Quake3 i mplayera z CVS-u. Daty poprzedniego padu nie pamiętam,
ale AFAIR zdarzył się w zimie.

I have experienced massive file system corruption on my main computer
after installing Woody and upgrading the kernel to 2.4.18-686-smp
(2.4.18-5). The filesystems were ext3. Hardware is an ABit BP6.

Czy kernel 2.4 jest bezbłedny? Nie. Czy zazwyczaj sypie się
jak drzewiej śnieg w zimie? Nie. Czy może się wysypać? Tak.

| I have experienced massive file system corruption on my main computer
| after installing Woody and upgrading the kernel to 2.4.18-686-smp
| (2.4.18-5). The filesystems were ext3. Hardware is an ABit BP6.
TAKICH problemów z Win2k to ja nie pamiętam. Możesz wskazać błąd w Win2k o
podobnej wadze?

   I have encountered a reproducible NTFS file corruption problem
   under Windows 2000 Professional (build 2195). The corruption has
   occurred several times on three different Dell XPS T600r systems.
   An identical system running Windows NT 4.0 SP5 has not encountered
   the problem.

Ja też nie pamiętam takich problemów co nie wyklucza ich istnienia
(nie mówię, że nie miał wogóle ale nie większe niż miałem z W2k).

| I have experienced massive file system corruption on my main computer
| after installing Woody and upgrading the kernel to 2.4.18-686-smp
| (2.4.18-5). The filesystems were ext3. Hardware is an ABit BP6.
TAKICH problemów z Win2k to ja nie pamiętam. Możesz wskazać błąd w Win2k o
podobnej wadze?

   I have encountered a reproducible NTFS file corruption problem
   under Windows 2000 Professional (build 2195). The corruption has
   occurred several times on three different Dell XPS T600r systems.
   An identical system running Windows NT 4.0 SP5 has not encountered
   the problem.

Ja też nie pamiętam takich problemów, co oczywiście nie wyklucza ich
istnienia (nie mówię, że nie miałem żadnych problemów, ale napewno nie
większe niż z W2k).

| I have experienced massive file system corruption on my main computer
| after installing Woody and upgrading the kernel to 2.4.18-686-smp
| (2.4.18-5). The filesystems were ext3. Hardware is an ABit BP6.

| TAKICH problemów z Win2k to ja nie pamiętam. Możesz wskazać błąd w Win2k o
| podobnej wadze?

   I have encountered a reproducible NTFS file corruption problem
   under Windows 2000 Professional (build 2195). The corruption has
   occurred several times on three different Dell XPS T600r systems.
   An identical system running Windows NT 4.0 SP5 has not encountered
   the problem.

Ja też nie pamiętam takich problemów, co oczywiście nie wyklucza ich
istnienia (nie mówię, że nie miałem żadnych problemów, ale napewno nie
większe niż z W2k).

nawiasem mowiac, raporty o tajemniczych padach ntfs, powodujacych
znieksztalcenie metadanych teoretycznie niemozliwe do zaistnienia
zdarzaja sie od zawsze. taki 'bugreport-widmo' ;-)

Artykuł odnosi się do historii, nie współczesności, a twoje pozostałe
"argumenty" nie odnoszą się do niczego.

[....]

Ciekawe czy ktos na to odpowie, ajatollachowie sa glusi na argumenty, tak
samo jak na fakty przytoczone z LinuxWorld.

To znaczy ? Problemy z "zamrażaniem" notebooka, które są silnie zalezne od
modelu, oops w eksperymentalnym module usbnet i jakies jaja ze niektórymi
sterownikami IDE. To maja byc przykłady niestabilności kernela ? Kiepskie.
Dla każdego systemu można coś takiego wyszukać.

   I have encountered a reproducible NTFS file corruption problem
   under Windows 2000 Professional (build 2195). The corruption has
   occurred several times on three different Dell XPS T600r systems.
   An identical system running Windows NT 4.0 SP5 has not encountered
   the problem.

"The Dell systems contain Promise Ultra66 controllers and 20Gig
Maxtor ATA66 7200 RPM hard drives. Our MIS group suspects the
Promise controllers."

Na złe sterowniki żaden system nie poradzi.

Nie mogę, bo ani nie używam W2k, ani nie mam wystarczająco bliskiego
kontaktu z tymi, którzy używają; u nas w fabryce u juzerii nadal
AFAIR króluje NT. Być może nikt nie doświadczył takiego problemu.
Ja np. używam i ext2, i ext3...

 15:53 [lech(pts/27)$/home/lech7]
 /dev/sdb5 on / type ext2 (rw)
 none on /proc type proc (rw)
 none on /dev/pts type devpts (rw,gid=5,mode=620)
 /dev/sdb6 on /usr type ext2 (rw)
 /dev/sdb7 on /home type ext2 (rw,nosuid,usrquota,grpquota)
 /dev/sdb8 on /var type ext2 (rw,usrquota,grpquota)
 /dev/sdb9 on /tmp type ext2 (rw,nosuid,nodev,usrquota,grpquota)
 /dev/sda12 on /home/lech7/mnt/sda12 type ext3 (rw)
 /dev/sda13 on /home/lech7/mnt/sda13 type ext3 (rw)
 /dev/sda14 on /home/lech7/mnt/sda14 type ext3 (rw)
 /dev/sda6 on /home/lech7/mnt/sda6 type ext3 (rw)

...i nie doświadczyłem żadnych przykrości z tym związanych.
Co nie znaczy, że ext3 nie było w pewnym momencie walnięte,
bo AFAIR istotnie było i nie ma co zaprzeczać.

Sporo zależy także od faktu, że kolejne wersje i łaty na kernel
są dostępne każdemu w sieci. Gdyby udostępniano je tak często,
jak SP do Windows, problemy w rodzaju opisanego powyżej miałyby
przynajmniej o rząd wielkości mniejszą szansę się zdarzyć.

:Czy kernel 2.4 jest bezbłedny? Nie. Czy zazwyczaj sypie się
:jak drzewiej śnieg w zimie? Nie. Czy może się wysypać? Tak.
: Kwestia skali. Pewnie 2.2 też ma jakieś błędy ale na niego nie słychać aż
: takich narzekań jak na 2.4.

Także kwestia zakresu możliwości ("ilości featur", jak to się
określa w nowomowie).

Sporo zależy także od faktu, że kolejne wersje i łaty na kernel
są dostępne każdemu w sieci. Gdyby udostępniano je tak często,
jak SP do Windows, problemy w rodzaju opisanego powyżej miałyby
przynajmniej o rząd wielkości mniejszą szansę się zdarzyć.
:Czy kernel 2.4 jest bezbłedny? Nie. Czy zazwyczaj sypie się
:jak drzewiej śnieg w zimie? Nie. Czy może się wysypać? Tak.
: Kwestia skali. Pewnie 2.2 też ma jakieś błędy ale na niego nie
: słychać aż takich narzekań jak na 2.4.
Także kwestia zakresu możliwości ("ilości featur", jak to się
określa w nowomowie).

: Wersje parzyste miały być stabilne (czytaj: dużo bardziej stabilniejsze niż
: nieparzyste).

Sądzę, że są.

: Może deweloperzy kernela powinni wziąć przykład z Debiana -
: rzadsze ale lepiej przetestowane wersje jądra dawałyby jakąś pewność
: użytkownikom.

Nikt nie każe nikomu używać wersji sprzed trzech godzin tylko dlatego, że
można jej użyć, bo jest dostępna. Naprawdę. Ja na lechu używam czasem
właśnie tych "sprzed trzech godzin", ale maszyny produkcyjne, którymi
administruję, nie działają na takich. Choćby dlatego, że żebym uznał daną
wersję za przetestowaną, powinna przetrwać (działając na lechu) znacznie
więcej niż te trzy godziny :)

: Ten kto chce nowych możliwości może korzystać z wersji testowych (na
: własne ryzyko) a reszta ma do dyspozycji może i okrojone ale za to
: stabilne jądra.

Jest taka dobra zasada "nie naprawiaj tego, co działa". Po prostu
należy ją zastosować. Zgodnie z nią, pewne maszyny, którymi się
opiekuję, używają jeszcze (o ile inne uwarunkowania na to pozwalają)
kernela 1.3.59.

ladnie sie chlopaki bawia w 'robienie' systemu 'enterprise'. Oby tak dalej i
krzyz im na droge. Na router do SDI/Neostrady ewentualnie VPNa sie nadaje,
reszta to niezla smiechawka ....

Wersje parzyste miały być stabilne (czytaj: dużo bardziej stabilniejsze niż
nieparzyste). Może deweloperzy kernela powinni wziąć przykład z Debiana -
rzadsze ale lepiej przetestowane wersje jądra dawałyby jakąś pewność
użytkownikom. Ten kto chce nowych możliwości może korzystać z wersji
testowych (na własne ryzyko) a reszta ma do dyspozycji może i okrojone ale
za to stabilne jądra.

znana regula jest tez instalowac jadra, ktore sa na rynku co najmniej
miesiac - w koncu to jest wlasnie model testowania Linusa - niech ludzie
zrobia to sami

rozsadni admini stosuja sie do tych regul i nie maja problemow

dla przykladu u nas na wydziale chodzi (dla wszystkich pracownikow inst.
informatyki) serwer della od prawie czterech lat; 4 procesory, sporo ramu,
sporo dyskow w roznych raidach; zaczynalismy gdy SMP dopiero raczkowalo;
teraz jest tam 2.4.costam

nigdy nie mielismy powaznych klopotow, serwer jest dostepny 24/7 od grudnia
1998; jedyny istotny przestoj (2 dni) byl sprzetowy

robert

: Wersje parzyste miały być stabilne (czytaj: dużo bardziej
: stabilniejsze niż nieparzyste).
Sądzę, że są.

: Może deweloperzy kernela powinni wziąć przykład z Debiana -
: rzadsze ale lepiej przetestowane wersje jądra dawałyby jakąś pewność
: użytkownikom.
Nikt nie każe nikomu używać wersji sprzed trzech godzin tylko dlatego,
że można jej użyć, bo jest dostępna. Naprawdę. Ja na lechu używam
czasem właśnie tych "sprzed trzech godzin", ale maszyny produkcyjne,
którymi administruję, nie działają na takich. Choćby dlatego, że żebym
uznał daną wersję za przetestowaną, powinna przetrwać (działając na
lechu) znacznie więcej niż te trzy godziny :)

: Ten kto chce nowych możliwości może korzystać z wersji testowych (na
: własne ryzyko) a reszta ma do dyspozycji może i okrojone ale za to
: stabilne jądra.
Jest taka dobra zasada "nie naprawiaj tego, co działa". Po prostu
należy ją zastosować. Zgodnie z nią, pewne maszyny, którymi się
opiekuję, używają jeszcze (o ile inne uwarunkowania na to pozwalają)
kernela 1.3.59.

Również można znaleźć w google wiele opisów problemów z W2k - czy to
znaczy, że Windows nie nadaje się na system dla przedsiębiorstw ?

Wersje parzyste miały być stabilne (czytaj: dużo bardziej stabilniejsze niż
nieparzyste). Może deweloperzy kernela powinni wziąć przykład z Debiana -
rzadsze ale lepiej przetestowane wersje jądra dawałyby jakąś pewność
użytkownikom. Ten kto chce nowych możliwości może korzystać z wersji
testowych (na własne ryzyko) a reszta ma do dyspozycji może i okrojone ale
za to stabilne jądra.

--c 8 szt. * 2.4

Dla mnie (użytkownika 1.3/1.9x, 2.0, 2.1, 2.2, 2.3 i 2.4) nie.
A przynajmniej nie w istotny sposób.

: Wersje "stabilne" są chyba przed wypuszczeniem testowane na realnych
: maszynach z realnym obciążeniem, prawda?

Są (pomijając kwestię dyskusji o znaczeniu napisu "realne obciążenie").
Ale shit happens, a przyjęcie takiego, a nie innego modelu wypuszczania
nowych wersji niesie ze sobą takie, a nie inne konsekwencje.

: Poza tym ja nie mam dwóch komputerów z Linuksem i mimo, że nie zależy od
: ich sprawności moje życie to wolałbym abym po zmianie kernela na nowszy
: "stabilny" nie miał problemów.

To zmieniaj dopiero wtedy, kiedy będziesz potrzebował (a nie - tak, jak
np. ja na lechu - jak masz kaprys).

: Jak słusznie zauważyłeś nowe jądra niosą nową funkcjonalność. Inaczej nie
: byłoby sensu ich pisać.

Wiele maszyn obywa się dobrze bez tej nowej fukcjonalności. Tam
pozostaje w zasadzie wyłącznie kwestia bezpieczeństwa (pominąwszy
oczywiście ewentualny brak zgodności z nowymi wersjami programów,
które chce się tam zainstalować, ale w odniesieniu do "2.2 vs 2.4"
ten problem prawie nie istnieje).

developerka linuksa ma wiele brakow, np. brak testow (co jest moim
konikiem akurat); stabilniejsze sa jajka ac

znana regula jest tez instalowac jadra, ktore sa na rynku co najmniej
miesiac - w koncu to jest wlasnie model testowania Linusa - niech
ludzie zrobia to sami
rozsadni admini stosuja sie do tych regul i nie maja problemow

: ac?

Łaty Alana Coxa.

: Poza tym nie chcesz chyba powiedzieć, że jądra parzyste przed
: publikacją nie są testowane na realnym sprzęcie?

Nieparzyste też są.

Developerzy? Mają wyrównać w dół i wypuszczać nową wersję raz
na kilka lat? :)

To jest wybór użytkowników. Świadomy i nie przymuszony w przypadku
rozsądnego doboru sprzętu. Ja się stosuję i nie mam problemów.

| Również można znaleźć w google wiele opisów problemów z W2k - czy to
| znaczy, że Windows nie nadaje się na system dla przedsiębiorstw ?
Znajdź. Powtarzalne, poważniejsze od literówek w menu, powodowane przez
system a nie sterownik lub wadliwy sprzęt.

(Taki wątek można chyba prowadzić w nieskończoność...)

| Developerzy? Mają wyrównać w dół i wypuszczać nową wersję raz
| na kilka lat? :)

Jeśli nie potrafią wypuszczać wersji stabilnych częściej to zdecydowanie
TAK.

| To jest wybór użytkowników. Świadomy i nie przymuszony w przypadku
| rozsądnego doboru sprzętu. Ja się stosuję i nie mam problemów.

OK. Wybór między wersją stabilną i nie. Tylko, że jeśli wersja stabilna nie
jest stabilna to wyboru nie ma.

Które jaja są w takim razem stabilne w sensie gwarancji stabilności?
Pewnie się komuś narażę, ale za takie uważam te, które wypuszcza
redhat w dystrybucjach *.1, a najlepiej *.2 :-)

--c

| developerka linuksa ma wiele brakow, np. brak testow (co jest moim
| konikiem akurat); stabilniejsze sa jajka ac

ac? Poza tym nie chcesz chyba powiedzieć, że jądra parzyste przed
publikacją nie są testowane na realnym sprzęcie?

sa testy i testy

wszystko jest testowane, ale slabo; zreszta takie jest zalozenie - finalne
testy wykonuja chetni do ryzyka uzytkownicy; przeciez nie mowimy o bledach
elementarnych, ktore wyjad w unit testach, tylko o kombinacjach
konfiguracja/sprzet ktora powoduje klopot

| znana regula jest tez instalowac jadra, ktore sa na rynku co najmniej
| miesiac - w koncu to jest wlasnie model testowania Linusa - niech
| ludzie zrobia to sami
| rozsadni admini stosuja sie do tych regul i nie maja problemow

Ja to rozumiem ale powyższe powinno się odnosić do wersji nieparzystych.
Jak już sobie chętni i odważni betatesterzy potestują to jądro powinno być
publikowane jako stabilne. Wtedy jeśli akurat jest mi potrzebne
USB/SMP/łotewer mogę to "stabilne" jądro wziąć i używać wiedząc, że KTOŚ je
wcześniej przetestował. IMHO po to właśnie jest rozróżnienie między
wersjami parzystymi i nieparzystymi.

chyba o tym, jak zrozumiales procedury zarzadzania wersjami linuksa

zle zrozumiales

rober

:Developerzy? Mają wyrównać w dół i wypuszczać nową wersję raz na kilka
:lat? :)
: Jeśli nie potrafią wypuszczać wersji stabilnych częściej to zdecydowanie
: TAK.

Ale dlaczego? Jak ktoś jest ZU, to instaluje system z płytki
z dystrybucją - a o obecność tamże przetestowanego kernela
ma zadbać ten, kto wypuszcza dystrybucję. Jak ktoś ma chęć
robic takie eksperymenty, jak ja na lechu, to... to ma, co
chciał i powinien mieć świadomośc tego, w co się pakuje.

: ac?
Łaty Alana Coxa.

: Poza tym ja nie mam dwóch komputerów z Linuksem i mimo, że nie zależy od
: ich sprawności moje życie to wolałbym abym po zmianie kernela na nowszy
: "stabilny" nie miał problemów.
To zmieniaj dopiero wtedy, kiedy będziesz potrzebował (a nie - tak, jak
np. ja na lechu - jak masz kaprys).

Rozróżnienie na jądra stabilne i testowe nie zostało wprowadzone z
powietrza. Ludzie chcą móc mieć zaufanie do software'u bez przeprowadzania
własnych, dogłębnych testów. Podchodzenie do wersji parzystych jądra tak
jak do testowych (a to jest podejście jakie proponujesz) sprawdza się może
w ekstremalnych warunkach gdy od pracy serwera naprawdę wiele zależy ale
nie na codzień.

Zresztą muszę to tłumaczyć? Przecież 2.4.0 to było któreś
2.3.xx, przecież nagle z dnia na dzień nie zrozbiło się z niestabilnego
stabilne. Źle interpretujesz te określenia tych gałęzi.

Ale oczywiście mogę przyjąć, że nie ma żadnego oficjalnego jądra nazywanego
stabilnym.

Które jaja są w takim razem stabilne w sensie gwarancji stabilności?
Pewnie się komuś narażę, ale za takie uważam te, które wypuszcza
redhat w dystrybucjach *.1, a najlepiej *.2 :-)

developerka linuksa ma wiele brakow, np. brak testow (co jest moim
| konikiem akurat); stabilniejsze sa jajka ac
| ac? Poza tym nie chcesz chyba powiedzieć, że jądra parzyste przed
| publikacją nie są testowane na realnym sprzęcie?
?

sa testy i testy
wszystko jest testowane, ale slabo; zreszta takie jest zalozenie -
finalne testy wykonuja chetni do ryzyka uzytkownicy; przeciez nie
mowimy o bledach elementarnych, ktore wyjad w unit testach, tylko o
kombinacjach konfiguracja/sprzet ktora powoduje klopot

| Ja to rozumiem ale powyższe powinno się odnosić do wersji
| nieparzystych. Jak już sobie chętni i odważni betatesterzy potestują
| to jądro powinno być publikowane jako stabilne. Wtedy jeśli akurat
| jest mi potrzebne USB/SMP/łotewer mogę to "stabilne" jądro wziąć i
| używać wiedząc, że KTOŚ je wcześniej przetestował. IMHO po to właśnie
| jest rozróżnienie między wersjami parzystymi i nieparzystymi.
nie wiem o czym piszesz
chyba o tym, jak zrozumiales procedury zarzadzania wersjami linuksa
zle zrozumiales

http://groups.google.com.pl/groups?q=2.4.18+kernel+problem+lockup&hl=...
ie=UTF-8&oe=UTF-8&selm=linux.kernel.200207181744.NAA24845%40mc-pc.research.t
elcordia.com&rnum=2

http://groups.google.com.pl/groups?q=2.4.18+kernel+problem+lockup&hl=...
ie=UTF-8&oe=UTF-8&selm=1020029262.13018.7.camel%40athlon&rnum=7

http://groups.google.com.pl/groups?hl=pl&lr=&ie=UTF-8&oe=UTF-8&selm=2...
161133.GA10091%40buici.com

http://groups.google.com.pl/groups?q=2.4.18+kernel+problem+lockup&sta...
l=pl&lr=&ie=UTF-8&oe=UTF-8&selm=200203041706.g24H6Kv25543%40klee.iskp.uni-bo
nn.de&rnum=12

http://groups.google.com.pl/groups?q=2.4.18+kernel+problem+lockup&sta...
l=pl&lr=&ie=UTF-8&oe=UTF-8&selm=f371e9ba.0207220801.12358d13%40posting.googl
e.com&rnum=14

http://groups.google.com.pl/groups?q=2.4.18+kernel+problem+lockup&sta...
l=pl&lr=&ie=UTF-8&oe=UTF-8&selm=1024740346.682402%40ampungk.ozonline.com.au&
rnum=17

ladnie sie chlopaki bawia w 'robienie' systemu 'enterprise'.

windows nt, z drugiej strony, rzekomo przystosowany do zastosowan
'enterprise', dorobilo sie quoty dyskowej dopiero w wersji 5.0. iirc
nawet wtedy ktos 'zapomnial' o przydzieleniu quoty nie tylko na ilosc
zajmowanych blokow, ale takze metadanych. nei sadze, aby taki blad mogl
popelnic _ktokolwiek_ rozumiejacy podstawowe zasady administrowania
serwerem. w sumie specjalnie mnie to nie dziwi - po tym, jak zobaczylem
wczesne wersje directx, 'zaprojektowane' przez osobe najwyrazniej
nie majacej zielonego pojecia nie tylko o programowaniu gier, ewentualnie
dem, ale praktyce programowania _w ogole_, nic mnie juz nie zdziwi.

http://groups.google.com.pl/groups?q=2.4.18+kernel+problem+lockup&hl=...
ie=UTF-8&oe=UTF-8&selm=linux.kernel.200207181744.NAA24845%40mc-pc.research.t
elcordia.com&rnum=2

[....]

Ciekawe czy ktos na to odpowie, ajatollachowie sa glusi na argumenty, tak
samo jak na fakty przytoczone z LinuxWorld.

co do linuxworld - ten artykul opisywal wczesne 2.4. obecnych wersji
to nie dotyczy. sorry, winnetou, linux rozwija sie 'nieco' szybciej,
niz windows. zreszta nie tylko w kwestiach czysto serwerowych,
czego przykladem moze byc chociazby mplayer.

: Wersje "stabilne" są chyba przed wypuszczeniem testowane na realnych
: maszynach z realnym obciążeniem, prawda?

Są (pomijając kwestię dyskusji o znaczeniu napisu "realne obciążenie").

oczywiscie kazda pojedyncza zmiana jest 'jakos' testowana.

: A to przepraszam. Ja testowanie systemu rozumiem jako m.in. uruchamianie
: go na różnych maszynach o możliwie zróżnicowanej konfiguracji. Czy tego
: się nie robi przed wypuszczeniem wersji "stabilnej"?

Od "vendor kernels" można tego oczekiwać, ale dla "vanilla" owe "testy"
oznaczają po prostu, że po wypuszczeniu ostatniego -pre nikt nie zgłosił
przez pewien czas żadnych dyskwalifikujących zastrzeżeń.

:: ac?
:Łaty Alana Coxa.
: Skoro tyle dają to dlaczego nie są od razu w jądrze?

W skrócie/uproszczeniu: bo -ac to właśnie jest poligon,
testujący to, co potem trafia (albo nie) do "vanilla".
Poniżej przykładowy fragment announce/changelog:

===

Subject: Linux 2.4.20-pre2-ac3

 [+ indicates stuff that went to Marcelo, o stuff that has not,
 * indicates stuff that is merged in mainstream now, X stuff that proved
   bad and was dropped out, - indicates stuff not relevant to the main tree]

The HP merge is now down to 3503 lines pending

Ok this is the next chunk of IDE merges. There is still a lot of cleaning
up to be done. You'll see that various stuff is now tagged FIXME. Its all
so far long standing stuff or ugly code things that were in the old
code too. The goal is to make the IDE code both really clean and really
correct. Nevertheless this is a lot of IDE code shuffling. Handle with
care treat as test for the moment. This -ac patch isnt recommended on
your critical database server 8)

Linux 2.4.20-pre2-ac3
o       IDE updates                                     (Andre Hedrick)
o       Merge -ac fixes for ALi and PCI bars            (me)
o       Add docs to PIIX and ALi                        (me)

Linux 2.4.20-pre2-ac2
o       Updates to device mapper                        (Joe Thornber)
o       Fix mempool corruption bug                      (Christoph Hellwig)
o       Correct pci_alloc_consistent with 64bit mask    (Steffen Persvold)
+       Elevator accounting improvements                (Jens Axboe)
o       Clean up vt.c ioperm ifdef even more            (Milton Miller)
o       Fix PAGE_BUG usage problem                      (Eyal Lebedinsky)
o       Tweak isdn to try and fix gcc 2.95 compile      (Kai Germaschewski)
o       Make parameter variables on synclink* static    (me)
o       Add documentation to jbd layer                  (Roger Gammans)
-       NFSD link fix                                   (Greg Louis)
+       Fix NFS oops on 64bit big endian                (Dave Miller)
+       Add another vaio to the dmi blacklist           (Marc Boucher)
+       Fix devfs enabled build                         (Christoph Hellwig)
o       Fix resource assignment for cardbus behind      (H J Lu)
        pci transparent bridges
o       Fix makefile for speakup a bit                  (O Sezer)
+       Update ftd_sio driver                           (Greg Kroah-Hartmann)
+       Update usb serial Config.in                     (Greg Kroah-Hartmann)
+       Fix error handling on ipaq usb serial           (Greg Kroah-Hartmann)
+       Update pl2303 usb serial                        (Greg Kroah-Hartmann)
+       Fix usb serial warnings in gcc3                 (Greg Kroah-Hartmann)
+       Fix gcc3 warnings in ir-usb                     (Greg Kroah-Hartmann)
+       Fix DMA off stack in USB storage                (Roland Dreier)
+       Add SDDR-55 USB storage driver                  (Greg Kroah-Hartmann)
+       Fix gcc3 warnings and other bugs in usb btooth  (Greg Kroah-Hartmann)
+       HP usb scanner driver                   (Oliver Neukum, John Fremlin,
                                                        Matthew Dharm)
+       Update usb scanner driver                       (Greg Kroah-Hartmann)
===

| developerka linuksa ma wiele brakow, np. brak testow (co jest moim
| konikiem akurat); stabilniejsze sa jajka ac
| ac? Poza tym nie chcesz chyba powiedzieć, że jądra parzyste przed
| publikacją nie są testowane na realnym sprzęcie?
| ?

Co to są "jajka ac"?

| sa testy i testy
| wszystko jest testowane, ale slabo; zreszta takie jest zalozenie -
| finalne testy wykonuja chetni do ryzyka uzytkownicy; przeciez nie
| mowimy o bledach elementarnych, ktore wyjad w unit testach, tylko o
| kombinacjach konfiguracja/sprzet ktora powoduje klopot

Właśnie o tym mówię.

o testach wymagajacych kilku milionow konfiguracji?

to w linuksie, bsd, etc. robia pomagajacy end-luserzy;
w zasadzie jest to beta-testing

| Ja to rozumiem ale powyższe powinno się odnosić do wersji
| nieparzystych. Jak już sobie chętni i odważni betatesterzy potestują
| to jądro powinno być publikowane jako stabilne. Wtedy jeśli akurat
| jest mi potrzebne USB/SMP/łotewer mogę to "stabilne" jądro wziąć i
| używać wiedząc, że KTOŚ je wcześniej przetestował. IMHO po to właśnie
| jest rozróżnienie między wersjami parzystymi i nieparzystymi.
| nie wiem o czym piszesz
| chyba o tym, jak zrozumiales procedury zarzadzania wersjami linuksa
| zle zrozumiales

A to przepraszam. Ja testowanie systemu rozumiem jako m.in. uruchamianie go
na różnych maszynach o możliwie zróżnicowanej konfiguracji. Czy tego się
nie robi przed wypuszczeniem wersji "stabilnej"?

jesli przez "stabilna" rozumiesz parzysty minor numeru, to
oczywiscie beta testy robi sie na buildach tak numerowanych

natomiast do stabilnej pracy rekomenduje sie releasy o konkretnych numerach,
o ktorych wiadomo po beta-testach ze maja malo groznych bledow

zreszta nie jestem ekspertem od procedur Linusa i Coxa; nie sadze tez,
zeby mialo duzo sensu objasniac je w tej formie w jakiej to robimy

jesli jestes ciekaw, poczytaj; jesli masz jakas teze i chciales ją pokazac -
powiedz wyraznie o co Ci chodzi

robert

| Zresztą muszę to tłumaczyć? Przecież 2.4.0 to było któreś
| 2.3.xx, przecież nagle z dnia na dzień nie zrozbiło się z niestabilnego
| stabilne. Źle interpretujesz te określenia tych gałęzi.

Zrobiło, właśnie poprzez nieustanne poprawianie wersji nieparzystej. Gdy
już nie ma żadnego znanego błędu do poprawki można kod wypuścić jako
stabilny. Oczywiście nie jest to stabilność 100% bo pewnie jakieś błedy tam
są. Problem leży w tym aby o jak największej liczbie błędów się dowiedzieć
- a temu służą testy.

Ale oczywiście mogę przyjąć, że nie ma żadnego oficjalnego jądra nazywanego
stabilnym.

falsyfikacja tezy jest prosta - np. jadro 2.4.7 jest uwazane za bardzo
stabilne (i jest to najnowsze o tak wysokim stopniu przetestowania i
stabilnosci) - i jest stosowane np. do zastosowan przemyslowych

robert

... and Marcin "T-1000" Wieczorek disseminated foul capitalist
propaganda:
| Również można znaleźć w google wiele opisów problemów z W2k - czy to
| znaczy, że Windows nie nadaje się na system dla przedsiębiorstw ?
| Znajdź. Powtarzalne, poważniejsze od literówek w menu, powodowane
| przez system a nie sterownik lub wadliwy sprzęt.

(Taki wątek można chyba prowadzić w nieskończoność...)

Ale dlaczego? Jak ktoś jest ZU, to instaluje system z płytki
z dystrybucją - a o obecność tamże przetestowanego kernela
ma zadbać ten, kto wypuszcza dystrybucję.

Jak ktoś ma chęć
robic takie eksperymenty, jak ja na lechu, to... to ma, co
chciał i powinien mieć świadomośc tego, w co się pakuje.

Trudno jest mi zrozumieć Twoją postawę. Nie traktujesz jako stabilnej
żadnej wersji jądra, której sam nie przetestujesz. Czy do każdego rodzaju
software'u tak podchodzisz czy tylko do systemu?

: Swiat nie dzieli się tylko na ZU instalujących RH z CHIPA i zaawansowanych
: administratorów sieci. Jest całe spektrum użytkowników którzy chcieliby
: skorzystać z nowych właściwości jądra nie obawiając się o stabilność
: systemu.

Jest również całe spektrum dziewic, które chciałyby sobie troche
po[censored] i nadal pozostać dziewicami. I co z tego?

:Jak ktoś ma chęć
:robic takie eksperymenty, jak ja na lechu, to... to ma, co
:chciał i powinien mieć świadomośc tego, w co się pakuje.
:
: Już mi wytłumaczono, że nie ma czegoś takiego jak stabilne jądro linuksowe

Nie ma również czegoś takiego, jak "stabilne jądro <tu-nazwa-systemu".
Są tylko jądra zwane stabilnymi.

: ale tak na logikę to "eksperymenty" kojarzą mi się raczej z jądrem
: testowym.

Pomijając nawet kwestię praktycznej niemożliwości pełnego
odpluskwienia nietrywialnego programu, jeśli liczba kombinacji
zestawów sprzętu jest jest tego rzędu, co w przypadku pecetów,
to przetestować nawet znaczącej części konfiguracji nijak się
nie da.

: Wtedy bym się z Tobą zgodził. Instalując parzystą wersję jądra powinienem
: mieć pewien komfort wynikający z wcześniejszego, dogłębnego jej
: przetestowania przez deweloperów.

I takowy komfort masz, znacząco większy niż w przypadku
jąder określanych jako "development".

: Trudno jest mi zrozumieć Twoją postawę. Nie traktujesz jako stabilnej
: żadnej wersji jądra, której sam nie przetestujesz. Czy do każdego rodzaju
: software'u tak podchodzisz czy tylko do systemu?

Do każdego. Nie mam zwyczaju instalować nowych wersji tylko
dlatego, że są nowe. A systemy, którymi administruje, mają
zazwyczaj coś takiego, co się zowie "systemem testowym"
(albo są wystarczająco redundantne, żeby istniału możliwości
przeprowadzenia testów działania danego softu w naszych
specyficznych warunkach/zastosowaniach)...
Jeśli gdzieś (vide lech) instaluję coś nowego tylko po to,
żeby obejrzeć, co to jest to nowe i co właściwie to nowe
mi da, to nie dziwię się, jeśli czasem muszę odtwarzać
coś z kopii bezpieczeństwa/zapasowych. Wystarczająco wiele
lat zarabiałem programując, żeby wiedzieć, jakie są szanse
stworzenia bezbłednych programów bez długiego cyklu testowania :)

Udowodnij, że przytoczone przez Ciebie przykłady są powodowane przez system
a nie sterowniki lub wadliwy sprzęt.

Zrobiło, właśnie poprzez nieustanne poprawianie wersji nieparzystej. Gdy
już nie ma żadnego znanego błędu do poprawki można kod wypuścić jako
stabilny. Oczywiście nie jest to stabilność 100% bo pewnie jakieś błedy tam
są. Problem leży w tym aby o jak największej liczbie błędów się dowiedzieć
- a temu służą testy.

Ale oczywiście mogę przyjąć, że nie ma żadnego oficjalnego jądra nazywanego
stabilnym.

Nie wiem co tam sobie Linus czy inny maintainter ogłasza- jeśli jakieś ogłasza
stabilnymi to są to jądra oficjalnie uznane za stabilne przez Linusa czy tego
kogoś.  Ja stosuję jądra oparte o te, które oficjalnie uzna za stabilne
redhat (-ac, w dodatku nie przypadkowo wybrane, ew. z jeszcze dodatkowymi
patchami). Nie przejechałem się jeszcze na tym. Aktualnie. Kiedyś
miałem inaczej, również w każdej chwili mogę zmienić zdanie.

| Które jaja są w takim razem stabilne w sensie gwarancji stabilności?
| Pewnie się komuś narażę, ale za takie uważam te, które wypuszcza
| redhat w dystrybucjach *.1, a najlepiej *.2 :-)

Dlaczego?

--c

jesli jestes ciekaw, poczytaj;

jesli masz jakas teze i chciales ją
pokazac - powiedz wyraznie o co Ci chodzi

Od "vendor kernels" można tego oczekiwać, ale dla "vanilla" owe "testy"
oznaczają po prostu, że po wypuszczeniu ostatniego -pre nikt nie zgłosił
przez pewien czas żadnych dyskwalifikujących zastrzeżeń.

testowania przez ogół. Chciałbym aby wyglądało to tak jak w Windows: czyli
przed wypuszczeniem programu intensywne testy na różnych konfiguracjach.

--c

| jesli jestes ciekaw, poczytaj;

Gdzie?

| jesli masz jakas teze i chciales ją
| pokazac - powiedz wyraznie o co Ci chodzi

Teza jest taka, że jeśli chcę instalować Linuksa to wolałbym z jądrem
stabilnym. Do tej pory sądziłem, że aby być spokojnym wystarczy trzymać się
wersji parzystych. Teraz okazuje się, że są to wersje wypuszczone do
testowania przez ogół. Chciałbym aby wyglądało to tak jak w Windows: czyli
przed wypuszczeniem programu intensywne testy na różnych konfiguracjach.

1. mozesz sie wlaczyc w dowolnej fazie rozwoju produktu
2. beta testing nie konczy sie po wdrozeniu produktu; przeciwnie,
   wtedy dlugosc cyklu zgloszenie bledu / poprawka sie skraca
   (w dowolnej metodologii komercyjnej sie wydluza, a skrocenie
   to jest support 24/7 niesamowicie drogi, oczywiscie)

jesli chcesz cos w miare podobnego do windows, to instaluj gotowe
dystrybucje - nie wiem jaki jest Twoj problem

robert

: zaawansowanych administratorów sieci. Jest całe spektrum użytkowników
: którzy chcieliby skorzystać z nowych właściwości jądra nie obawiając
: się o stabilność systemu.
Jest również całe spektrum dziewic, które chciałyby sobie troche
po[censored] i nadal pozostać dziewicami. I co z tego?

:Jak ktoś ma chęć
:robic takie eksperymenty, jak ja na lechu, to... to ma, co
:chciał i powinien mieć świadomośc tego, w co się pakuje.
:
: Już mi wytłumaczono, że nie ma czegoś takiego jak stabilne jądro
: linuksowe
Nie ma również czegoś takiego, jak "stabilne jądro
<tu-nazwa-systemu". Są tylko jądra zwane stabilnymi.

: ale tak na logikę to "eksperymenty" kojarzą mi się raczej z jądrem
: testowym.
Pomijając nawet kwestię praktycznej niemożliwości pełnego
odpluskwienia nietrywialnego programu, jeśli liczba kombinacji
zestawów sprzętu jest jest tego rzędu, co w przypadku pecetów,
to przetestować nawet znaczącej części konfiguracji nijak się
nie da.

: Wtedy bym się z Tobą zgodził. Instalując parzystą wersję jądra
: powinienem mieć pewien komfort wynikający z wcześniejszego,
: dogłębnego jej przetestowania przez deweloperów.
I takowy komfort masz, znacząco większy niż w przypadku
jąder określanych jako "development".

: Trudno jest mi zrozumieć Twoją postawę. Nie traktujesz jako stabilnej
: żadnej wersji jądra, której sam nie przetestujesz. Czy do każdego
: rodzaju software'u tak podchodzisz czy tylko do systemu?
Do każdego. Nie mam zwyczaju instalować nowych wersji tylko
dlatego, że są nowe.

Jeśli gdzieś (vide lech) instaluję coś nowego tylko po to,
żeby obejrzeć, co to jest to nowe i co właściwie to nowe
mi da, to nie dziwię się, jeśli czasem muszę odtwarzać
coś z kopii bezpieczeństwa/zapasowych. Wystarczająco wiele
lat zarabiałem programując, żeby wiedzieć, jakie są szanse
stworzenia bezbłednych programów bez długiego cyklu testowania :)

Bo ja sobie nie przypominam, żeby ktoś twierdził, że ostatnie
nieparzyste stają się parzystymi po intensywnym testowaniu. Wydaje mi
się, że właśnie takie testowanie zaczyna się przy pierwszym parzystym,
bo dopiero wtedy następuje code freeze i wyłącznie poprawianie bugów
(przynajmniej w teorii, nie śledzę).

A kto je ma oficjalnie ogłosić stabilnym?

Każdy może. Taki model
rozwoju. W sprawie kernela Win decyduje o tym tylko MS. Ale tutaj
każdy może coś ogłaszać, każdy może wypuścić swoją wersję.

Owszem,
zbyt duża możliwość wyboru dla części ludzi jest problemem - nie tylko
w tej dziedzinie życia. Dla takich - jest to wada. Dla mnie nie -
potrafię sobie znaleźć zaufane źródło.

Nie wiem co tam sobie Linus czy inny maintainter ogłasza- jeśli jakieś
ogłasza stabilnymi to są to jądra oficjalnie uznane za stabilne przez
Linusa czy tego kogoś.

Ja stosuję jądra oparte o te, które oficjalnie
uzna za stabilne redhat (-ac, w dodatku nie przypadkowo wybrane, ew. z
jeszcze dodatkowymi patchami). Nie przejechałem się jeszcze na tym.
Aktualnie. Kiedyś miałem inaczej, również w każdej chwili mogę zmienić
zdanie.