Pan Kot

A mi się wydaje, że więcej na prąd wydasz przez miesiąc niż ten sprzęt jest warty.

Aktualizacja Windowsa z jednej wersji do innej nigdy dobrze nie działała i nie zapowiada się, żeby w najbliższym czasie cokolwiek się zmieniło. W najlepszym wypadku "będzie" działać, w najgorszym nie odpali w ogóle, a w przeciętnym będą m.in takie problemy jakie miałeś ty. Od zawsze - instalacja windowsa tylko na czysty system, bez wyjątków.

Pewno jest, z drugiej strony jak szukasz tłumacza przysięgłego to i cena będzie znacząco wyższa.

Forum nie do używania, nie wiem czemu już któryś raz z kolei ktoś to psuje.

Masz odczyt i zapis na poziomie 0 TB, jak na moje to wygląda albo na złe odczyty SMARTa, albo na jego uszkodzenie - dysk może być zarówno w fatalnym jak i perfekcyjnym stanie.

http://www.webhostingtalk.pl/index.php?app=core&module=search&do=viewNewContent&search_app=forums - popsute.

W pełni się zgadzam, firmy domeny.zbyszekinvestments.krzak.pl również nie widzę, czyżby spisek Zen?

Nie tylko, metoda porównywania napisów odgrywa największą rolę przy wszelkich warunkach where i podobnych. MySQL jest w stanie dużo szybciej porównywać stringi przez ich binarną reprezentację (_bin) niż przez porównywanie kulturowe czy case-insensitive. Ma to też dużą rolę przy kolizjach - przykładowo ja mam w bazie coś takiego jak ID, gdzie ID to 5 znaków 0-9 A-Z. ID "00AAF" to nie to samo co ID "00aAF", i jeśli użyłbym tutaj utf8mb4_unicode_ci to bym miał błąd w warstwie logiki bazy danych, i od cholery problemów po stronie kodu. M.in dlatego właśnie stwierdziłem, że porównywania _ci to samo zło i dopóki ktoś nie potrzebuje tego case-insensitivity (a w większości przypadków się tego nie stosuje), to powinien się upewnić, że używa wszędzie typów _bin. I już nawet pomijam to, że porównywanie _bin jest o wiele szybsze. Jest też o wiele bezpieczniejsze kiedy operujemy na takich systemach jak Linux, gdzie filesystemy i generalnie cała otoczka jest case-sensitive. Już swoje godziny straciłem na debugowanie takiego problemu. Jedyny przypadek gdy chcemy skorzystać z _ci lub _cs to właśnie taki gdy albo potrzebujemy tego case-insensitivity, np. upewniając się, że zapytanie WHERE nazwisko = "regDoS" zwróci ten sam wynik co "Regdos", lub w przypadku gdy niektóre znaki mają specjalne znaczenie w różnych kulturach (np. i w Tureckim). Generalnie więc, _bin all the way.

Jeśli nie potrzebujesz robienia MySQL case insensitive to najszybszym i jednocześnie najlepszym będzie utf8mb4_bin. Zawiera on wszystkie znaki jakie gdziekolwiek są używane, a jednocześnie porównuje stringi binarnie nie martwiąc się o aspekty kulturowe czy właśnie case. Z kolei jeśli potrzebujesz to utf8mb4_unicode_ci - podobnie jak wyżej z dodatkowym overheadem w postaci kultury i case insensitive. Cała reszta jest bardzo specyficzna i powinna być używana wyłącznie jeśli masz taką potrzebę. Przykładowo do zapisywania hashy w postaci cyfr i znaków A-F (np. FF0000) warto użyć latin1_bin - doprecyzowanie kodowania potrafi ładnie poprawić wydajność, w szczególności używanie typów binarnych zamiast _ci czy _cs.

Precyzujesz odpalanie pliku przez /bin/bash, a odpalasz go przez sh, toteż taki argument nie ma sensu. Odpal swój skrypt przez /bin/bash skrypt.sh i sprawdź czy działa, bo to definiujesz w swoim pliku. /bin/sh bardzo często jest podlinkowane pod jakiś lżejszy niż bash interpreter, często dash. Ma to sens z punktu wydajności.

