megi

Możesz teraz zagrać jako programista i pracownik BOK, przy czym to już nie będzie się liczyło do rankingu. BOK się najbardziej różni od admina (chociaż część zadań jest wspólna).

hmmm powinno działać, bo ludzie to przechodzą, ale jak mi podeślesz na megiteam@megiteam.pl screena z poprawnym według Ciebie ustawieniem to Ci powiem czy dobrze. Mogę też podpowiedzieć, że nie jest to zadanie w którym trzeba używać brute force Wielu naszych klientów wiedziało jaką kawę piję EDIT Ale i tak brute force może być najszybszy EDIT2 Ewentualnie odśwież - czasem na różne problemy przeglądarkowe to pomaga

Idziesz torem admina czy programisty? Jak admina to podpowiedź masz w treści zadania, jak programisty to szyfr trzeba zgadnąć i jest to do zrobienia, bo programistę przeszło najwięcej osób.

Któraś podstrona się nie ładowała? Też nie wiem czemu tam dałam Służę namiarami na graficzkę. BTW. Dopiero jedna osoba przeszła questa jako admin. Panowie, robię Wam wjazd na ambicję

Faceci... Na razie mamy 4:3, ale od stycznia się wyrówna.

Osobiście dziękuję Ale muszę dodać swoje 3 gr w kwestii chmury. Kiedyś było wokół niej dużo marketingowego szumu, lekarstwo na całe zło tego świata, zero konkretów, nie było wiadomo czym w ogóle jest chmura. Taki marketing to może trafiał do mniej zaawansowanych technicznie ludzi, ale odrzucał tych, których interesują konkrety. Wydaje mi się, że teraz pojęcie chmury już się skrystalizowało i to już nie jest tylko marketing. Oktawave oferuje głównie IaaS i dla mnie atrakcyjne są pewne rzeczy, które z takiej oferty wynikają (uruchamianie na żądanie, API, godzinowe rozliczanie, dodawanie/odejmowanie CPU i pamięci w locie, wysoka dostępność*). Ja to traktuję jako kolejny rodzaj hostingu oprócz form, które już znamy, i jako nowe obszary rozwoju dla nas. Natomiast na wszelkie newsy o tym, że cloud wyprze tradycyjny hosting, które czasem się pojawiają, jako tradycyjny hoster patrzę z przymrużeniem oka Powinna tam być gwiazdka i dopisek "nie dotyczy hostingu współdzielonego", bo z tym to cloud nie może konkurować. Odnośnie możliwości rozwoju to niedawno robiliśmy streaming z zabiegu na sercu, który transmitowało rmf. Nie zajmujemy się tym na co dzień. O tym, że klient chce to zrobić u nas na VPSie to się dowiedziałam parę dni wcześniej, a że będzie w rmfie to jeszcze później. Pewnie byśmy tak czy siak się tego podjęli, bo akurat mamy parę dedyków w OVH i ATMANie, które od biedy można byłoby wykorzystać, ale z Oktawave to było proste. Dzień wcześniej skonfigurowaliśmy jedną instancję w Okta, wyłączyliśmy ją, żeby nie generowała kosztów (chociaż to i tak były niewielkie kwoty), następnego dnia ją włączyłam, w czasie wydarzenia sklonowaliśmy ją i streamowaliśmy z dwóch. Po godzinie je ostatecznie wyłączyliśmy. Nie powiem, ile nas to kosztowało, ale to były śmieszne kwoty Takie eventy to jedno z zastosowań, które my widzimy, i do których mamy zamiar wykorzystać chmurę na naszej nowej platformie od nowego roku. Natomiast to, że akurat nawiązaliśmy współpracę z Oktawave, a nie kimś innym wynika w pewnym stopniu z tego, że w kontaktach "poza kamerą" przekonali nas do siebie pasją i podejściem. Sprawiają wrażenie, że wiedzą co robią i mam nadzieję, że się nie pomyliłam w ocenie *odnośnie wysokiej dostępności to pytaliśmy co się dzieje w przypadku awarii node'a i dostaliśmy informację, że wirtualka jest uruchamiana natychmiast na innym węźle

//wątek wydzielony z dyskusji zenbox.pl i WHT @nrm No to teraz mnie ciekawość zżera co planujecie

Teraz, kurde?! Jak się sezon motocyklowy kończy a ciężarówka nam samochód skasowała? Cały czas czekałam na sygnał

