blackfire

Następnym razem dopiero w trumnie

Hm, pewien jesteś? Ja zakładam, że i tak efektywnie każda maszyna jest wydzielona w swoim VLANie (bo inaczej po co /32), więc jedynym sąsiadem serwera jest router, który i tak tam być musi. IMHO można przenosić tak samo łatwo jak przy adresacji /32. Tak czy inaczej masz trasę do każdego hosta osobno. Różnica polega na tym, że router musi mieć dodatkowo adres z każdej obsługiwanej /24 a przydzielając /32 może mieć jeden adres w ogóle, bo i tak się go ustawia z łapy.

Hm. Czyli routing na serwerze masz w stylu: 188.116.0.30/32 dev lo # mimo że adres na eth0; tego nie widać w tablicy main 188.116.0.1/32 dev eth0 # trasa do routera default via 188.116.0.1 dev eth0 # reszta świata via router tak? Jeżeli router nie wie, że ma inną podsieć dla tej adresacji (/24 vs /32), to będzie wysyłał ICMP redirecty ("po cholerę mam forwardować pakiet do 188.116.0.40, sam se go tam wyślij"). Jak zareaguje host, ciężko wyczuć, chociaż możliwe, że będzie działać jak w reklamie. Jeżeli router wie o tych czarach (np. ma wyłączone wysyłanie redirectów), to oczywiście nie ma problemu. Minus (zwłaszcza jeżeli to nie Ty zarządzasz serwerami a ktoś inny) jest taki, że tablica routingu jest dość nietypowa (trasę do routera trzeba dodać z łapy/OSPFem bo nie wynika z adresacji interfejsu). Jeżeli jest to wykonalne, to chyba zdrowiej jest dać serwerom /24, bo i tak żeby /32 miało sens to musisz je odizolować jakimiś VLANami od siebie, a wtedy przynajmniej masz routing, który ogarnie 95% gospodyń domowych z Gdańska (/24 na eth0, default via coś normalnie osiągalne via eth0). Jakie masz argumenty "za"? Ciekawm.

Fakt, przesadziłem. To tylko te 99% wyjątków psuje opinię reszcie. "jest dobre" + "zostawienie problemów jest prawie murowane". xorg, Archi: ja nie piszę tu o zawodowych programistach, którzy i w brainfucku napiszą elegancki kod. To jest wątek o początkującym, który zaczął niestety od PHP. Skoro się uczysz, to ucz się tak, żebyś nie musiał się tego potem zaraz oduczać. Pisanie w czystym PHP to trochę jak growl wśród metalowych wokalistów. Jeżeli umiesz czysto śpiewać ale wolisz growl (który wbrew pozorom jest trudny), to jak najbardziej OK. Ale jeżeli drzesz ryja bo nie umiesz inaczej, to jesteś dupa nie wokalista.

Tak. Znaczy IMHO naprawdę lepiej użyć jakiegoś frameworka, który ogarnie za Ciebie dużo więcej takich tematów, które wydają się proste do momentu, kiedy chcesz to zrobić dobrze. Ale już samo PDO Ci wiele pomoże. Prosty argument: masz definitywnie załatwioną kwestię SQL Injection (no, chyba że się bardzo postarasz). Poza tym PDO to ucywilizowanie interfejsu (spójny sposób komunikacji z różnymi bazami danych, wyjątki zamiast zwracania false/null/-1 itp.). Niezależność od konkretnej bazy danych to trochę mit, ale i tak Ci to masę roboty oszczędzi przy migracji MySQL->PostgreSQL. http://wiki.hashphp.org/PDO_Tutorial_for_MySQL_Developers na pierwszy rzut oka wygląda sensownie. Zobacz zwłaszcza sekcję "Running statements with parameters" i porównaj z podejściem klejącym zapytanie w PHP. BTW, co to jest SQL Injection to jest nawet na polskiej Wikipedii: http://pl.wikipedia.org/wiki/SQL_injection ale pomiń te bzdury o addslashes(). To *nie* to samo co DBI::quote() i nie zabezpiecza w pełni przed SQL Injection.