To zapewne popsułeś line endingi lub zapomniałeś sprecyzować interpretera (aka shebanga) na początku pliku.

Różnica jest w tym, że jeden plik ma chmod 755 a drugi 644.

Jeśli ktoś skupi się na tym, to będzie miał spore wyzwanie udowodnić, że rzeczywiście tak było, bo to nie w gestii użytkownika ani sądu jest to jak prezes prowadzi swoją firmę. Poza tym to musiałby być długotrwały proces, a nie szybki fuckup - nie zapominaj, że to wszystko stało się w zasadzie z dnia na dzień, całość historii (do momentu rm -rf) można by było zamknąć w kilku miesiącach max. Efektu takiej rozprawy nie przewidzę, bo jasnowidzem jeszcze nie jestem, ale imho udowodnienie BJ czegokolwiek będzie naprawdę trudne zważywszy na to ile lat firma była na rynku czy nawet samego faktu, że NASK 2be zaufało jeszcze przed całą awarią. To nie jest firma krzak pana X, któremu możesz udowodnić, że to jeden wielki scam i zostałeś oszukany. BJ nie jest bezpośrednio winny tej sytuacji, a udowodnienie mu winy pośredniej będzie bardzo trudne. Wątpię, żeby komukolwiek się to opłacało w kwestii pieniędzy - imho prawnik będzie więcej wart niż to co sąd Ci przyzna nawet jeśli udowodnisz BJ winę, ale to już każdy poszkodowany powinien sobie sam przekalkulować - ja tu tylko siedzę i obserwuję przebieg zdarzeń.

Nie zapominajcie jeszcze w tym wszystkim o polskich realiach i tym, że to nie USA i nikt tutaj nie wiadomo jakich odszkodowań nie dostanie. Poza tym, jeśli ktokolwiek pozwie 2BE to zgodnie z kodeksem musi udowodnić firmie, że nie wywiązała się z umowy świadczenia usług i zrobiła to umyślnie. Wystarczy, że BJ udowodni, że doszło do włamania, przedstawi zawiadomienie do prokuratury i sądzę, że w najlepszym przypadku klient dostanie zwrot pieniędzy za niewykorzystany okres, i nic więcej. Nie chce mi się teraz sprawdzać kodeksu cywilnego i tego na jakich warunkach 2BE świadczyło swoje usługi, ale naprawdę mocno wątpię, żeby sąd przyznał komukolwiek odszkodowanie ponad to co mu się "należy" z tytułu świadczenia usługi - raz, że to strona pozywająca musi udowodnić drugiej winę, a dwa że z tego co pamiętam mamy kilka zapisów prawnych, które chronią w takim wypadku 2BE i BJ z tego tytułu, że nie działał umyślnie. Nie jestem prawnikiem, a jedynie nieco bardziej oczytanym użytkownikiem z wiedzą praktyczną. Prawo to jedno, ale wyrok w każdym wypadku podejmuje sąd i to właśnie sąd trzeba przekonać do swoich racji, a to nie będzie proste i każdy dobrze powinien sobie z tego zdawać sprawę.

A może BJ przeczytał mojego posta wyżej .

Dlaczego domena.pl jest w posiadaniu usera www-data a nie twojego? Popraw poprzez chown -hR user:user /var/www/vhosts/domena.pl. Konfiguracja wygląda OK, sprawdź logi nginxa w /var/log/nginx (konkretnie error.log) i sprawdź dlaczego wyrzuca 502.

