Grubo, obecność w Debian Stable jako tożsamość stabilności. Dzwonił rok 2001, chce swoje WTC z powrotem.
(Oraz jeśli dla kogoś Debian Stable jest wystarczający aby zawrzeć w TOS odpowiedzialność za poprawne działanie chmury, to nie wiem czy gratulować samopoczucia czy współczuć amatorstwa)
No właśnie nic z tego nie jest cool. Ręka w górę, kto używa rails 2.3.5 i 1.8.7? 
Anyone?
Wybacz, ale z taką konfiguracją, możecie sobie robić co wam się podoba, ale forever alone. Bo nawet jeśli ktoś używa wersji 2.3.x, to jest to 2.3.7 lub 2.3.9. Już nawet nie mówię tu o tym, że w startupie, przy którym pracuję już prawie 1,5 roku zaczynaliśmy od rails 3.0. Wprawdzie wtedy to były edge, ale już niedługo rok stuknie oficjalnej wersji. Zadawał sobie ktoś pytanie do kogo z takimi wersjami uderzacie?
Przecież większość aplikacji zaczętych w ciągu ostatniego roku nawet nie spojrzy na taką konfigurację, a nikt normalny nie będzie też robił downgrade do 2.3.5, jeśli ma 2.3.9. A to właśnie aplikacje, które się rozwijają, wchodzą w końcu w taką fazę, że potrzebują czegoś lepszego niż postawiony na prędce dedyk na ovh.
Dlatego ja radzę spuścić z tonu, bo takim podejściem to raczej dużo nie ugracie. Powodzenia życzę mimo wszystko.
EDIT: A używanie oficjalnych paczek debiana, których pewnie mało kto komercyjnie używa (ergo wątpię w nieskazitelną niestabilność) jest słabą wymówką.
Przecież na tym “stabilnym” Debianie też da się zainstalować Ruby 1.9.3 (stabilne).
To jest dla nas ważna informacja i naprawdę nikt u nas nie robi czegoś dla siebie, tylko dla Was. Przecież bronienie starego oprogramowania dla samego oprogramowania jest nieporozumieniem i sami się brzydzimy takich praktyk.
Jednak chcemy dostarczyć środowisko produkcyjne i brać odpowiedzialność za Wasze dane, backupy i ogólną stabilność (czego większość dostawców nie robi). Chcemy Wam dać produkcyjne i biznesowe SLA. Żeby to zrobić, nie możemy sobie pozwolić na swobodę i lekkomyślność, która po prostu nie jest profesjonalna. Mamy nadzieję, że też to rozumiecie.
Więc może zapytamy tak: jakie konfiguracje byłyby dla Was dziś optymalne z punktu widzenia jakości samego procesu tworzenia kodu? My sprawdzimy, czy i jak dziś można zapewnić Wam tę konfigurację, mając na uwadze konieczność utrzymania wysokiego SLA.
Z góry dziękujemy za pomoc,
zespół Oktawave
Dla mnie na chwilę obecną to byłby: Ruby 1.9.3-p194 i Rails 3.2.6
Aktualizowane dość często w oparciu o te dwie strony:
http://weblog.rubyonrails.org/
http://www.ruby-lang.org/en/news/2012/04/20/ruby-1-9-3-p194-is-released/
Zresztą problem konkretnej wersji Railsów, w dużej mierze rozwiązuje bundler.
Offtopic:
Tomash i Sarnik, rozwliliście mnie. 
Przy rejestracji na forum powinnno być ostrzeżenie: “Uwaga, wchodzisz na tereny zamieszkane przez trole!”
+1
Coś Ci się pomyliło 
Jechaliśmy na edge’u, ale to był master w czasach, kiedy stabilna była wersje 3.1.x, 3.0 było wydane pod koniec sierpnia 2010: http://rubygems.org/gems/rails/versions/3.0.0
Co do wersji rubiego, to tylko mogę się podpisać pod tym co jest powyżej. Najprawdopodobniej jeszcze w tym roku zostaną wydane railsy w wersji 4.0, która nie będzie obsługiwać rubiego w wersji niższej niż 1.9.3. Praktycznie nikt już nie zaczyna projektów w niższych wersjach. To, że paczka jest oznaczona jako unstable w debianie, wcale nie znaczy, że ruby 1.9.3 nie jest stabilny.
Ale mamy tutaj 2 kwestia - jedna kwestia to to co jest dostarczone przez chmurę, a druga kwestia to to co można tam zainstalować. Jeżeli udostępnicie możliwość zainstalowania rubiego w innych wersjach, to użytkownicy mogą to zrobić na własną odpowiedzialność i jeżeli będą chcieli, to mogą nawet aplikacje uruchamiać na ruby 2.0.0. Jak moje konto na Oktawave zostanie aktywowane to sprawdzę jak to wygląda z punktu widzenia programisty.
Taka jedna rzecz mi się nasuwa jeszcze, że o ile często, to co pisze Tomash można by nazwać trolowaniem ;), o tyle teraz poruszona została bardzo ważna kwestia.
Fakap pewnie się zdarzy, prędzej czy później. Nie wiem jak to wygląda od środka, ale radzę nie uśpić swojej czujności faktem iż używacie paczek oznaczonych jako stabilne. Patrząc na wtopy różnych chmur, wydaje mi się wręcz, że to jest jedna z ostatnich rzeczy o jakie powinniście się martwić.
Jak to mówi mój wujek, chirurg - jeśli przy zabiegu śmiertelność wynosi 0,1%, a pacjent umrze, to umrze na 100%. If you catch my drift ;).
Ale mamy tutaj 2 kwestia - jedna kwestia to to co jest dostarczone przez chmurę, a druga kwestia to to co można tam zainstalować. Jeżeli udostępnicie możliwość zainstalowania rubiego w innych wersjach, to użytkownicy mogą to zrobić na własną odpowiedzialność i jeżeli będą chcieli, to mogą nawet aplikacje uruchamiać na ruby 2.0.0. Jak moje konto na Oktawave zostanie aktywowane to sprawdzę jak to wygląda z punktu widzenia programisty.[/quote]
Można instalować absolutnie wszystko. Chodzi nam tylko o to, co dostajecie na wejście :). A co później z tym zrobicie… well, it is up to you :).
Zdrówka,
zespół Oktawave
[quote=sarniak]Taka jedna rzecz mi się nasuwa jeszcze, że o ile często, to co pisze Tomash można by nazwać trolowaniem ;), o tyle teraz poruszona została bardzo ważna kwestia.
Fakap pewnie się zdarzy, prędzej czy później. Nie wiem jak to wygląda od środka, ale radzę nie uśpić swojej czujności faktem iż używacie paczek oznaczonych jako stabilne. Patrząc na wtopy różnych chmur, wydaje mi się wręcz, że to jest jedna z ostatnich rzeczy o jakie powinniście się martwić.
Jak to mówi mój wujek, chirurg - jeśli przy zabiegu śmiertelność wynosi 0,1%, a pacjent umrze, to umrze na 100%. If you catch my drift ;).[/quote]
Oj, czujni to staramy się być cały czas. Zachęcamy do lektury: http://www.oktawave.com/pl/6-zasad-bezpiecznej-chmury-obliczeniowej.html
Zdrówka,
zespół Oktawave
Czy chcielibyście specjalny kod służący do przetestowania naszej chmury, umożliwiający autoryzację od ręki? Możemy takowy dla użytkowników tego forum przygotować. Testy są darmowe, a maszynki mocne ;).
Zdrówka,
zespół Oktawave
Ja chce mieć railsy takie jakie będę chciał, potrzebował mieć. A rubiego takiego, zeby te railsy pociągnął
[quote=Piotr Misiurek]@oktawave
Ja chce mieć railsy takie jakie będę chciał, potrzebował mieć. A rubiego takiego, zeby te railsy pociągnął[/quote]
W naszej chmurze, możesz sobie zainstalować, co chcesz. Nam chodzi o predefiniowane konfiguracje - takie, które dostajesz na wejściu. Jakie paczki sobie dograsz, jak sobie to później skonfigurujesz - wszystko zależy od Ciebie.
To wyeksponujcie ten fakt zamiast tego, że wspieracie jakąś ruby/rails archeologię Szczerze powiedziawszy nie mam zielonego pojęcią w jaki sposób to ma w ogóle wpływac na stabilność serwera jakiego ruby ja tam sobie używam ?
Ubuntu 10, 11, 12. Zawsze ten, który jest potrzebny, nie ten, który jest dostępny.[/quote]
Ale nie chodzi o to, na czym sobie codziennie stawiasz Ruby. Chodzi o skalowalne i poważne infrastruktury. Czekam na odpowiedź Bragi.[/quote]
40 serwerów wystarczy?
Wykorzystujemy Shelly do hostowania wszystkich aplikacji jakie powstały w Ragnarsonie w ciągu ostatniego półtora roku. Obejmuje to na przykład aplikację zbierającą informacje o partnerach (affiliate tracking), która musi odpowiadać w czasie poniżej 10ms czy agregator sklepów internetowych generujący 50 req/s. Dla każdej z nich godzinny downtime to tysiące euro straty.
W codziennej pracy wykorzystujemy Rails 3.2.6 i Ruby 1.9.3. Nasi klienci nie spodziewają się niczego gorszego.
Możesz sam sprawdzić jaki system bazowy stosujemy na Shelly:
git clone https://github.com/bragi/shelly-os-check
rm Cloudfile
shelly add
shelly start
curl https://os-check.shellyapp.com/
linux-gnu
Distributor ID: Debian
Description: Debian GNU/Linux testing (wheezy)
Release: testing
Codename: wheezy
Od siebie jeszcze dodam, że niektóre pakiety pochodzą z sid a nawet (o zgrozo!) są instalowane ze źródeł przez nasze własne repozytorium.
Reliability nie możesz uzyskać ze stabilnych pakietów. System i tak padnie, choćby miał korzystać ze stabilnej jak skała dystrybucji. Jedyne czego można być pewnym, to że padnie. W Shelly bierzemy to pod uwagę od pierwszej chwili. To co zapewnia wysoką dostępność to rozproszenie aplikacji i systemy redundantne - np. dodana niedawno replikacja baz danych na wiele instancji.
Cieszę się z konkurencji, zawsze motywuje to do dalszego rozwoju. W Oktawave znalazłem potwierdzenie, że wyróżniki Shelly: nowoczesność, łatwość użycia, zarządzanie z terminala były dobrym wyborem.
[quote=Oktawave]Nie wiem, czy czytacie regulaminy, ale Shelly Cloud nie bierze za nic odpowiedzialności:
https://shellycloud.com/terms_of_service
Jak chcecie w takich warunkach prowadzić biznes?[/quote]
Chciałbym wiedzieć jaką przewagę nad Shelly Cloud ma Oktawave w tym temacie wobec poniższych wpisów:
[quote=http://www.oktawave.com/regulations.html]3.2 The Operator does not guarantee availability of the Services, continuity of operations, failure-free operation and performance of the Service System (or particular functionalities thereof) or safety of the data used by the User in connection with the use of the Service.
3.9. The Operator shall not be liable for any loss caused to User’s or third party property, including loss of any data.
3.10. The Operator does not guarantee that the use of the Service will meet the User’s requirements. The Service is not covered by any guarantee or assurance regarding its quality or reliability.[/quote]
[quote=filiptepper][quote=Oktawave][quote=filiptepper]
Ubuntu 10, 11, 12. Zawsze ten, który jest potrzebny, nie ten, który jest dostępny.[/quote]
Ale nie chodzi o to, na czym sobie codziennie stawiasz Ruby. Chodzi o skalowalne i poważne infrastruktury. Czekam na odpowiedź Bragi.[/quote]
40 serwerów wystarczy?[/quote]
Jakich serwerów?