O drapaniu się w lewe ucho przez prawe ramię

Po przeczytaniu posta Michała miałem podobne odczucia.

swietny felieton - zadziwiające, ale dokladnie pomyslalem o tej samej anegdocie z olowkiem! No i oczywiscie masz racje, to bug a nie feature.

swietne!

śiwetny felieton

no, no i to jest argument!

A nie lepiej zainstalować na serwie jakiegoś Linuxa albo BSD? Po co marnować kasę na windowsa?

Tylko że temperowanie ołówków w stanie nieważkości to nie jest najlepszy pomysł...

Krótko, właściwie i na temat! Kurczę! :-)

Wielkie brawa dla autora!

samo życie...

jak byłeś kiedyś w IKEA to wiesz, że ołówków można nie temperować... ;)

przychodzi mi na myśl oprogramowanie sklepu internetowego SOTE, oni też wydają produkt z mnóstwem błędów, a jak trochę poprawią(dzięki zgłoszeniom użytkowników) to sprzedają jako nową wersję

Tomku, bardzo fajny artykul i bardzo lekko napisany. Niestety nie znasz wszystkich faktow, ktore przemiawaja za tym, ze korzystam z SMB a nie z innych protokolow. Przykladowo mamy cale mnostwo aplikacji, ktore wymieniaja sie informacjami poprzez SMB i wszystkich nie moge wrzucic do jednego worka z napisem FTP. Przyklad jaki podalem, to jedynie fragment naszych dzialan. Jesli chcesz poznac szczegoly, mozesz sie ze mna skontakowac poprzez blog'a.

Co do FTP to niestety wszystkiego tym sie rozwiaze, ale co do placenia w nowej wersji systemu za naprawienie bledu starego systemu to niestety standard.
Powoli zaczynam zauwazac ze MS celowo robi bledy, sztuczne ograniczenia aby sprzedawac nowe wersje i pisac jacy sa cudowni.

@MikeO - przepraszam, ale Twoj post mowi wylacznie o prostym scenariuszu synchronizacji paczki ZIP miedzy dwoma serwerami i tyle. Co wiecej, jednoznacznie stwierdza, ze to wlasnie poprawienie tej rzeczy stalo sie glownym bodzcem do przygotowania migracyjnego business case - nie wspomina o niczym innym. Komentuje wiec to, co widze :)

@CodeBoy: pewnie, ze za pomoca FTP nie obejdzie sie wszystkich scenariuszy uzycia SMB, chociaz uprę się że całkiem sporo. Niemniej, są jeszcze inne metody - i to nie rsync ;) a np DFSR i uzycie dostepnego w edycji Enterprise mechanizmu RDC (Remote Differential Compression). Tez prostsze i tansze niz migracja do WS2008 ;)

Prawde powiedziawszy podoba mi sie fakt, ze Ty - Tomaszu - pomimo oddania firmie MS potrafisz jeszcze spojrzec obiektywnie na pewne kwestie.
Tak czy owak fakt jest taki, ze wiele sposrod "rewelacji" MS to zadne rewelacje i ... powiedzialbym wiecej: tego typu problemy o niebo lepiej rozwiazuje system *BSD.
Przyklady? Wheel.pl, etc

Ależ to to samo, co np. z iPhonem! Pierwszą wersję sprzedawano bez 3G, chociaż to absurd i idiotyzm w przypadku telefonu. Już wtedy mówiono, że to celowe, aby w wersji drugiej wprowadzić 3G jako nowość i wielki ficzer. I faktycznie. Spora ilość nadzianych lub maniackich posiadaczy pierwszego iPhona kupi go jeszcze raz - w wersji drugiej (a potem trzeciej, czwartej, piątej...).
Nad gigantami softłerowymi wisi już nad głową miecz Damoklesa w postaci Open Software. Ostatnie posunięcie VIA stworzyło już znaczący precedens dla powstania czegoś takiego jak Open Hardware. Myślę że gdzieś, kiedyś Open Hardware rozwijając się, obejmie też smrtphony. ;)

Tak na serio to jedyny dramat całego tego blogowego wpisu, to komentarze:
Jakub: A jakiego protokołu używacie do transportu plików
Michał: nie wiem. Zapytam sie sieciowcow
Oniemiałem.

Ryan, pytajacemu chodzio o to czy uzywamy polaczenia (protokolu) VPN, stad tez byla moja odpowiedz. Informacja w jaki sposob polaczone sa dwie lokalizacje nie jest mi do niczego potrzebna. W ten sposob przesylalbym pliki po VPN czy FastEthernet. Skad zatem Twoje zdziwienie?