Skrypty pisane od zera przez hobbystów dają też ogromną satysfakcję adminom, jak muszą blokować konta takim hobbystom i tłumaczyć się RBLom, czemu od nich wychodzi tona spamu. Oprócz tego przyjemnie spędzi czas rzesza innych adminów, którzy ten śmietnik muszą odebrać i przeanalizować. Jak chcesz pisać od zera to nie pisz w PHP tylko w asemblerze (albo gołym kodzie maszynowym), w końcu z PHP dostajesz kilkadziesiąt MB gotowca. Przynajmniej jak już skończysz to ja nie będę musiał odbierać wysłanego przez to spamu bo już pewnie opuszczę ten łez padół. "A co do tych filtracji" - Windows prawda. Gdyby to było takie proste, to SQL Injection by wyzdychało śmiercią naturalną. Słowa bym nie powiedział, gdybyś w ten sposób szkodził tylko sobie. Ale takie rękodzieło to wrzód na dupie całego Internetu i wszyscy ponosimy tego konsekwencje.

Nie. "Odpowiednie filtrowanie" to obejście problemu, który w ogóle nie powinien istnieć, a który _rozwiązuje_ (nie _obchodzi_) użycie współczesnego interfejsu do baz danych (chociażby PDO). Wiesz, że w jakimś dwubajtowym kodowaniu jeden z chińskich ideogramów zawiera ASCII 0x5c, czyli backslash? Zgadnij, jak to wpływa na "zabezpieczenia" oparte o addslashes/stripslashes/wytnij_slashes_real_escape_string. Zamiast się zastanawiać, czy na pewno Twoje "rozwiązanie" z filtrowaniem/escape'owaniem danych od klienta działa, możesz zlikwidować całą klasę problemów. Użycie jakiegoś frameworka (jakiegokolwiek używanego nie tylko przez autora i jego psa) chowa przed Tobą tego typu pomysły i generalnie wymusza zdrowsze podejście (oddzielenie logiki biznesowej od prezentacji itp.). Kiedyś jeszcze lepienie w gołym PHP miało sens, jak nie było powszechnych frameworków i darmowych SaaSów do wszystkiego, ale teraz naprawdę nie jestem w stanie znaleźć jakiegokolwiek uzasadnienia poza masochizmem.

Największą pomocą będzie jak ZOSTAWI GOŁE PHP W CHOLERĘ. To nieodwracalnie uszkadza mózg i wpaja najgorsze możliwe wzorce. Piszę całkowicie serio. PHP przykryte jakimś używalnym frameworkiem (na co dzień piszę w Django, więc z głowy nie wiem, który jest używalny, dlatego odesłałem do webmastah) może być fajną platformą do developmentu. Ale takie gołe: <? mysql_query("INSERT INTO tab VALUES($_GET[foo])") ?> powinno być prawnie zakazane pod karą rozstrzelania.

Primo: Po czym wnosisz, że przedpiśća nie ma kolumny na klucz główny? NULL jako pierwszy parametr sugeruje (niestandardowe, ale używalne w mysqlu) użycie domyślnej wartości. Jeżeli pierwszą kolumną w definicji był właśnie klucz główny, to NULL jest o niebo zdrowsze niż '' (chociaż w zasadzie to taką kolumnę należałoby pominąć). SQL l3szcza jest fatalny, ale to akurat chyba najmniejszy z jego problemów. Secundo: UTFG: SQL injection. Właśnie wystawiłeś całą swoją bazę internetom do zapisu. l3szcz zresztą też. Tertio: mysql_query. Proszę Cię (i przedpiścę), nie w XXI wieku. Nie po to powstało PDO, żeby to truchło jeszcze ruszać. Zapomnijcie o istnieniu tak niskopoziomowych i skopanych na etapie samego projektowania funkcji. Quarto: l3szcz, użyj jakiegoś frameworka, nie męcz się z gołym PHPem. Np. tutaj sobie poczytaj: http://webmastah.pl/

Może. OpenVZ tykałem dawno temu i raczej z daleka.

OTOH, dużo tego nie ma, parę plików zerowej długości, na pewno nie 30 GB. Ile Ci brakuje _teraz_ miejsca? O ile się różni zajęte miejsce z "df -B 1048576" od policzonego przez "du -xsm /"? Ile masz plików w /tmp (nawet pustych)? Ich liczba rośnie z czasem? Zakładam że /tmp masz na tym samym filesystemie co resztę, a nie na jakimś tmpfs na przykład. BTW, jak to jest OpenVZ to kojarzy mi się, że ten ich SimFS kłamał w żywe oczy jak mu się miejsce na hoście kończyło, ale nie tłumaczyłoby to, dlaczego reboot pomógł. BTW2, ktoś kojarzy, co to za blockdev 0,147? Coś z OpenVZ?

