Autorzy Railsów zalecają aktualizację, chociaż najwyraźniej nikomu jeszcze nie udało się przeprowadzić skutecznego ataku.
Czy po aktualizacji wasze (railsowe) aplikacje doświadczyły jakichś problemów ?
Jeśli tak to prosimy o podanie wersji Rubiego/Railsów i ew. rodzaju problemu w tym wątku.
Co do Zeda, to tak naprawdę nie wiem o co mu chodzi - sam napisał, że można to bardzo łatwo znaleźć używając chociażby SVNa. O ile uważam Zeda za bardzo dobrego programistę, to często zdarza mu się przesadzać - większość użytkowników rubiego nie zna C i nic by im nie dała wiadomość o tym, w którym miejscu była dziura. A jak ktoś zna i będzie się chciał dowiedzieć, to na pewno nie będzie miał problemów ze znalezieniem tego kawałka.
Sam wkleił kawałek z logów SVNa (svn co http://svn.ruby-lang.org/repos/ruby/trunk ruby; cd ruby; svn log | more - i mamy te ukrywane skrzętnie informacje i błędy). A to, że oficjalny news był 3 dni później? Można się doszukiwać teorii spiskowych. Ja bym to zrzucił na testowanie…
Powinieneś posłuchać wywiadu z Zedem po jego słynnym rancie. Ogólnie koleś ma zadrę jeśli chodzi o środowisko rubiowe i kod Ruby, bo ten kod ma masę dziur oraz zwalonych fragmentów, a developerzy nie potrafią tego przyznać i zwalają złe zachowanie na inne czynniki.
O to chodzi w rantach
I to jest tragedia, bo moim zdaniem nie sposób być dobrym programistą w języku high-level jeśli nie zna się jakiegoś języka niskiego poziomu (obecnie rodzina C dominuje w tym temacie). A już nie wspominam o pojawiającej się z rzadka, ale jednak, konieczności napisania natywnego rozszerzenia…
No tak, to rozumiem, w poprzednim rancie też o tym pisał. Ale akurat w tych newsach nie szukałbym chęci ukrycia czegokolwiek. Samo znalezienie błędu świadczy o tym, że coś jest nie tak, nie wiem co by zmienił dokładny opis.
I to jest tragedia, bo moim zdaniem nie sposób być dobrym programistą w języku high-level jeśli nie zna się jakiegoś języka niskiego poziomu (obecnie rodzina C dominuje w tym temacie). A już nie wspominam o pojawiającej się z rzadka, ale jednak, konieczności napisania natywnego rozszerzenia…[/quote]
To jest temat na dłuższą dyskusję Sam zaczynałem od C i cieszę się, że nie był to na przykład Pascal, Java, czy PHP (ten ostatni chyba najgorszy z możliwych do zaczęcia przygody z programowaniem). Moim zdaniem im więcej języków zna programista, tym lepiej (i przez “zna” rozumiem napisanie jakiejś, nawet niewielkiej, aplikacji), ale z drugiej strony jest wielu programistów, którzy nie znają języków niższego poziomu, a są dużo lepsi ode mnie.
Heh a ja pamiętam czasy, gdy się C uczyłem i to język wysokiego poziomu był ;))
Tomash: Idąc tym tropem, znam kupę programistów co świetnie znają C, Assemblera i niżej i za cholerę sobie nie radzą z wzorcami projektowymi jak singleton, czy fabryka abstrakcyjna nie ma tu zasady.
Kiedyś się mówiło, że bez matematyki nie będzie się dobrym programistą
[quote=y3ti]Heh a ja pamiętam czasy, gdy się C uczyłem i to język wysokiego poziomu był ;))
Tomash: Idąc tym tropem, znam kupę programistów co świetnie znają C, Assemblera i niżej i za cholerę sobie nie radzą z wzorcami projektowymi jak singleton, czy fabryka abstrakcyjna nie ma tu zasady.[/quote]
No widzisz, właśnie wylazła znajomość jednokierunkowości implikacji
Implikacja była: jeśli ktoś jest dobrym programistą, to zna język niskiego poziomu (wie co to wskaźnik, alokacja i fragmentacja pamięci itd.).
Czyli znajomość lowlevela jest warunkiem koniecznym (a nie wystarczającym) bycia dobrym programistą.
Oczywiście nieprawdą jest (tzn. nie jest prawdą w ogólności) zdanie odwrotne:
Jeśli ktoś zna język lowlevel, to jest dobrym programistą.
I cały czas twierdzę że żeby być dobrym programistą, trzeba wiedzieć co się dzieje “tam na dole”. Nie być z tego jakimś wymiataczem, który potrafi rozpisać sobie wszystko do poziomu bramek logicznych. Ale znać temat na tyle, żeby np. docenić język z możliwością ręcznego zwalniania pamięci (tego mi brakuje w Rubym) czy rozumieć wady i ograniczenia Śmieciarza. I wiedzieć dlaczego ten algorytm będzie bolesny dla maszyny nie tylko ze względu na złożoność, ale i konieczność zaalokowania gigantycznej tablicy. Świadomość że obiekt (także liczba) w Rubym zajmuje przynajmniej kilkadziesiąt bajtów oraz wiedza jakimi obiektami są w Rubym liczby (takimi jak symbole, czyli tylko jeden obiekt dla danej wartości) naprawdę pozwala “lepiej” myśleć podczas projektowania i pisania.
A to nie jest prawda?
Ziom, najsłabszym programistą Ruby/Rails z jakim miałem okazję do tej pory pracować był chłopak, który właśnie leżał z matematyki i nie znał języka niskiego poziomu (oraz związanych z tym zagadnień). Wiesz że po jego kodzie było widać brak właśnie matematycznego sposobu myślenia o programowaniu?
Już nie wspomnę o tym, że znając matematykę można fajniej i zwięźlej pisać pętle i warunki logiczne.
Tomaszu, a kto to jest dobry programista ? Jak go zmierzysz? Okreslisz ? Jest jakas norma zapisana w krajowym urzedzie miar i wag ?
Kolejne sprawa to to jakie bedzie mialo znaczenie czy operuje c/asm jesli mam rozwiazac jakis problem uzywajac javy ? Czy piszac w javie powieniem wiedziec jak ta java alokuje pamiec, jak dziala procesor ? Co to jest fragmentacja pamieci, przeciez jest tam ta cala wirtualna maszyna ktora ma mi tego zaoszczedzic.
Wazniejsze jest chyba pozyskiwanie informacji, czy jestem slabym pogramista skoro nie wiem jak calkowac ? Wydaje mi sie ze nie, pod warunkiem ze gdy faktycznie bede potrzebowal tej wiedzy, bede w stanie ja pozyskac.
Wracajac jeszcze do bycia programista w c, wczoraj kolega mi wyslal ciekawy paste. Jego znajomy uczy sie c, pomagal mu troche, pokazal tez jak wygladalo by rozwaizanie jego problemu w ruby
Kod moze nie jest najlepszy, ale chodzi mi tutaj bardziej o zobrazowanie tego, ze nie ma znaczenia czy znasz c, asm, albo forttrana piszac w ruby. Liczy sie to jak jestes w stanie dobrze poznac jezyk w ktorym rozwiazujesz problemy, jak dobrze potrafisz pozyskiwac nowe informacje, czy potrafisz czytac dokumentacje itd.
Wyobraz sobie ten kod programisty c, ktory ma za zadanie napisac go w czystym ruby i nie posiada zadnej z wyzej wymienionych umiejetnosci. Jestem prawie pewien ze by go przepisal kropka w kropke uzywajc kilku zmiennych, petli i jakiegos warunku, przeniosl by po prostu wzorce programowania z c do ruby, a to nie jest chyba wlasciwe.
Ja zainstalowałem wersję p230 i nie było żadnych problemów, później zobaczyłem wersję phusion: http://www.rubyflow.com/items/544 . Zainstalowałem i też nie było żadnych problemów.
Ja przy probie odpalenia aplikacji z ruby 1.8.6-p230 mialem caly czas segmentation fault’y (przy testach to samo). Aplikacja dziala na Rails’ach 1.2.5
Ponoc problemy wystepuja dla wersji:
1.8.5p231, 1.8.6p230, 1.8.7p22, and 1.9.0-2
Natomiast po skompilowaniu i zainstalowaniu Ruby Enterprise Edition (chlopaki z Phusion wymyslili sobie fajna nazwe ) http://www.rubyenterpriseedition.com/
wszystko dzialalo jak nalezy. Generalnie jest to Ruby w wersji 1.8.6-p110 z patchami latajacymi ostatnie security issues.
MRI nie umrze (jeszcze), ale mocno traci na reputacji i aż się prosi o silną konkurencję (tj. nie taką, jak javowo-borgowy JRuby czy niekompletny Rubinius).
Niestety trochę smutne jest to w jaki sposób Matz i spółka prowadzą taki projekt. Aż dziwne, że zaszli tak daleko.
To dzięki takim projektom jak JRuby, Rubinius powstała specyfikacja Rubiego (RubySpecs), która pozwala na utrzymanie zgodności wstecz oraz lepsze testowanie nowych ficzerów Rubiego. Developerzy JRubiego i Rubiniusa widać, że wiedzą jak prowadzić projekt porządnie. To oni przekonali Matza do speców Rubiego, a także starają się wymusić inne podejście do pewnych spraw, np. konsekwentna numeracja wersji, zgodność wstecz przy zmianie pozycji “build” (major.minor.build). Niestety 1.8.7 nie jest zgodna z 1.8.6. Spaczowane wersje jak się okazuje potrafią rzucić segfaultem. Wnioskuję, że w ogóle nie uruchomili na nich testów, bo chyba nie są to jakieś ‘edge case’?
Powiedzmy sobie szczerze. Z całym szacunkiem dla Matza (jako autora języka), ale zachowują się trochę lamersko. Ja rozumiem, że można było załatwiać takie sprawy kilka lat temu, gdy zasięg Rubiego był niewielki. W tej chwili gdy Ruby pretenduje do miana technologii enterprise nie można już tak postępować. Potrzebne są choćby mechanizmy CI.
Dobra, trochę sobie ponarzekałem, to może teraz kilka słów ku pokrzepieniu serc?
Po pierwsze to w jaki sposób MRI jest rozwijane zmienia się, ku lepszemu oczywiście (aczkolwiek powoli, ale zawsze coś). Developerzy wszystkich liczących się implementacji Rubiego spotykają się dosyć regularnie na IRCu i dyskutują na różne tematy. Ruby Design Meeting - możecie tam znaleźć logi ze spotkań.
Po drugie nie ma tego złego co by na dobre nie wyszło. Im gorsze będzie MRI tym lepsze będą inne implementacje. Na pewno wszyscy liczymy na Rubiniusa, który regularnymi krokami idzie do przodu. To dzięki temu projektowi powstały speci Rubiego. Rubinius ma już dosyć sporą zgodność z MRI, a niedługo zaczną się prace nad jego optymalizacją. Z pewnością będzie to najważniejszy etap, a jeśli powiedzie się to jestem pewien, że będziemy mieć nowego króla.
A co z JRubym? Myślę, że to inna para kaloszy. Na tyle inna by być obuwiem, w którym miałoby się chodzić na co dzień. JRuby na pewno świetnie integruje się z całym stosem technologicznym J2EE. Zatem firmy z polityką pt “nie odpalamy nic co nie integruje się z jvm” mają możliwość użycia Rubiego pod postacią JRubiego.
). A miał się wypiąć na rubiego i społeczność, hehe 