MikeO: mysle ze stad, ze jesli ktos grzebie w serwerach brzegowych lub robi jakies plany ich dotyczace, powinien wiedziec jak sa polaczone... jesli nie wie, to... no coz, bez komentarza ;)

@tomekb; A dlaczego mialoby go to interesować? Z punktu widzenia usługi ważne jest dla jej właściciela, czyli Michała, jaki jest adres serwera docelowego i czy jest on dostępny. Z jego punktu widzenia jeden serwer jest wpięty do przełącznika w serwerowni po jednej stronie jeziora (założe się że Michał nawet nie wie gdzie) a drugi po drugiej stronie jeziora ... a co jest pomiędzy to nie jego brocha. Ewentualnie może go interesować jakie ma parametry łącza żeby podtunować TCP\IP ... Tak to wygląda w prawie każdej większej firmie że usługami i siecią administrują różni ludzie.

@Ryan: Masz racje - poziom komentarza jest sredni. VPN to nie protokol a Michal wprost pisze ze SMB. Nie wiem ale strzelam ze pomiedzy nimi jest TCP\IP :)

@tomeko: niby tak, ale mowa tutaj nie o jakichstam serwerach z jakimis tam uslugami, tylko konkretnie o serwerah brzegowych, ktorych jedna z funkcji moze (choc nie musi) byc wlasnie zapewnienie lacznosci miedzy lokalizacjami, wypadaloby wiec robiac jakies plany wiedziec chociazby tyle, czy tunel za wode realizowany jest wlasnie przez te serwery czy przez jakies inne urzadzenia...

Do tego, gdybym to ja odpowiadal za to srodowisko, wolalbym wiedziec takie rzeczy nawet jesli nie bylyby w mojej gestii... wiec rozumiem zdziwienie Ryana faktem, ze kogos moze to nie interesowac ;)

No i poza tym, nawet jesli tego typu rzeczy moga nie interesowac admina do ktorego nalezy waski kawalek infrastruktury, to jesli ktos bawi sie w inzyniera i managera robiac plany biznesowe powinien miec szersze spojrzenie...

@tomekb: Hmmm ... gdybamy sobie, poniewaz ja tez tak jak i Ty nie znamy realiow i szczegolow uslug ktorymi zajmuje sie Michal. Ale jak znam nasze IT i prace Michala to niekoniecznie sa to serwery brzegowe w takim rozumieniu jak Ty to interpretujesz. Jezeli chodzi zas o polaczenia w sieci rozleglej to MS IT utrzymuje "grube rury" i wewnatrz nikt raczej sie nie zajmuje tym jak jego serwer laczy sie gdzies. Ja tez sie nad tym nie zastanawiam gdy siegam do zasobow w Dublinie czy Redmond.

Ale to i tak poboczny temat wiec moze nie warto tego roztrzasac bo odpowiedzi moze udzielic tutaj sensownej tylko Michal.

@tomekb: a kto powiedzial, ze ja odpowiadam za srodowisko? Kto w ogole powiedzial, ze ja jestem adminem? A moze po prostu jestem gosciem, ktory z tych serwerow korzysta i stara sie zoptymalizowac infrastukture IT? Robisz bardzo duzo mylnych zalozen.
Moja odpowiedz na Twoj felieton: http://michal.osmenda.com/2008/06/15/na-skroty-ale...

@MikeO: wnioskowalem tak czytajac zwroty typu "Mój zespół ma pod opieką...", "Efektem optymalizacji było między innymi stworzenie wspomnianej przeze mnie paczki", "nteresował mnie jedynie czas jaki można uzyskać", "Efektem tego testu był business case"... przepraszam, jesli wniosek byl mylny, ze w jakims stopniu odpowiadasz za to srodowisko :)

Co do Twojej odpowiedzi - nie kupuję wyników testow FTP, z moich doswiadczen wynika ze nawet tym FTP wbudowanym w IIS6 mozna maksymalnie wysycic dostepne lacze... moze stosujesz gdzies konfiguracje oparta o zapisywanie plikow na udzialach albo w weekend jednak obciazenie lacza jest wieksze a nie mniejsze niz w tygodniu... a tak czy siak, mozna uzyc innego serwera FTP lub np protokolu HTTP gdzie jeden serwer bedzie sobie WGETowal plik od drugiego, tu juz chyba nie da sie argumentowac ze SMB bedzie nadal bardziej wydajne w takim scenariuszu ;)

@tomekb
Tak czytam tą waszą dyskusję i kilka rzeczy mi się obija po głowie więc może po koleji.