666. Jaki sens ma +x dla /dev/null? @Aimer, Sprawdź przy okazji (ls -l /dev/null), czy /dev/null jest urządzeniem, bo może coś je podmieniło zwykłym plikiem. Pierwsza kolumna wyniku ls ma wyglądać tak: crw-rw-rw- (i ew. kropka jak używasz SELinuxa)

Masz jakieś otwarte usunięte pliki. Skopana rotacja logów? lsof | grep -F '(deleted)' Przedostatnia pozycja (przed nazwą) to jest numer inode'a, jeszcze wcześniejsza to rozmiar. Mój bash ma jakieś 950 KB na dysku: bash 15414 blackfire txt REG 8,1 950896 6815748 /bin/bash

Ja bym pewnie zaczął od uruchomienia obu procesów pod strace -ff -ttT -s 10000 -o fcgi.strace /path/to/php-fcgi --opcje-php (dla php-fpm analogicznie). Masz duże różnice w czasie wykonania samego kodu PHP, co nie ma żadnego sensu patrząc po architekturze php-fcgi i php-fpm (po odebraniu requestu obydwa robią dokładnie to samo). Dasz sobie wyciąć obie nerki, że obydwa phpy korzystają z tych samych ustawień (php.ini)? Porównywałeś `phpinfo()`? php-fpm na pewno korzysta z opcache? Wyłącz go w obu SAPI i wtedy porównaj wyniki, może się okaże, że się to jakoś żre z fpmem. Może masz php-fpm skonfigurowane tak, że uruchamia jakąś dużą pulę procesów, która wypycha cache z pamięci?

USERA, USERB to są różne konta unixowe? Mówisz o chown'owaniu po synchronizacji więc zakładam że tak i że możesz zrobić ssh USERA@serwer i ssh USERB@serwer. Jeżeli nie, to daj znać bo wtedy to będzie trochę inaczej wyglądać. W takim układzie nie potrzebujesz żadnego gitolite'a (o gitosisie zapomnij, nie jest od lat utrzymywany), masz po prostu dwa niezależne repozytoria, każde na swoim koncie. Przeczytaj tego posta, żeby się zorientować w praktykach związanych z obsługą zdalnych repo gita, powinien Ci wyjaśnić, dlaczego masz użyć dwóch repo na każdym koncie: http://www.megiteam.pl/blog/2009/11/01/zeby-bylo-git/ Jak już na każdym koncie masz katalog na repo (powiedzmy ~/app.git) i katalog na drzewo robocze (powiedzmy ~/app), to po prostu ustawiasz odpowiednie remote'y w swoich lokalnych repozytoriach, coś typu: git remote add origin ssh://USERA@SERWER/~/app.git Dla serwisu USERB analogicznie. Pamiętaj, żeby odciąć dostęp do katalogu ~/app/.git (w katalogu roboczym), na przykład .htaccessem. Jeżeli -- czego się trochę spodziewam, czytając o zmianie właściciela plików -- pchasz zmiany do tych repozytoriów logując się na konto roota, to przestań i nie rób tak więcej. Jak najbardziej da się wykonać chown po pchnięciu zmian, ale to jest na tyle zły pomysł, że nie podam Ci rozwiązania.

Konfiguracja nginxa jest pełna (włącznie z nieistotnymi pierdołami typu użytkownik, na jakim działa) i w zupełności wystarczy do serwowania streamingu. Wywołanie ffmpega też. Czego Ci brakuje? Taki był też cel tego posta -- pokazać streaming od początku do końca, bo najwięcej problemów jest na styku. crtmpserver skonfigurowany poprawnie, ffmpeg wywoływany poprawnie a stream nie idzie ICMPTZ. Możemy jeszcze pomyśleć nad follow-upem z opisem osadzenia jwplayera, ale tam już zupełnie nie ma magii i niekoniecznie jest co zepsuć. Przede wszystkim nginx-rtmp ma typowe nginxowe podejście, subtelne jak ruski bimber. Robi totalnie niezbędne minimum (podejrzewam że nawet nie zagląda za bardzo do środka strumienia), przez co nie ma za dużo ruchomych części a całą konfigurację można łatwo zrozumieć. Umie na przykład przekodować strumień na inną jakość, ale polega to na tym, że wywołuje ffmpega wycelowanego w swój strumień i streamuje jego wynik. Proste i niezawodne. IMHO zupełnie inna jakość w porównaniu do red5, w którym nawet nie znalazłem, gdzie on konfigurację trzyma.