I prawidłowo zakładasz, bo za takie propozycje jak te użytkownika @Viperoo wyżej administracja powinna na tym forum banować. php-fpm działa na zasadzie pooli odpalanych z konkretnego użytkownika, możesz je sprawdzić w /etc/php5/fpm/pool.d. Zakładam, że twoja strona jest w posiadaniu jakiegoś usera o nazwie user1, a pool jest standardowo w posiadaniu użytkownika www-data. User ten nie ma prawa zapisywać w twojej stronie, stąd problem. Rozwiązanie: Skopiuj www.conf lub inny standardowy pool, z którego teraz korzystasz do nowego pliku, np. user1.conf. Popraw usera i grupe w tym pliku, a finalnie ścieżkę do socketa (lub port TCP, w zależności z czego korzystasz) czyli pole listen (tak żeby było inne niż obecne). Zrestartuj php5-fpm np. poprzez service php5-fpm restart i sprawdź czy wszystko działa - w htopie powinieneś być w stanie zobaczyć nowy działający pool. Teraz wystarczy, że poprawisz ścieżkę do socketa (lub port TCP) w nginxie, i zrestartujesz nginxa. Jak nic nie popsułeś to będzie działać.

Zabezpieczenie robisz na poziomie webservera, więc powinieneś również na poziomie webservera (htaccess) robić odpowiednią logikę dla swoich aplikacji, a nie w kodzie PHP na sztywno hardcodować usera i hasło. Tym bardziej, że htaccess bardzo ładnie wspiera allowy zarówno z tej samej maszyny, sieci lokalnej jak i konkretnego IP, więc wystarczy po prostu tego mechanizmu użyć, a nie modyfikować działający kod, który powinien mieć w czterech literach to na jakiej logice działa webserver.

XAMPP to środowisko, a nie framework. Dopóki nie testujesz wydajności ani kompatybilności swoich rozwiązań z tym co ma być na produkcji to nie ma żadnego znaczenia co tam masz, bo PHP wszędzie powinno działać identycznie (a jak nie działa to kwestia konfiguracji, a nie języka). To ma być środowisko w którym tobie się łatwo pisze i testuje kod, a czym bardziej przypomina środowisko docelowe (produkcyjne), tym większa szansa że kod będzie działał identycznie bez większych zmian. I naprawdę nie ma to zbytnio znaczenia co tam sobie postawisz, już zgodność php.ini produkcji z twoim ma większy wpływ niż to, że tam jest apache czy inny nginx. Frameworki istnieją po to, żeby pisało się mniej kodu, tak samo jak PHP istnieje po to, żebyś nie musiał sam alokować pamięci i bawić się ze wskaźnikami. Znajomość frameworka to spora oszczędność czasu i pisanie dużo lepszych jakościowo aplikacji - Symphony to tylko jeden z przykładów, mi osobiście bardzo do gustu podszedł Laravel ostatnio. I nie, nie jestem programistą PHP . Czy ci to potrzebne? Do pisania 100-linijkowych skryptów PHP zapewne nie, ale jakbyś chciał już napisać coś bardziej złożonego, nawet średnio-rozbudowaną stronę w oparciu o PHP i SQL, to jak najbardziej przyda się, bo klepanie dzisiaj w czystym PHP całej strony jest co najmniej dziwne - można, ale po co.

Klucz publiczny odbiorcy też musisz w jakiś sposób pozyskać, opiera się to na tym samym.

Przed atakiem man in the middle, w którym ktoś mógłby Ci podesłać własne spreparowane pliki. Dokładnie tak samo działa infrastruktura klucza publicznego, gdzie ty mając swój klucz prywatny jesteś w stanie podpisać nim wiadomość, a druga strona ją zweryfikować twoim kluczem publicznym. A serwis z którego się pobiera nawet nie jest zabezpieczony SSLem więc przygotowanie takiego ataku jest bajecznie proste. Zresztą SSL też nie stanowi problemu, ale wymaga nieco więcej wkładu własnego.

Ale to było w TVN Meteo, z racji warunków pogodowych informacje przesyłane światłowodami doznają znacznych opóźnień i robią się korki.

Tak, minister zdrowia ostrzega przed wolnym internetem w całej Polsce, nawet w TVN było niedawno o tym.

A na Mazowszu też zadziała?

Dorosły człowiek ma MÓZG i jest w stanie sam stwierdzić co mu się bardziej opłaca, oraz to co mu się opłacać nie ma prawa. Znam wiele osób z PSC, które żyją i mają się dobrze, za to nie znam żadnego idioty, który za wszystko płaci SMSami. Twoja alegoria nie ma żadnego sensu.