blackfire

Rezerwacje to akurat IMHO dobry pomysł bo możesz domenę zarezerwować a później na spokojnie opłacić. Pewnym rozwiązaniem mogłyby być np. płatne rezerwacje -- na tyle niska cena, żeby (normalny) registrar był skłonny wziąć ten koszt na siebie w razie jak klient zrezygnuje, ale jednak zniechęcająca do rezerwacji wszystkiego co popadnie. Nie wiem, 10 groszy od sztuki? Czyli tyle, ile teraz jest płatne wywołanie <domain:create> na istniejącej domenie -- też pewnie po to żeby zniechęcić do tłuczenia w kółko prób rejestracji aż domena wróci do puli wolnych. Może np. opłata dotyczyłaby tylko domen wygasłych mniej niż ileś tam temu, żeby nie karać ludzi po prostu rejestrujących nowe domeny.

Latający Potworze Spaghetti, widzisz i nie grzmisz? (a akurat security.debian.org oficjalnie nie jest mirrorowane IIRC, co potrafiło dostarczyć kupę radości jak wyszła jakaś dziura w openoffice czy innym kde i cały świat darł stamtąd gigabajty).

Doskonały przykład niezrozumienia problemu. Kafi, pisz ten tutorial Nie ma czegoś takiego jak "tak jak powinno być". Musisz rozróżnić dwie kluczowe sprawy: znaki a bajty (Unicode ninjas są proszeni o przymknięcie oczu na drastyczne uproszczenia). Masz taki znaczek: "ą" (LATIN SMALL LETTER A WITH OGONEK). W bazie Unicode ma on przypisany kod U+0105 i tyle możesz o nim powiedzieć. Niestety, codepointów (czyli np. takich U+0105) nie da się bezpośrednio zapisać w bazie danych, wysłać w sieć itp., dlatego powstały różne sposoby konwersji znaków (LATIN SMALL...) na bajty. Realnie używany jest UTF-8, gdzie ą (U+0105) jest zapisywane jako dwa bajty: \xc4 \x85. Proces dekodowania UTF-8 -> Unicode zamienia z powrotem te dwa bajty na U+0105, czyli platoniczny ideał "ą". Zanim upowszechnił się Unicode i UTF-8, powszechne były inne, jednobajtowe kodowania (i niestety dalej są powszechnie używane). Np. w popularnym ISO-8859-2 znak ą (wtedy jeszcze nie był ani LATIN SMALL..., ani tym bardziej U+0105) zapisuje się jako jeden bajt \xb1. W forsowanym onegdaj przez MS kodowaniu CP-1250 ą to \xb9. Wszystkie te zapisy opisują dokładnie ten sam znak: ą, ale żeby się tego dowiedzieć, musisz wiedzieć, jakiego kodowania użyć do konwersji \xb9 -> Unicode. Bo \xb9 to wcale nie musi być ą w CP-1250, to równie dobrze może być š w ISO-8859-2. "Krzaki" pojawiają się, kiedy traktujesz dane zapisane w jednym kodowaniu jako zapisane w innym. Przykładowo, masz string "\xb1", który (jesteś o tym głęboko przekonany) przedstawia ą w latin2 (ISO-8859-2). Twój software operuje w UTF-8, jak Latający Potwór Spaghetti przykazał, więc przed wyświetleniem (wypisaniem do przeglądarki) musi przekonwertować ten string na UTF-8. Tak się nieszczęśliwie składa, że skądś sobie wydumał, że ten string jest zakodowany w latin1 (ISO-8859-1). No to bierze \xb9 i konwertuje latin1->UTF8. Wynik? \xc2 \xb1, odpowiadający U+00B1, czyli PLUS-MINUS SIGN (±). Druga warstwa konwersji, która również musi się udać żeby było widać pliterki a nie krzaki, to wyświetlanie. Tutaj ponownie konwertowane są dane z postaci strumienia bajtów z określonym kodowaniem (wynikającym z nagłówków http, ustawień terminala czy czego tam innego), a wynikowe codepointy są odnajdowane w fontach i rysowane na ekranie. Problem jest szczególnie widoczny w mysqlu (zwłaszcza za czasów migracji 4.0->4.1 to była prawdziwa plaga), bo łatwo jest osiągnąć konfigurację, która prawie zawsze działa. Przykładowo: na stronie zadeklarowane kodowanie utf8, dane do bazy wrzucane zakodowane również w utf8, a kodowanie kolumny w bazie i oczekiwane kodowanie danych wyjściowych zadeklarowane jako latin1 (domyślne). Wygląda to tak: 1. User w formularzu wpisuje ą 2. Przeglądarka wysyła \xc4 \x85 3. INSERT INTO ... VALUES (..., "\xc4\x85") 4. Serwer mysql konwertuje dane z latin1 (character_set_client się ta opcja bodajże nazywa) do latin1 (kodowanie kolumny), czyli nic nie robi 5. SELECT ... FROM ... 6. Serwer mysql konwertuje dane z latin1 (kodowanie kolumny) do latin1 (character_set_client), czyli nic nie robi 7. Do klienta idzie \xc4 \x85 z nagłówkiem "Content-type: text/html; charset=utf-8" 8. Klient dekoduje \xc4 \x85 na U+0105 i wyświetla ą Teraz puszczamy w to wszystko phpmyadmina, który stara się robić dobrze i eksportować dane w utf8: 0. SET NAMES UTF8 1. SELECT ... FROM ... 2. Serwer mysql konwertuje dane z latin1 (kodowanie kolumny) do utf8 (character_set_client) 3. Klient dostaje wynik konwersji \xc4 (LATIN CAPITAL LETTER A WITH DIAERESIS, \xc3 \x84) i \x85 (NEXT LINE, \xc2 \x85) 4. OMGWTFBBQ gdzie moje ogonki?