Z doświadczenia: 1. Baza to nie kolejka. Trzymanie tam zadań do wykonania to generalnie głupi pomysł, chociaż jak masz je trzy na krzyż to możesz tego nie zauważyć. Jak chcesz sobie taką kolejkę zrobić, to użyj do tego produktu, który do tego służy, np. RabbitMQ albo Redisa. 2. Push, nie pull. Z panelu pchaj informacje po dobrze zdefiniowanym interfejsie do jakiegoś demona, który nie ma dostępu do żadnej centralnej bazy. Na początku prościej jest rzeczywiście wystawić sobie całą bazę ryjem w LAN i grzebać po niej z serwerów ale ugryzie Cię to w dupę przy pierwszej zmianie schematu (albo będziesz musiał robić deploy wszędzie_natychmiast_w_jednym_momencie, albo wspierać rozjechane wersje panelu, demona i schematu bazy -- nie ić tom drogom). Coś, co działa z roota, musi być maksymalnie proste, tępe i łatwe do przetestowania. 3. KISS. Nie kombinuj, nie wymyślisz lepszego SSLa, lepszego HTTP i lepszego JSONRPC. My jedziemy na własnym mtrpc [1, 3], które sprowadza się do JSONRPC po AMQP, ale jeżeli nie masz (i nie potrzebujesz do innych rzeczy) brokera AMQP, to pomyśl po prostu o komunikacji po ssh (z multipleksowaniem sesji[5] ma całkiem zadowalającą wydajność). Trochę możesz sobie uprościć życie gotowcem typu ansible[4, 6] 4. Jeżeli dojdziesz do wniosku, że musisz robić jakieś własne mechanizmy uwierzytelniania, to usiądź i poczekaj aż Ci przejdzie. To bardzo rzadko jest dobry pomysł. Użyj https i certyfikatów klienta, kluczy ssh albo czegokolwiek (nawet http basic auth), ale nie wymyślaj koła na nowo. 5. Konkretny mechanizm RPC to rzecz gustu. Są ludzie, którzy z własnej woli używają SOAPa. Realnie i tak nie będziesz tego z łapy generował, a na tcpdumpie jsonrpc jest mniej więcej tak samo czytelny jak xmlrpc (zwłaszcza szyfrowany ;]). Wybierz coś, co ma wygodny interfejs w Twoim języku programowania. My (MegiTeam) obecnie mamy serwery pythonowe rozmawiające po JSONRPC-over-AMQP i to RPC jest ich jedynym interfejsem do świata zewnętrznego (nie mają wjazdu do żadnej bazy itp.). Architektura jest fajna i mocno elastyczna (zwłaszcza z dodatkowym celery[2]), natomiast jak nie potrzebujesz czegoś wymyślnego, to pomyśl o czymś takim: - SSH z multipleksowaniem połączeń (opcjonalnie zostawiasz `ssh -Nf serwer` w tle dla każdej maszyny) - wjazd po kluczu ssh na roota ograniczony do jednego polecenia -- tym poleceniem jest jakieś Twoje narzędzie (napisane w czymkolwiek), które jeszcze raz waliduje sensowność wszystkich parametrów (nawet jak Ci panel przepuści założenie usera z uidem 0, dobrze mieć jakąś ostatnią linię obrony), a potem robi. - protokół możesz mieć jakiś ustandaryzowany typu jsonrpc, albo jechać po bandzie z "ssh serwer 'admintool add-user foo:$1$xxxxxx$...:1234:1234:...'", wszystko zależy od tego, co będziesz miał po stronie serwera i w czym Ci się będzie to dobrze pisać (parsowanie SOAPa w bashu to trochę sport ekstremalny) 1. http://www.megiteam.pl/blog/2010/05/23/amqp/ 2. http://www.megiteam.pl/blog/2012/06/10/umarl-agent-niech-zyje-agent/ 3. http://github.com/gnosek/mtrpc 4. http://www.slideshare.net/gnosek/ansible 5. http://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing 6. http://ansible.cc/