1/ Takie bardziej ogólne pytanie mi się nasuwa do Twoich opinii na temat SMB pomiędzy WIndows 2003 i 2008: czy w każdym przypadku to że jakiś produkt w wersij 2.0 działa lepiej niż w wersji 1.0 oznacza że 1.0 to bubel??? Czyli na przykład - czy fakt że wychodzi wersja 2.0 iPhone, która zawiera w sobie nowe elementy oprogramowania (też) oznacza że wersja 1.0 była skopana i czy nie powinno być tak że w wersji 1.0 powinno dostarczyć się uaktualnienie , które da pełną funkcjonalnośc 2.0 dla tych którzy kupili 1.0 (BTW nie ze nie lubie Apple czy cos ... tylko dokladnie taka dyskusja wlasnie sie zaczela tu i owdzie po tym jak Apple oglosilo v2)?

Problemy z SMB sa znane od czasu Windows NT. Nie wynikaja w wiekszosci z implementacji (chociaz lba sobie nie dam uciac ... tutaj akurat Ty jako MVP miales mozliwosc zajrzenia w kod zrodlowy i sprawdzenia tego). Problemy wynikaly z natury samego protokołu, tego ile komunikatów przesyłał po sieci i jak obsługiwał transmisję. To ogranicza wydajnośc w v1.0.

Czy wersję 2.0 da się portować na WIndows 2003 ? Ty twierdzisz że dałoby się ... i powód dla ktorego tego sie nie robi to sprzedaz W2008. Ja tego nie wiem ... nie znam kodu, nie znam az tak archietktury Windows Server od strony programistycznej itp. Pewnie by sie dalo ... jak to mowil jeden z moich bylych szefow ... nie ma takich rzeczy ktorych sie nie da zrobic. Pytanie tylko jakim nakladem srodkow i jakie by to mialo skutki. Moze o tym tez warto wspomniec piszac w temacie

2/ Dlaczego nie dopuszczasz że testy Michała, w jego środowisku są poprawne - może w tym środowisku tak się to po prostu zachowuje i takie są wyniki??? Proponuje zebys przeprowadzil testy SMB 1.0/2.0, FTP i HTTP (w zasadzie jeszcze SAMBA by sie do tego przydala) przy danych warunkach sieciowych dla takiego zadania i opublikowal wraz z metodologią i wynikami z licznikow i wskaznikow ktorych uzyles. Wtedy bedzie to mozna ocenic. Narazie Michal przedstawil wyniki swoich testow a Ty powiedziales "nie wierze".

3/ Sugerujesz kolejne rozwiązania, tak jakbyś nie wiedział jak odbywa się zarządzanie usługami w dużych organizacjach (i to nie chodzi tylko o MS). W zasadzie to nie mozna sobie ot tak po prostu postawic kolejnych uslug. OK - zmienmy SMB na FTP, postawmy tam ten serwis ... to jest kolejna usluga do monitorowania, musi byc do niej zapewnion operations itp. Wiec moze z tego punktu widzenia wymiany na 2008 jest sensownym rozwiazaniem. Daje zysk na wydajnosci, nie wprowadza dodatkowych zmian do srodowiska, ktore skutowalyby innymi zmianami (jak wyzej, chociazby kwestia operations i monitorowania).

4/ W duzych srodowiskach czesto jest tak, ze nawet jak ktos odpowiada za srodowisko jako usluge, to niekoniecznie odpowiada za srodowisko w rozumieniu - jest administratorem systemu \ sieci itp. To standard. Biznes i IT sa rozdzielone bo tak jest sensownie. Nie wiem czy jest tak w tym przypadku, ale tak moze byc. Po prostu przy jakiejs skali taki podzial zaczyna sie naturalnie.

To w zasadzie takie tam przemyslenia z tej dyskusji mialem ... :)

@tomeko: zaczynasz manipulowac i zupelnie wypaczac caly problem...

"czy w każdym przypadku to że jakiś produkt w wersij 2.0 działa lepiej niż w wersji 1.0 oznacza że 1.0 to bubel???"

Nigdzie czegos takiego nie napisalem, napisalem ze w tym konkretnym przypadku tak jest i dalej to podtrzymuje - SMB w Windows Server 2003 to bubel - zapewnia sprawność na poziomie 2-3% łącza, niby jak to inaczej nazwac? Nie wnikam z czego to wynika, dobrze wiem ze to jeszcze problem z czasow NT, tylko to bez znaczenia - między NT a 2003 trochę czasu upłynęło.

"Czy wersję 2.0 da się portować na WIndows 2003 ? Ty twierdzisz że dałoby się .."

Nigdzie czegos takiego nie stwierdzilem.

"Dlaczego nie dopuszczasz że testy Michała, w jego środowisku są poprawne"