Przynajmniej wyszedł dobry wątek kalibrujący

Zerowe primo: IANAL. Mogę się mylić. Pierwsze primo: patenty to nie prawa autorskie i vice versa. Każdy utwór jest z automatu chroniony prawami autorskimi i nie musisz tego nigdzie zgłaszać (nawet zwyczajowe © Autor nie jest wymagane). Nie możesz opatentować wartości artystycznych utworu (jakkolwiek by to nie brzmiało w kontekście problematycznego cytatu). To, że w Internecie każdy kopiuje każdego, nie oznacza że to jest (w każdym przypadku) zgodne z prawem (choć często jest a i równie często autorom to nie przeszkadza/jest na rękę). Grafiki na stronę też nie możesz sobie tak po prostu z Google Images zedrzeć. Za przypisywanie sobie autorstwa cudzego tekstu ("pisałem na trzeźwo" or sth; jakby w tym miejscu przyznał się do copypasty, byłby IMHO na zupełnie innej pozycji). Średnio mnie obchodzą losy freecast.pl (firmy i właściciela) a o rhosting.pl nigdy nie słyszałem więc po tym tekście spodziewałem się że rhosting.pl jest jego jakąś nową marką. @Kulfi: poczułem się wprowadzony w błąd ;] Śmieszne to są Twoje próby wytłumaczenia zachowania freecast.pl ("po pierwsze to nie ukradłem żadnego zegarka, a po drugie to on wcale nie był złoty"). Plagiat to plagiat. Fakt że 1kpln to trochę sporo ale IMHO to, że freecast powinien jakąś nauczkę dostać, nie ulega wątpliwości. Ano wyczynia się. Najpierw uphost pracodawca, teraz freecast pisarz. Akcja z *firmą-bez-akceptacji-wht* też była dość żenująca, ale co zrobisz (ktoś to forum traktuje jakoś bardziej na poważnie?). Napisz bajkę, pośmiejemy się wszyscy, a potem każdy ją gdzieś opublikuje jako swoją.

Wstańcie i pomachajcie