Jak 2 miesiące temu usłyszałam, że robicie hosting to byłam przekonana, że to będzie kolejny hosting PHP z DA, no limits i konkurowanie ceną. Nie doceniłam Was - zaskoczenie na plus Ale nie dlatego, że uważam to za rewolucję w hostingu, tylko za świeże podejście do tematu. Fajnie, że na rynku zaczyna się dziać coś ciekawego i można pokonkurować pomysłami i nowymi rozwiązaniami. Nie wiem, jak na dłuższą metę wyjdzie Wam takie rozliczanie, ale moim zdaniem to krok w dobrym kierunku (sami mamy parę pomysłów w których planujemy zrobić rozliczanie za UU, ale nie na regularnych usługach). Jak wprowadzicie Django i Railsy to będzie jeszcze ciekawiej - rywalizacja to to, co tygryski lubią najbardziej Nie wypowiadam się na temat samej oferty, parametrów, opisów na stronie, marketingu, bo wiadomo, że każdy z branży zrobiłby po swojemu a nie jestem targetem - to ocenią klienci.

Dzisiaj na RMF24 był streaming z operacji serca w Szpitali Uniwersyteckim UJ. Dla zaprzyjaźnionej agencji interaktywnej konfigurowaliśmy na szybko streaming, który uciągnie zainteresowanie z głównej strony RMFu. Jako serwera streamingu użyliśmy nginxa z modułem rtmp, na dostawcę sprzętu i pasma wybraliśmy chmurę Oktawave, a testowaliśmy korzystając z ffmpega. To wszytko opisaliśmy na blogu (http://www.megiteam....operacji-serca/) Może komuś się przyda Edit: wideo jest już na YouTube

No niestety, ale dobrze, że my się przed faktem dowiedzieliśmy, bo to też nie było takie oczywiste

O, ups, @Tomasz Fiedoruk no to wprowadziłam Cię w błąd @conra jakby ludzie mogli płacić tylko za to co faktycznie wykorzystają to ceny musiałyby być wyższe więc niekoniecznie byłaby jakaś oszczędność.

Dostaniesz roota - to jest wstępnie skonfigurowane środowisko z Wordpressem. Edit Albo inaczej: na 99% dostaniesz roota, ale jako, że nie mam środków na koncie, żeby przetestować to pozostaje element niepewności

php-fpma uruchomiłeś, prawda? Co masz w upstream php {}, bo nie pokazaleś. Ta reszta co działa poprawnie to co to jest dokładnie? Też jakieś php czy static?

Sam Nginx nie obsłuży Ci PHP - potrzebny jest jakiś backend do tego i albo będzie nim Apache z mod_php albo php-fpm albo jeszcze coś innego. Jeżeli w każdym przypadku pliki statyczne idą przez Nginxa to jedyne co w takiej konfiguracji możemy porównywać to wydajność backendu + ewentualnie wydajność wsparcia w Nginxie dla proxy i FastCGI. Z ciekawości: swoje stwierdzenie opierasz na jakichś benchmarkach czy tylko intuicji? Jeżeli możesz się podzielić jakimiś danymi na temat wydajności apache z mod_php w porównaniu do php-fpma to chętnie bym zobaczyła. Nie spodziewam się drastycznej różnicy przy dobrze skonfigurowanym apache. Oprócz wydajności ważna jest również wygoda i na pewno plusem konfiguracji z Apache jest to, że nie trzeba przepisywać .htaccessów. M.

No to dawaj te namiary a nie tylko gadasz :>

Nie zawsze jest to możliwe - jeżeli w skrypcie np. zapętlisz rekurencyjne wywołania i nastąpi przekroczenie stosu to maszyna wirtualna php nie będzie miała szansy zareagować i w ładny sposób tego obsłużyć, tylko właśnie wysegfaultuje.

Jest tak, jak pisze nrm. Możliwy jest też myk pod tytułem "transfer z przedłużeniem" czyli sekundę po wygaśnięciu domeny nowy rejestrator może zrobić równocześnie transfer i przedłużenie - nie trzeba domeny opłacać u obecnego. To jest kiepsko udokumentowany "ficzer" NASKu i robiliśmy tak kilkukrotnie dla domen, które klienci chcieli przenieść, gdy do wygaśnięcia było już mniej niż 6 dni. Mówimy jednak o samym transferze, czy NASK pozwoli go wykonać czy nie, nie wydaje mi się, żeby rejestrator mógł z tego powodu odmówić wydania authinfo, bo to nie jego sprawa co z nim zrobisz. Jeżeli nie ograniczają Cię żadne zapisy umów to się kłóć o swoje M.

Słoniki się w nocy rozmnożyły?

@Samu, trochę chaotycznie. Nie do końca wiem co miałeś na myśli pisząc, że frameworki tworzą demony - chodziło Ci o to, że z frameworkami przychodzą developerskie serwery, na których można sobie uruchomić aplikację w czasie jej tworzenia? Django przychodzi z serwerem developerskim opartym na flupie i można sobie uruchomić aplikację działającą po http lub fastcgi. Do zastosowań produkcyjnych uruchamia się aplikacje na gunicornie, apache z mod_wsgi, uwsgi. Wsgi to nie jest protokół komunikacji taki jak http czy fastcgi - to jest interfejs, który wystawiają pythonowe aplikacje. Serwery aplikacji na których uruchamiane są pythonowe aplikacje z jednej strony mają interfejs wsgi do aplikacji, z drugiej któryś z protokołów http lub fastcgi do komunikacji ze światem zewnętrznym (http - proxy, przeglądarka; fastcgi - serwer www). Apache z mod_wsgi można powrównać do apache z mod_php. Thin komunikuje się ze światem zewnętrznym po http, tak samo jako mongrel czy unicorn. Wymieniasz jednym ciągiem fastcgi i tcp a to nie jest ta sama kategoria. (Fastcgi i http) oraz (tcp i sockety unixowe). Serwer www może się komunikować z aplikacją protokołem fastcgi i ta komunikacja może się odbywać po tcp lub socketach; tak samo może się komunikować protokołem http po tcp i socketach. Dla aplikacji w ruby takim interfejsem jak wsgi dla pythona jest rack. @Rafał Gołego języka (python, ruby, perl) nikt nie używa do pisania aplikacji webowych. Tak, jak pisał samu, w tych językach są fajne frameworki, które Ci upraszczają pisanie aplikacji. W pythonie masz django, pyramid, do małych rzeczy mikroframework flask. W ruby najpopularniejsze są railsy, jest też sinatra i pewnie stado innych, mniej znanych frameworków. Jeżeli chodzi o różnice w sposobie hostowania php, railsów i django to 5 lat temu pisałam o tym artykuł (http://webhosting.pl....Pythona.i.Ruby) Trochę się zdeaktualizował, bo np. mongrela raczej nikt już nie używa, a tym bardziej nikt nie uruchamia railsów jako fastcgi, ale idea jest taka sama. M.

Pojawił się element niepewności, nie? Zjeść czy nie zjeść, oto jest pytanie @Maniack Pykonik jest za tydzień we czwartek (http://blog.pykonik.org/) Jak się uda to od kolejnego będzie streaming z prelekcji, ale w takim przypadku to już faktycznie tylko ciastka http wchodzą w grę. Będziemy streamować jak się obżeramy A w ogóle to o której będziecie? Kto jeszcze będzie z WHT? M.

nieznaszsie niestety nie, ale też dobre własny wypiek to na mniejszą skalę dla współpracowników albo na pykonika - wpadnijcie kiedyś HTTP A jak pytasz o smak to kurczakowe - poważnie

Ale za to będą ciasteczka od MegiTeam Będzie też jojo to możemy zrobić turniej - ćwiczyliśmy na PyConie

offtopic Czym jeździsz?

W jakim sensie podupadł? Chodzi Ci o to, że jest patch dla PHP 5.3.9 a jest już dostępne PHP 5.3.14? Jeżeli patch nakłada się czysto na nową wersję PHP to jest ok, jeżeli nie to autor suhosina to poprawia. Jeżeli chodziło Ci o to, że nie ma dla 5.4, to dlatego, że jak sam autor stwierdził chce to zrobić porządnie. Czy może chodziło Ci jeszcze o coś innego? Autora - to jest projekt jednego gościa, zdaje się byłego coredeva PHP. Wzajemne stosunki pomiędzy nim a teamem PHP i teraz developerami Debiana to telenowela. W tym samym wątku wypowiedź deva suhosina http://lists.debian....2/msg00081.html "considering the fact that you write this email the very same day that a remote code execution vulnerability in PHP is found that is easy to exploit from remote and is greatly mitigated by the use of Suhosin you look pretty stupid. (In case of usage of Suhosin-Extension in default config, it is even completely killed)" Z innego wątku "However from my point of view it is actually better if Debian does not ship Suhosin by default. That might stop them from spreading nonsense like Suhosin is unmaintained/upstream is not responsive etc…" Byłabym raczej ostrożna w twierdzeniu, że rozwój suhosina podupadł. M.