Tu oczywiście piszesz o Django, nie o Pythonie jako języku. Djangowy ORM jest jaki jest, ale nie wyobrażam sobie powrotu do rzeźby typu "SELECT * FROM a_table WHERE id=".$_GET['id']. Jeżeli wybierzesz inny framework to pewnie z pudełka dostaniesz SQLAlchemy, które też ma wielu fanów (i chyba odrobinkę bardziej bezpośrednio mapuje się na SQL). Ja osobiście gorąco polecam Django każdemu początkującemu chociażby dlatego, że z tego Django tak łatwo nie "wyrośnie" (zdecydowanie się nadaje i do poważnych aplikacji). Nie mam serca polecić komukolwiek czystego PHP jako jakikolwiek język, nieważne czy pierwszy, czy kolejny. Nie ić tom drogom. Jeżeli PHP, to tylko z jakimś współczesnym frameworkiem, przykrywającym cały najgorszy syf[1]. Symfony2? Zend? Nie wiem, nie jestem na bieżąco. Widać moje aplikacje nie są nowoczesne A tak poważnie to co masz na myśli? Wydajność? Nie robiłem benchmarków ale nie widzę różnicy vs. PHP. Podejrzewam, że dla każdego benchmarka istnieje benchmark o identycznym kierunku i przeciwnym zwrocie a realnie to i tak wąskim gardłem jest baza danych. Funkcjonalność? Masa rzeczy przychodzi od razu z Django, a nawet jak nie to są wtyczki (django-rest-framework na przykład jeżeli nowoczesnym wymaganiem jest wsparcie dla REST w kilku linijkach kodu). Dokumentacja? na php.net może i jest więcej treści (chociaż porównując dokumentację python+django do realnie używanych funkcji php to wątpię) ale poziom woła o pomstę do nieba (zwłaszcza komentarze; raz na sto trafi się ktoś, kto ma choć blade pojęcie, o czym pisze, od czytania reszty można dostać raka). Tomiz, chcesz języka logicznego i łatwego w nauce? Python. PHP jest absurdalnie wręcz nielogiczny (link poniżej), a nauczyć się go trudno ze względu na fatalną jakość materiałów (na pewno są też i dobre ale giną w morzu badziewia). Wyrobisz sobie złe nawyki rodem z lat 90., nieodwracalnie uszkodzisz mózg, po co to komu 1. http://me.veekun.com...-of-bad-design/

Właśnie wyguglałem. No i? "Enthusiast" to nie zastosowania serwerowe. Zamiast 4-way SLI większy sens miałby IPKVM. Chociaż OK, procesory serwerowe są. Dalej stoję na stanowisku że podkręcanie procesorów serwerowych (uściślając: procesorów w serwerach, a nie Xeona w smoku do grania) jest zupełnie bez sensu. Powiedzmy że staram się podnieść średni poziom wtajemniczenia, choćby minimalnie Spodziewam się, że podwyższenie częstotliwości jednak wymaga wyłączenia (przejścia w odpowiedni C-state) połowy rdzeni. Mam wrażenie że tak jest prościej i bezpieczniej, a rynek overclockerów Opteronów jest na tyle mikry, że nie ma powodu się nim przejmować.

Chcesz overclockować procesor serwerowy? Serio? BTW, te 16 rdzeni to takie nie do końca przemyślane ubarwienie rzeczywistości* przez marketing AMD. Masz do dyspozycji 16 jednostek całkowitoliczbowych i 16 zmiennoprzecinkowych (128-bit; mogą też pracować jako 8 jednostek 256-bit). Pod każdym innym względem to są de facto maszyny 8-rdzeniowe (z czymś w stylu HT Intela) i to niespecjalnie mocne. A tryb turbo fajna rzecz, zwłaszcza jak scheduler w systemie to wspiera. *ładniej brzmi niż ordynarna ściema, nie?