Czas CPU a czas zegarowy to dwie bardzo różne rzeczy. Na określonej maszynie wykonanie jakiegoś zadania będzie zajmować tyle samo czasu CPU niezależnie od jej obciążenia, ale czas zegarowy może się drastycznie różnić -- zadanie może dostać 100% CPU i wtedy cpu_time==real_time, może (jak umie) rozłożyć się na kilka procesorów i wtedy cpu_time>real_time, a może maszyna nie ma tyle wolnej mocy żeby to zadanie policzyć i wtedy cpu_time<real_time. A może wąskim gardłem jest I/O i CPU się nudzą (cpu_time<<real_time), a czas zegarowy jest określany przez wydajność dysków -- i też im bardziej dorżnięta maszyna, tym większa dysproporcja między cpu_time a real_time. Jeżeli liczą za czas CPU to jest jak najbardziej OK, ale liczenie czasu zegarowego jest co najmniej nieuczciwe.

Bodajże Ford stwierdził, że jakby spytał klientów, czego chcą, toby odpowiedzieli że szybszych koni. /OT Edit: Pac! polskiego (prawo Muphry'ego w całej okazałości)

Ja rozumiem że w firmie coś takiego to samobójstwo ale w shellowni typu rootnode? Jeżeli plik w lost+found był, to znaczy że inode (w dużym uproszczeniu "właściwy plik") był cały a zaginęło jedynie dentry ("nazwa pliku"). Uprawnienia są przechowywane razem z inodem, więc i tak byś czyichś plików nie zobaczył (próbowałeś czy od razu przyszedłeś na wht z płaczem? a jak miały o+r to nie miej pretensji do nikogo poza sobą). Na miejscu ahesa mógłbym zrobić dokładnie to samo nawet jakbym miał backup (który z definicji nigdy nie będzie 100% aktualny, więc user mógłby chcieć wydłubać z lost+found nowszą wersję czegoś_tam). Chociaż fakt, że wcześniejszy chmod -R og-r /lost_found mógłby być niezłym pomysłem. Dałeś dupy, teraz musisz z tym żyć. Ludzie dzielą się na dwie kategorie: tych, który robią backupy i tych, którzy zaczną je robić. Poza tym, wyobraź sobie sytuację taką: kupujesz konto w jakiejś firmie, robią backupy itd., nagle sru! zepsuło się. Przywróćcie backup. Ups, backupu jest 10% bo komuś się omsknął palec i backupy trafiały na zły filesystem (o wiele za mały). Odpowiedzialność usługodawcy i tak się pewnie ograniczy do góra kilkumiesięcznego abonamentu a Ty zostaniesz w czarnej dupie dokładnie tak samo jak teraz. Masz dane, na których Ci zależy? To je backupuj i nie oglądaj się na niczyje gwarancje, bo de facto nikomu innemu na tych danych za bardzo nie zależy (marketingowy bullshit notwithstanding). [disclaimer: akurat wódki to z ahesem nie piłem, co trzeba kiedyś nadrobić]

To masz za swoje -- po co odkopujesz temat zamiast założyć nowy? Kto Ci serwuje to 403? masz uruchomione to php? (jeżeli tak to po ubiciu zmienia się błąd?) Uruchom php pod strace: strace -ff -s 10000 php-fcgi -b 127.0.0.1:9000 2>&1 | grep index.php i spróbuj wywołać to /index.php w przeglądarce. Widzisz coś dziwnego na strace (np. ścieżki złe czy coś)?

Pewnie odbijasz się o limit VM, zmniejsz apc.shm_size albo zwiększ ulimit -v. I pod żadnym pozorem nie uruchamiaj php z roota! Spróbuj z php-fpm tak jak tu już pisał nrm. EDIT: przeczytaj ze zrozumieniem bo (na pierwszy rzut oka) masz dziurawą konfigurację: http://cnedelcu.blogspot.com/2010/05/nginx-php-via-fastcgi-important.html

Tu nie ma jakiejś specjalnej metody. Po prostu _nie_ rysuj tego pola tekstowego na obrazku tła a wygląd ustal w stylach dla <input>. Na przykład: http://www.jankoatwarpspeed.com/post/2008/07/27/Enhance-your-input-fields-with-simple-CSS-tricks.aspx (zaokrąglone rogi i ikonkę też da się zrobić). Z ciekawości, ile zapłaciłeś za projekt graficzny? Ciąłeś sam czy robił to grafik/ktoś inny?

Aż z radości Cię zaplusowałem (jakiś mod mi to anuluje?) zamiast odpowiedzieć. Po pierwsze meminfo z openvz jak widzisz jest głównie humorystyczne (zero cache itd., bo tak ogólnie wyliczenie RSS dla kilku wybranych procesów nie jest całkowicie trywialne). Po drugie, nie podałeś konfiguracji obu mpmów (tak, też umiem skonfigurować preforka tak że zajmie mniej pamięci niż worker). Większość tej pamięci to jest (IIRC) scoreboard, którego wielkość (IIRC takoż, dawno we wnętrznościach apache'a nie grzebałem) zależy w zasadzie wyłącznie od MaxClients (a dokładnie to liczby procesów * liczby wątków). Porównaj Pss z /proc/<pid>/smaps w obu MPMach na porównywalnej konfiguracji, myślę że nie zauważysz różnicy, o którą warto kruszyć kopie. To że worker zużywa więcej przestrzeni adresowej per proces to też nic specjalnie dziwnego ale nie przekłada się na zużycie pamięci fizycznej (jak masz domyślne bodajże 2MB na stos to na wstępie masz 2MB VM per wątek, z czego realnie wykorzystane będzie w porywach kilka 4KB stron). Najbardziej debilne narzędzia rzeczywiście pokazują użycie VM zamiast RSS (vserver-stat np., z tego co widzę to /proc/meminfo z openvz też). Porównaj sobie na wyniku ps przydzieloną przestrzeń adresową (VSZ) z rzeczywiście użytą (RSS, choć właściwie PSS powinien być, ale tu błąd będzie porównywalny dla obu mpmów) -- te 200 MB nie znaczy absolutnie nic, istotne jest to oszałamiające 2MB z ogonkiem (z czego większość jest dzielona z parentem zajmującym <2MB ale ps tego nie pokaże). awk '/^Pss: / { sum += $2 } END { print sum " KB" }' < /proc/PID/smaps EDIT_za_edit: Xen pokazał Ci prawdziwe zużycie pamięci fizycznej, czyli mniej więcej to, o czym pisałem powyżej. "Wiadomo, że Xen lepiej zarządza pamięcią" -- mocne

To coś nowego. Jesteś w stanie jakoś tę tezę obronić (bez odsyłania do google)?

IMHO od tego zacznij bo może się okazać że varnish weźmie na klatę 90% ruchu i nie będzie po co optymalizować apache'a. Jednocześnie za mała (względem liczby odwiedzających) i za duża (względem możliwości maszyny). Jakbyś się nie kręcił, dupa zawsze z tyłu. No jedziesz po bandzie. Ledwie 200MB (w porywach) na page cache to proszenie się o OOM i zarżnięcie wydajności maszyny (co zdążyłeś już zauważyć). mpm_worker jest OK, zwłaszcza jak uruchomisz php po fastcgi (choć jak dla mnie to masz mało procesów a dużo wątków per proces). Jak uruchamiasz php, bo w wątkowanym mpmie mod_php AFAIK nie działa stabilnie? Inna sprawa że jak masz serwer pod tę jedną aplikację to poświęć parę godzin na konfigurację nginxa + fastcgi + php_fpm, na takiej maleńkiej maszynce powinieneś zobaczyć dużo więcej wolnej pamięci.

Kombinacja czarnego z pomarańczowym to akurat jedyne, co mi się w wyglądzie tej strony podoba. Biały tekst na pomarańczowym tle? Animacje w menu (a zwłaszcza pod nim, te trzy niebieskie) są straszliwie nieżyciowe, wyszukiwarka jest zrobiona fatalnie (pole formularza narysowane na obrazku tła zamiast ostylować jak biały człowiek <input>?? do tego jako rzucający się w oczy rozmazany jpg), itd. Sorry ale to jest po prostu brzydkie. Całość może zrobiłaby szał tak z 10 lat temu.

Jeżeli tak skonfigurowałeś serwer że może zeżreć cały ram+swap, to to robi. *Zmniejsz* MaxClients bo widać że ustawiłeś za dużo jak na możliwości maszyny, postaw z przodu jakieś cache'ujące proxy typu varnish (skonfiguruj ładną 503kę przy przeciążeniu). Możesz też zastąpić apache'a nginxem/lightym/litespeedem (pomoże jeżeli większość treści to static, bo jeżeli 90% to odwołania dynamiczne to cudów nie ma, php_czy_co_tam swoje musi zeżreć). Jeżeli to php to eacceleratora/apc/innego_cache_bajtkodu używasz?

W dwa lata to można od zera napisać silnik 3d w haskellu Książki do IT to z reguły nieporozumienie (nie mówię o klasykach pokroju Knutha ale dla aktywnie rozwijanych obszarów książka w momencie wydania jest nieaktualna). So? Dlatego IMHO najlepiej walczyć z kodem w praktyce a teorię uzupełniać sobie równolegle. Po cholerę ma się chłop męczyć z GoF jak jeszcze nie rozumie po co są funkcje? No dobra, przyjąłem milczące założenie że OP jednak angielski zna. "Co jaka funkcja robi" to jest akurat najmniejszy problem (z reguły wynika to z nazwy a poza tym albo jest udokumentowana, albo masz jej źródła i możesz sobie przeczytać). Co Twoim zdaniem robi metoda .is_valid() klasy ModelForm z modułu django.forms.models? Jeżeli kiedykolwiek słyszałeś o MVC (tym webowym) i formularzach HTML to na 99% odpowiesz poprawnie bez znajomości Pythona czy Django i zaglądania do dokumentacji (nie mówiąc już o źródłach). Myślę że już się zorientował że jak chce szybko to niech komuś to zleci. Akurat soft pod demotywatorami jest trywialny. Trochę komplikuje go skala, w której działa serwis np. demotywatory.pl ale sama idea jest do napisania w jedno-dwa popołudnia. To nie soft decyduje o powodzeniu takiego przedsięwzięcia. "PHP a nawet HTML"? Co ma jedno z drugim wspólnego? HTML (CSS, JavaScript) jest zupełnie obok platformy, na której tworzysz aplikację. Jasne że jest najpopularniejszy ale w dawnych czasach pisało się serwisy w WMLu (pamiętacie WAP?), teraz aplikacje webowe coraz częściej serwują goły JSON (a cała prezentacja to statyczny HTML + JS).

(cały czas zakładam że OP chce tę stronę napisać samodzielnie i czegoś się przy tym nauczyć, bo jeżeli chce po prostu mieć działający serwis nie ważne jak to niech to po prostu zleci, będzie najszybciej) Myślę że spora część tych dwóch lat to byłoby oduczenie się złych nawyków, których nabierasz pisząc w php zgodnie z tutorialami z czasów wczesnego php4. Poziom materiałów o php w sieci jest przerażający (ze sporymi kawałkami php.net włącznie). Wpinając się w gotowy produkt masz za darmo całą masę udogodnień, których nie musisz wynajdować od nowa (szablony, abstrakcja bazy danych itp.), poza tym wymusza jakąś tam dyscyplinę w kodzie (np. model "webowe MVC", który z prawdziwym MVC nie ma wiele wspólnego ale i tak jest fajny). Pod gotową platformę nie piszesz też w próżni -- masz górę przykładowego kodu do analizy i modyfikacji. Popatrz na tutorial do Django -- naprawdę prześledzenie go wymaga dwóch lat nauki?

+1 Odrobinkę to nie na miejscu IMHO. Sam się lubię powyzłośliwiać jak ktoś głupoty pisze ale trzeba odróżnić głupka od początkującego. -0,5 Czemu akurat PHP? Tak źle mu życzysz? Webappki dużo przyjemniej się w Pythonie pisze (czy to z kobyłami typu Django, czy z mikroframeworkami a'la Flask). Masz rację z tym, że nie da się w 5 minut nauczyć programować, ale w sytuacji OPa zaczynanie od <? print "<h1>hello world</h1>"; ?> jest zupełnie bez sensu. Zanim się nauczy dobrze pisać, nabierze złych nawyków albo straci zapał i zrezygnuje. W rok-dwa nie osiągnie poziomu, który pozwoli mu przeskoczyć gotowce typu wordpress, a w XXI wieku pisanie typowych serwisów (CMSów) od zera trochę straciło sens. Przedpiśco! Postaw sobie jakąś gotową platformę typu wordpress, drupal czy inna joomla i pobaw się na niej. Pościągaj przykładowe moduły (jest tego stado), poczytaj ich kod, spróbuj coś zmienić, dopisać. Składnia języka jest drugorzędna i wsiąknie sama. Tutoriali i opisów jest masa, ale i tak myślę że szybciej nauczysz się czytając (i pisząc!) kod niż czytając o kodowaniu. Od samego początku używaj jakiejś kontroli wersji, żebyś mógł zobaczyć "co ja właściwie zmieniłem że zaczęło działać" albo łatwo wycofać zmiany, którymi zepsułeś wszystko (możliwość wygodnego powrotu do znanej działającej wersji zachęca do eksperymentów). Ja korzystam z gita ale mercurial albo subversion mogą być łatwiejsze do ogarnięcia. Byle nie cvs.

Rzeco? Podałeś rozwiązanie (stosowane przez dystrybucje zresztą), ja podałem inne, które uważam za lepsze (czytelniejsze), z uzasadnieniem. Póki co jeszcze Ci matki nie obrażałem. Jakbym chciał się czepiać to czepiłbym się do bezsensownego cd (cp -f ... /etc/localtime wystarczy) i do użycia CET zamiast poprawnej strefy czasowej (dla Polski Europe/Warsaw). Ale tak zasadniczo to wybacz łaskawie że ośmieliłem się opowiadać bajki że Twój sposób nie jest jedynym poprawnym i najwspanialszym na świecie. Hint: jak trochę poadminujesz różnymi rzeczami to dojdziesz do wniosku że "działa" to nie jedyny wyznacznik dobrego rozwiązania (warunek konieczny ale dalece niewystarczający).

Symlink jest IMO lepszy -- od razu widać, jaka strefa czasowa jest ustawiona. Dystrybucje lubią kopiować plik do /etc/localtime (tak jak w Twoim przykładzie) ale nie mam pojęcia czemu. Ma o tyle, że eliminuje konieczność używania ntpdate (jeżeli rzeczywiście zegar na hoście jest poprawny a tylko TZ zła). Zresztą jeżeli strefa czasowa jest zła to ntpdate nic nie zmieni, po prostu czas będzie zły o bardzo_dokładnie_dwie_godziny. Albo napisać skrypt startowy, który tę strefę czasową ustawi. Trochę ładniej IMHO bo skrypt widać od razu a chattr +i /etc/localtime nie.

To weź mi w aucie zawieszenie zrób, bo nie umiem. OP: znajdź kogoś, kto Ci zrobi ten serwer od początku do końca (i dalej będzie się nim opiekował) i to raczej prędzej niż później bo administracja metodą gwałtu zbiorowego ma jedno możliwe zakończenie.

I to jest rozwiązanie? Dalej nie będzie umiał a z kolejnym problemem znów sobie nie poradzi.