Bo FTP w takich samych warunkach sieciowych ma minimalny overhead w porownaniu z SMB 1.0 i chodzi po prostu szybciej, to wynika z konstrukcji tych protokołów i moich doświadczeń praktycznych. Michal nie wykonal tych testow w takim samym srodowisku, przetestowal transfer po FTP w zupelnie innych warunkach kilka dni pozniej.

"Sugerujesz kolejne rozwiązania, tak jakbyś nie wiedział jak odbywa się zarządzanie usługami w dużych organizacjach (i to nie chodzi tylko o MS). W zasadzie to nie mozna sobie ot tak po prostu postawic kolejnych uslug."

Mysle ze zmiania skryptu odpalajacego robocopy na skrypt odpalajacy wgeta wpisalaby sie jakos elegncko nawet w skomplikowane korpoprocedury ;)

A ja tak obserwuje wasze dyskusje: ) i dajcie sobie spokoj takie dyskusje wygladaja nieelegancko , kazdy ma swoje racje. Proponuje (tak jak tomeko) zeby tomekb zrobil wlasne testy podzielil sie nimi na lamach tego portalu i tyle. (ps nie pracuje w microsofcie) :)

@tomekb
(...) Mysle ze zmiania skryptu odpalajacego robocopy na skrypt odpalajacy wgeta wpisalaby sie jakos elegncko nawet w skomplikowane korpoprocedury ;) (..)

Ten wget wymaga jeszcze serwera WWW po obu stronach do ktorego ten wget sie podepnie, a taki serwer w obecnej konfiguracji moze nie istniec (moze istnieje) i calej otoczki zwiazanej z utrzymaniem tej uslug. To tak na marginesie tylko. I to o czym pisze to nie jest "korpo procedura" tylko rzeczy wynikajace z tego jak sie podchodzi do utrzymania uslug w kazdym wiekszym srodowisku. Bez zachowania pewnych procedur itp po prostu tworzy sie jeden wielki burdel ... zreszta pewnie sam to trenujesz przy zarzadzaniu zmianami w swoim srodowisku wiec nie wiem skad ta ironia.

@MikeO: semantycznie pytanie nie jest jednoznaczne i Twoja interpretacja jest równie dobra jak moja: ja zrozumiałem, że pytał (m.in. - pytanie jest dwuczęściowe) o to, czy kopiujesz po SMB. Poza tym, choć nie lubię się z TomkiemB zgadzać ;-P, pisałeś o serwerach brzegowych. Ale najwyraźniej Release Support Analyst działają na tym samym poziomie abstrakcji co PMi.

@tomeko: autor komentarza pytał o protokół i (jak to ujął) strumień. Ja zrozumiałem, że pytał czy to SMB, Michał odpisał "nie wiem". To mnie zmroziło.

@Ryan
Hmmmm ... tak do tego podchodzac ... jezeli po przeczytaniu artykulu o SMB komentujacy pyta sie czy to SMB ... to nie mam pytan ...

@tomeko: Ludzie mają tendencję do skanowania tekstu a nie dokładnego czytania. :-) Ponadto odnoszę wrażenie, że tekst nie zaznacza wystarczająco wyraźnie, że o SMB chodzi. Podkreśla natomiast obecnie, że to serwery "brzegowe". ;-]

hehe, coz moge powiedziec... Ja zalozylem, ze pytajacy jest sapiens sapiens i domyslilem sie, mimo uzycia slowa protokol, ze chodzi mu o VPN (zreszta nawet i tym wspomnial w nawiasie). Taki nawyk "o co chodzi pytajacemu" wymaga duzo ciepliwosci i pewnej dozy doswiadczenia z roznymi klientami ;)

@Ryan: RSA dzialaja na troche nizszym poziomie niz PMi, choc to jest rownie oderwane od surowego IT. Jestesmy tymi, ktorzy przychodza do IT z wlasnymi pomyslami i truja im 4 litery. Jestesmy tez tymi, ktorzy uslug dostarczanych od IT uzywaja. Z punktu widzenia IT jestesmy wiec ... klientami. Dlatego tez, ja moge byc srednio zainteresowany tym jak co dziala, byleby dzialalo na najlepszym z mozliwych poziomow. Moze sie to wydawac dziwne, ale gdybym sie interesowal jak co jest polaczone, to albo bym oszalal, albo zabralbym komus prace. Ani jednego ani drugiego nie chce.

@MikeO: czy w takim razie nie wypada sprawdzić z kimś bardziej technicznym drobiazgi, zanim ogłosisz na swoim blogu tryumf myśli nad materią?

jak na profesjonalny artykul dotyczacy IT, to tytul jest beznadziejny.