http://hostingmeeting.pl/index.php/agenda/ As in, WTF? Serio cały dzień wypełniony 15-min ścinkami od sponsorów? Zero jakiejkolwiek treści? Reklam nawet z adblockiem mam dookoła wystarczająco dużo. W sumie to myślałem żeby się przejechać ale turlać się ileś godzin żeby wyjść na piwo wieczorem to trochę bez sensu jest. Kurde, na PyConie Microsoft chociaż próbował zrobić merytoryczną prezentację o Azure (jak wyszło to inna sprawa ale próbował). Tutaj nikt widać nie udaje że chodzi o coś innego niż wepchnięcie Oracle'a na serwerach HP z procesorami AMD, pod kontrolą VMware. Czy jakoś. Ble. Jak ktoś będzie to niech się pochwali ile dostał "pendrive'ów za ankietkę"

Karty kredytowe ≠ płatności online, przynajmniej w Polsce. Kredytówki nie mam (świadomie, co chwila mi chcą jakąś sprzedać) ale i tak udaje mi się bez problemu płacić w sieci. Czary? BTW, przykładowe PayU Protected Payment akurat karty kredytowe to obsługuje najwolniej (jakieś 24h), więc w dyskusji o skróceniu czasu rezerwacji są kredytówki są raczej _kontr_argumentem BTW2, to że ja bym bardzo chciał tylko i wyłącznie PayU akceptować, nie znaczy że nie ma ludzi, którzy jak nie zrobią przelewu w okienku to im z tym źle. Chcesz im efektywnie zabronić rejestracji domen w piątki? Może się mylę ale wpłaty na jeden wspólny rachunek muszą być obsłużone ręcznie ("wpisz <foo> w tytule przelewu" to wołanie na puszczy) a indywidualne konta bankowe per klient to mało popularna sprawa. Zobaczycie że skończy się tym że będziemy przez EPP te rezerwacje licytować Dobra, dyskusja była fascynująca ale dla mnie EOT. Hej ho, hej ho, w kierat by się szło

Nie. Płatne są wywołania <domain:create> jak domena jest zarejestrowana (np. nieudana próba przechwycenia wygasającej domeny). <domain:check> ("czy domena jest wolna?") można tłuc bez ograniczeń. Płatne <domain:check> to byłaby rzeźnia i studnia bez dna dla registrarów. Zdefiniuj parę. Bo może się okazać że (minimalne) opłaty za rezerwację ograniczyłyby skalę polowań na domeny (utopienie paru stówek na rezerwację kilku tysięcy domen co dwa tygodnie to dość droga impreza, nawet jeżeli sporo tańsza od po prostu zarejestrowania tych domen). "Gimnazjalista z kieszonkowym" raczej ma małe pole rażenia i takimi bym się nie przejmował na dłuższą metę (chociaż fakt, nie znam tego rynku aż tak dobrze -- grasują tysiące gimnazjalistów polując na każdą domenę czy jednak jest paru dużych graczy typu dropped?).

Z tym się zgadzam że 2 tygodnie to sporo (2-3 dni robocze miałyby sens). Tak samo z tym że mechanizm rezerwacji jest nadużywany. Z drugiej strony niekoniecznie podoba mi się fakt, że mogę stracić domenę przez to, że mam konto w innym banku niż rejestrator (albo rejestrator żyje w XIX wieku i wszystkie wpłaty obsługuje ręcznie). Zdaję sobie sprawę z tego, że niekoniecznie czyste intencje rejestratorów są ciężkie do obejścia, zwłaszcza bez karania normalnych rejestratorów z nieuczciwymi klientami (dlatego kosmiczne kwoty za rezerwację są IMHO nierealne). Zamiast utrudniać użycie rezerwacji, trzeba IMHO utrudnić ich użycie do wygasających domen. Chociażby ograniczając zapytania <domain:check> dla danej domeny do jakiejś tam częstotliwości (nie mając authinfo/nie będąc registrarem dla danej domeny nie dowiesz się od NASKu kiedy wygasa co do sekundy, nawet jeżeli jesteś partnerem więc i tak musisz macać co jakiś czas). Albo zabronić rezerwacji przez jakiś czas od wygaśnięcia domeny (to byłoby upierdliwe bo wymagałoby rozszerzenia protokołu ale dałoby się zrobić). Zabicie rezerwacji siłą rzeczy rozwiąże problem z ich nadużywaniem ale IMHO to wylewanie dziecka z kąpielą. Rezerwacje tak, wypaczenia nie!

Świetny argument. Nie róbmy lepiej bo inni robią gorzej i żyją.