Zdecydowania większość interesujących i innowacyjnych projektów powstaje dla systemu Linux. Nie inaczej jest w przypadku Redisa, open source’owej bazy NoSQL, która nie posiada oficjalnej wersji dostępnej dla systemu Windows.
Na szczęście dla deweloperów korzystających z Windowsa, Microsoft ciężko pracuje nad dostarczeniem wersji działającej na okienkach. Wczoraj światło dzienne ujrzała aktualizacja wprowadzająca obsługę 64 bitowego Windowsa oraz instalator umożliwiający zainstalowanie Redisa w Windows Azure, co w niedalekiej przyszłości zaowocuje przygotowaniem instalatora dla Windowsa.
Z całym szacunkiem dla MS. Redis nigdy nie będzie miał dobrego wsparcia dla windows bo twórca Redisa swego czasu powiedział że Linux „wygrał jako platforma” i ile nawet go cieszy portowanie Redisa na windows to go to nie interesuje. Pewnie dlatego największy „windowsowy” portal w sieci: Stackoverflow używa Redisa na Linuksach (wspominali o tym pracownicy SO). Technicznie Windows też ma gorzej bo nie ma tutaj odpowiednika Copy-On-Write i trzeba to emulować w userspace (co w tej chwili prowadzi do tego, że przy operacji zrzutu danych do pliku windowsowa wersja zużywa dwa razy więcej RAM) .
Dobrze, że MS dostrzega takie projekty i zamiast tworzyć ich kopie, stara się je uruchomić na swojej platformie.
to by byla jakas nowość… Fakt, że sporo się nauczyli i częściowo zmienili podejście, ale historia firmy z Redmond to własnie kopiowanie i kradzież pomysłów…
Na szczęście MS zmienia swoje podejście do branży/rynku. W końcu nie jest już jedynym gigantem, a w wielu dziedzinach musi gonić konkurencję. Dobrze, że jest dział w MS, który zajmuje się dostosowaniem powszechnie stosowanych rozwiązań, do swojej platformy. Obok Redisa mamy również Node, Solr, CouchDB, npm oraz kilka ciekawych projektów dedykowanych PHP.
MS niczego nie zmienia.
Nadal ma podejście, żeby zniszczyć wszystko co mu przeszkadza doić rynek tanią amatorszczyzną.
Jedyna zmiana to taka, że dostrzegli teraz, że owe przeszkody zamieniły się w bardzo realne zagrożenie. Więc zmieniają sposób walki z nimi i metody na wyeliminowanie ich. Czyli podejście dokładnie to samo co zawsze.
Baza danych to narzędzie.
Windows to zabawka.
Znacie kogoś, kto tworzyłby na przykład drogi celownik optyvzny przystosowany do plastikowego pistoletu na kulki za 20 złotych?
Nie? To też wyjaśnia brak profesjonalnych i nowoczesnych narzędzi dla platformy windows. Jest trochę przestarzałego okienkowego crapu dla lamerów, ale generalnie ten system operacyjny jest martwy. Microsoft przegrał.
Na prawdę wiele złego temu portalowi wyrządziłeś swoimi bezpodstawnymi opiniami.
i pewnie dla tego ze system jest martwy 90 programow typu erp jest na windows i mssql nie mowiac juz o narzedziach do tworzenia softu to co napisales to jest belkot totalny … windows jest bardzo dobrym systemem z gigantycznym zapleczem i producentem ktory ma strategie i wizje i co jest najlepsze nie przepisuje od nowa softu co kilka miesiecy jak niestety przy wielu projektach opensource bywa
"nie przepisuje od nowa softu co kilka miesiecy jak niestety przy wielu projektach opensource bywa"
bo nowy developer musi się wykazać. Co lepiej brzmi w CV – udział w jakimś projekcie czy napisanie zupełnie nowego projektu, który zastępuje stary… 🙂
trochę Cię zaskoczę. Mój bratanek ma pistolet na kulki z celownikiem laserowym 🙂
No i zapewne używa też Windows. A jeśli nie on, to jego stryj. Co ma w tym być zaskakującego? 😛
Fakt jest faktem, że większość porządnych NoSQLi chodzi dobrze wyłącznie na Linuksie. Jakoś nasi klienci nie cisną nas na wypuszczenie Cassandry na Windows (choć uruchomić się da, ale wsparcia nie dajemy).
Powody, dla których napisanie dobrego SZBD na Windows jest trudne:
– brak dobrego odpowiednika mlockall; VirtualProtect nie ma nawet połowy możliwości mlockall
– brak mincore / fincore
– brak kontroli nad readahead
– słaby zarządca I/O i brak możliwości zmiany na własny
– słaby zarządca procesów, porównywalny z takim, jaki w Linuksie był 8 lat temu; znowu brak możliwości zmiany na własny
Do tego dochodzi kwestia dziwnego API, które nie przypomina żadnego API z systemów Uniksopodobnych. Dlatego łatwo jest jednym kodem oblecieć Linuksa, Solarisa, RHEL, wszelkie BSD w tym Mac OSX, natomiast Windows to zupełnie inna bajka. I dla tych dwóch klientów na 200 zwykle się nie opłaca portować.
"- słaby zarządca I/O i brak możliwości zmiany na własny
– słaby zarządca procesów, porównywalny z takim, jaki w Linuksie był 8 lat temu; znowu brak możliwości zmiany na własny "
O, i to są argumenty. Powiedziałbym jednak, że to nieprawda iż scheduler Windows jest taki, jak w Linuksie 8 lat temu. One w ogóle nie są porównywalne. Zatkać Windowsa procesami można bez problemu (siódemkę 64 bit, ósemki nie próbowałem). Zatyka go głupia tacka od CD, zatykają (całkowicie) operacje bezdyskowe.
Wystarczy odpalić wystarczająco dużo procesów. I to "dużo" to nie jest 1000 forków zrobionych na siłę, aby tylko wykazać z góry założoną tezę, tylko normalna, codzienna praca. (eclipse, tomcat, outlook, kilka okien worda, excel, kilkanaście tabów w przeglądarce). Zostaje jeszcze bardzo dużo wolnej pamięci, a mimo to system nie pozwala na szybką i wydajną pracę.
W tym samym momencie na drugiej maszynie działa sobie Oracle i Jboss, obciążone jak cholera i nadal jest pełna responsywność interfejsu.
——
Zaraz jednak przyleci powershell czy jak mu tam i zacznie "udowadniać", że nie masz racji.
Napisałem taki jak w Linuksie 8 lat temu w sensie złożoności. Obecnie Linuks ma scheduler procesów o złożoności O(log n), tymczasem Windows chyba nadal używa schedulera O(n). Jak n jest duże, to wiadomo, który będzie działał lepiej.
Uwielbiam te kłótnie o złożoności obliczeniowej planisty.
Linux swego czasu miał nawet planistę o złożoności O(1), ale… nie sprawdził się. Poza tym – złożoność planisty ma znaczenie tylko wtedy, gdy to n jest naprawdę duże, większe niż setki tysięcy, czy miliony. Ale przecież tylu procesów po prostu nie uruchamia się na raz. W przypadku Linuksa dochodzi jeszcze kwestia szeregowania wątków (w Linuksie proces = wątek, tyle, że w obrębie wątków z jednego procesu odpada przełączanie kontekstu). Poza tym – to włąśnie przełączenie przestrzeni adresowej zabiera niejednokrotnie więcej czasu niż zaplanowanie przydziału procesów do procesora…
Blah, przełączanie przestrzeni adresowej zamiast kontekstu..
Zapewne masz rację. Ja pisałem raczej o user-experience. A jest ono w Windows na chwilę obecną okropne.
Hmm, ciężko mi ocenić user-experience Windowsa, bo lata z niego nie korzystałem 😉
> Zapewne masz rację. Ja pisałem raczej o user-experience. A jest ono w Windows na chwilę obecną okropne.
Desktopowe user-experience? Mam dokladnie odwrotne odczucia,
Win7 jest swietne, linux ssie palke w porownaniu.
Dodałbym do listy jeszcze Linuksowy copy-on-write przy forkowaniu, o którym na windowsie microsoft może tylko pomarzyć bez przepisania całego systemu od zera.
Ale to tylko tak pisze, żeby skopać leżącego windowsa, do tego już nieprzytomnego.
Po raz kolejny pokazujesz, ze jestes klinicznie niekompetentnym idiota ktory nie ma pojecia o czym pisze.
1. Fork w windows jako taki nie istnieje (i nie, to nie jest wada czy zaleta, to po prostu inna filozofia).
2. Copy-on-write to cecha bardziej sprzetu (tutaj, CPU rzuca wyjatek przy zapisie do danej strony), w systemie jest handler do obslugi takiego zdarzenia.
3. I tak, windows takie cos ma.
4. Zanim znow cos bezmyslnie chlapniesz, uzyj googli, to nie boli.
"Copy-on-write to cecha bardziej sprzetu "
Otóż nie prawda. COW to technika (strategia) optymalizacji
Szczególnie śmiesznie to brzmi w zestawienie inwektywami o "klinicznie niekompetentnym idiocie"
Zgadza sie, cow w ogolnosci to technika, w kontekscie cow pamieci realizowana
z wykorzystaniem mechnizmow na poziomie cpu.
LOL. W sumie, nie wiadomo gdzie zacząć dementować te brednie.
Dlaczego Linuksowy scheduler jest "completely fair" wykazano dawno i wielokrotnie 😀
Copy-On-Write – w ReFS się pojawia.
MS-SQL Server jak najbardziej ma własnego zarządcę procesów, pamięci i IO zapewne też i w odróżnieniu od worków na dane, składających się na skutek błędu w jednym timerze (CouchDB), SQL Server to prawdziwy RDBMS. Takim wiesz, z transakcjami.
Windows od czasu pojawienia się linii NT jest technicznie przed dowolnym darmowym Unixem i spokojnie relacją ceny do możliwości zabijał Unixy komercyjne. A to, że dzieci żyją ignorancją i uprzedzeniami….
>Copy-On-Write – w ReFS się pojawia.
hmm…ale zdajesz sobie sprawę jaka jest różnica między COW dla procesu a COW dla systemu plików ?
Redis to baza nosql w RAM znacznie szybsza niż tradycyjne RDBMSy z możliwością zrzutu do pliku/replikacji. Służy przede wszystkim jako zaawansowany serwer cache (ale można też zrobić na tym naprawdę skalowalny system MQ)
W tym zastosowaniu SQL Server będzie za wolny (dlatego portują Redis)
Polecam doc na http://redis.io
Z drugiej strony tam gdzie potrzeba ACID to MS SQL Server nie jest złym RDBMSem – po prostu nie ma nic takiego co w by powodowało że 95% przypadków nie można by użyć PostgreSQL (oprócz kompatybilności z legacy-microsoft-ecosystem)
> hmm…ale zdajesz sobie sprawę jaka jest różnica między COW dla procesu a COW dla systemu plików ?
Idz popraw wiki, bo tam twierdza, ze w windows jest cow dla urzadzenia: http://en.wikipedia.org/wiki/Copy-on-write
"COW may also be used as the underlying mechanism for disk storage snapshots such as those provided by logical volume management, Microsoft Volume Shadow Copy Service or file systems such as btrfs in Linux."
>Idz popraw wik
@jarek Nie twierdze ze nie ma COW, tylko ze COW w ReFS a COW dla pamiecie to co innego. Brak COW dla pamieci (takiego jak przy forku wlasnie) jest powodem podwojnego zuzycia RAMu przy zrzucie do pliku w Redisie, pewnie mozna to ominac ale antirez (twórca Redisa) ma to dupie bo go platforma win32 nie za bardzo interesuje*.
Czytaj uwazniej jareczku – bo dyskutujesz z teza ktorej nie stawialem.
*http://oldblog.antirez.com/post/redis-win32-msft-patch.html ( [..] I think that Linux completely won as a platform to deploy software[..] )
Faktycznie kisielku, zagalopowalem sie. W linku ktory podajesz nie widze wzmianki, ze windows nie ma cow (i slusznie, bo ma). Nadal wiec nie rozumiem o czym to gadanie z cow?
> Nadal wiec nie rozumiem o czym to gadanie z cow?
NIE MA COW na poziomie OS (takiego jak przy fork) ergo nie da się łatwo portować Redis i całej masy innego softwareu na forku bazującej.
> W linku ktory podajesz nie widze wzmianki, ze windows nie ma cow
link odnosił się do tego dlaczego Twórca prawdopodobnie najlepszego na rynku serwera cache nie podziela pogladu na temat wspanialosci platformy MS a nie do COW (znowu nie czytasz ze zrozumieniem)
Ze strony MS:
"Redis on Linux uses an OS feature called Fork/Copy On Write. This feature is not available on Windows, so we had to find a way to be able to mimic the same behavior without changing completely the save on disk process "
http://blogs.msdn.com/b/interoperability/archive/…
Nastepny nie odroznia forka od copy-on-write.
Windows nie ma forka, wiec z definicji nie moze miec cow+fork,
czytaj ze zrozumieniem. Cow w windows istnieje:
http://support.microsoft.com/kb/103858
Ok pierwotne wyrazenie nie jest precyzyjne: nie ma funkcjonalnego odpowiednika forka (który używa techniki COW). Co w praktyce oznacza ze przy portowaniu Redisa dla windows trzeba bylo to dopisywac.
> Co w praktyce oznacza ze przy portowaniu Redisa dla windows trzeba bylo to dopisywac.
Ale to efekt tego, ze tworca tego softu postawil na mechanizmy specyficzne
dla unixa. Z jednej strony ma to sens bo pozwala zmaksymalizowac wydajnosc,
z drugiej pojawiaja sie problemy z przenosnoscia. Tak samo moze byc rownie
dobrze w druga strone jak zacznie sie od deweloperki i zoptymalizuje na win32.
Wniosek, ze winda nie ma copy-on-write jest nieuzasadniony.
A wniosek, ze winda ogolnie ssie to juz luzna interpretacja.
Już dawno udowodniono, jest najlepszy, blabla, technicznie przez darmowym, dzieci, ignoracja.
Może jakieś konkrety, trolu?
I also want to start my own business and looking for partner.What kind of business you have?