@borysses: @Kuraito: wyrzucilismy footer z jednego diva, pod nowy styl :P

@Writer: @Paralotnia: to zmiany pod nowego cssa.... stay tuned

@Paralotnia: ?

@Paralotnia: nie :E

@Paralotnia: sprawdź teraz ;)

@elDominiko: in progress...

@Writer: my zresztą też. Chodzi o to, że każda instytucja przetwarzające dane osobowe powinna miec publicznie dostępny adres siedziby i podmiot odpowiedzialny... Trochę śliska sprawa, dlatego taki wykop ma to podane.

@grzegorz_brzeczyszczykiewicz: wiesz, mozna zalozyc albo naszą albo jego rację. Nie będę próbował cię przekonywać w te czy we wte, bo to nie ma sensu. Jesli faktycznie zaszła pomyłka, to niech scape się sam z nami skontaktuje.

@grzegorz_brzeczyszczykiewicz: @Writer: @borysses: @Karramba:
Po kolei. Co do scape...
2014-06-15 09:05:26.242Z Dostałem PW z prośbą o usunięcie konta (użytkownik zalgowany poprawnie, z adresu IP 89.191.164.XXX), co też zostało dokonane.

Co do regulaminu. Jest z nim problem - mianowicie z akutalną bazą strims .pl działa nielegalnie :) dux jest w trakcie pisania naszego, który zarówno daje jasno do zrozumienia zakres działania portalu, zabezpiecza użytkowników jak i jest blachą na dupę dla nas (uokik i te sprawy).

@borysses: zjebałeś. juz jest zajęta

@borysses: wybacz, taka moja natura :P to nie moja wina, że z lektur szkolnych wolałem Lalkę ;)

@only_spam: tylko już mówiłem - koszt CPU przy obróbce pliku.php który i tak będzie zaczytany żeby wykonać resztę roboty vs odczytanie htaccessów a pozniej pliku php, to odpowiedź jest oczywista. Ze strony admina wystarczy podstawowe obcinanie .php względnie dorzucenie jednego globalnego rewrite index.php?$request_uri daje własciwie wszystko użytkownikom.

@only_spam: Z tym, że w przypadku php mozna zrobic jedną definicje redirecta i będzie jeden odczyt pliku (względnie plus importy) - zasobów CPU jest z reguły kilka rzędów wielkości więcej niż IO dyskowego. PHP powinien też działać w scope tylko danego użytkownika, więc jeśli sobie coś popsuje to już u siebie - can't care a less :P Co więcej - z apachem był jeszcze problem, że każde połączenie powodowało stworzenie osobnego procesu (20~40mb w zależności od ilości bibliotek i dodatków) więc im dłużej trwało połączenie podczas ktorego bylo sprawdzane drzewo folderow, tym gorzej. Nginx szczęśliwie nie ma tego problemu, a procesy php-fpm zajmują wymiernie mniej RAMu (4mb). Do tego php-fpm umie pre-warmować procesy więc działa to znacznie sprawniej.

@only_spam: @Writer: dobra, musiałem zjeść sniadanie :P

Więc tak. Idea .htaccess odbiera administratorom możliwość kontroli nad konfiguracją i zachowaniem poszczególnych location. Po drugie .htaccess wymusza kaskadowe sprawdzanie reguł i ich odpowiednią konkatenację. Oznacza to, że dla adresu example.com/some/long/path/to/very/deep/subdirectory/where/file/possibly/exists/or.not zamiast pojedynczego odczytu z dysku będzie sprawdzenie dla każdego folderu nadrzędnego istnienie pliku .htaccess (czyli co najmniej 12 odczytów z dysku dla samych konfiguracji), złożenie tych konfiguracji w całość, interpretacja jej (nie jest kompilowana przy starcie - jest dynamiczna) i późniejsze odczytanie pliku (bądź wykonanie rewrita do nowej lokacji i... cykl zaczyna się od nowa [no chyba ze jest last]). Powoduje to gigantyczny narzut przy wykonaniu prostego GETa. Ogólnie użytkownicy nie powinni mieć uprawnień do mieszania w ten sposób na serwerach. Wszelkie redirecty powinni juz obsługiwać w kodzie swoich programów. Tak samo listingi folderów czy inne cuda. Administrator nie powinien poświęcać stabilności, wydajności i bezpieczeństwa serwera (vide exploitacje apacza poprzez cudaczne redirecty) nad wygodę użytkowników - szczególnie, że oni mogą to zrobić wszystko we własnym zakresie w swoim kodzie.

@only_spam: konfiguracja bezposrednio w /etc/httpd/ albo /etc/nginx/ :P obsluga .htaccess powinna byc wylaczona na poziomie serwera