Pan Kot

Sprzeda za 20 zł to zrozumie wartość swojego serwisu .

C# jest kompilowane do kodu pośredniego (CIL), który jest potem wykonywany przez JIT. Przy odpowiednio napisanym i zoptymalizowanym kodzie wszystkie proste operacje uzyskują szybkość tych znanych z C/C++, a niektóre wyższego poziomu jak np. operacje na HtmlDocument są nawet szybsze od tych c++. C# jest kilka lat świetlnych przed javą, sam lubię go nazywać javą na steroidach. Jeśli środowisko docelowego wspiera C# (patrz Linux/OS X - Mono, Windows - natywnie) to nie ma nawet co wybierać między javą, a C# bo C# ma zaimplementowanych tyle sztuczek i optymalizacji, że java jest bardzo daleko w tyle zarówno pod względem syntaxu, wydajności oraz zużycia pamięci. Przykładowo takie rzeczy jak operacje asynchroniczne to 1 słowo kluczowe, C# automatycznie tworzy i zarządza sobie thread poolem, podobnie w przypadku HttpClient masz connection poola, reuse socketów i tryliard innych sztuczek, o których nawet nie wiesz pisząc docelowy kod. W javie o ile da się zrealizować większość z tych rzeczy, to na pewno nie w mniejszej ilości linijek niż 200 - a w C# jest to jedna. Tak, też byłem zwolennikiem javy, po czym usiadłem do jednego projektu (który na mnie wymusił C# z powodu biblioteki), i nigdy więcej już do javy nie wróciłem. Tu nawet nie ma argumentów, doszło do takiego paradoksu, że Mono wspiera C# na Linuxie lepiej niż openjdk javę. Nie wiem, nadal sądzę, że co byś nie zrobił PHP się do tego absolutnie nie nadaje i degradacja będzie tylko postępować, nieważne czy odpalisz via CLI czy mod_php, to jest nadal wolna kobyła, która pracuje na 1 wątku, dla każdego połączenia otwiera socket, nie wspomaga się zoptymalizowanym natywnym kodem CPU, i używa interpretera. Tracisz od groma cykli procesora i zwiększasz sobie koszty - nadal obstawiam przy swoim, że można by to na 1 dedyku ustawić, a bottleneckiem powinna być rurka albo I/O, a nie CPU.

Jeśli ktoś hardcoduje poufne dane do logowania w kodzie to jest idiotą i należy mu dać po łbie za to co robi. Dane do logowania powinny być dostarczone w oddzielnym pliku i czytane po odpaleniu programu - ja mam je zapisane w postaci pliku XML. No i w zależności od tego jak poniesie Cię fantazja, plik ten można szyfrować w dowolny sposób, jeśli zajdzie taka potrzeba. Co do dekompilacji - C# jest kompilowany do kodu pośredniego, tak więc mając dobry dekompilator możesz to przywrócić do "mniej więcej" tego samego kodu źródłowego. Oczywiście są wszelkiej maści obfuscatory, które już tak przemielą ten kod, żebyś spędził co najmniej tydzień na doprowadzeniu go do postaci czytelnej dla człowieka - bo nie wyobrażam sobie, żebyś zrozumiał cokolwiek z takiego obfuscated kodu bez jego obróbki. Pytanie tylko po co - sprawa ma się podobnie jak z PHP, masz skrypt/binarkę to masz jej kod. Jak chcesz świadczyć usługę dla klienta to nie dajesz mu binarki tylko świadczysz usługę, a jeśli tworzysz dla klienta projekt w C# to z definicji należy mu się binarka i jej kod źródłowy, więc nie widzę use case'a "potrzeby" takiego obfuscatora.

Jeśli chcesz wysyłać i odbierać maile wyłącznie z jednego własnego serwera to pokolei: 1. A domena.pl -> 1.2.3.4 2. AAAA domena.pl -> ::1 3. MX domena.pl -> domena.pl 4. SPF domena.pl -> v=spf1 mx -all 5. revDNS 1.2.3.4 -> domena.pl 6. revDNS ::1 -> domena.pl Oczywiście powinieneś zamienić adresy IP 1.2.3.4 oraz ::1 na prawidłowe, tak samo domena.pl na prawidłową domenę. Jak chcesz obsługiwać więcej domen ponawiasz punkty 3-4 dla każdej domeny. Jak chcesz dodać dodatkowe serwery, które mają dostęp do wysyłania maili z twojej domeny to zmieniasz wpis SPF np. includując ekstra adresy. Na ogół nie jest to potrzebne jeśli cała twoja domenowa poczta mieści się w obrębie serwera MX (zarówno przychodząca jak i wychodząca ).

Mam i nie mam mu nic do zarzucenia, chyba najlepsza darmowa alternatywa na tą chwilę.

Projekt już zapewne zaszedł za daleko, ale ja bym coś takiego napisał w C#, spiął z bazą i moim serwisem, i odpalał via Mono-sgen na Linuxie, albo natywnie na Windowsie, co kto lubi. PHP nigdy szybki ani wydajny nie był, nie powinno się na nim tworzyć długo-żyjących procesów bo po prostu się do tego nie nadaje, m.in dlatego masz w domyślnych konfiguracjach limit sekundowy wykonywania skryptu. Crawlery powinny być pisane w tym, co może w pełni wykorzystać potencjał OSu oraz połączenia internetowego (patrz C# i HttpClient - który zarządza connection poolem, robi reuse socketów, jest w stanie realizować wiele requestów na jednym porcie i więcej), a nie PHP który od zawsze był tworzony w oparciu o zrealizowanie konkretnej logiki i zwrócenie wyniku. Ale mówię, zapewne za daleko to zaszło, żeby już coś tutaj kombinować, choć nadal sądzę, że będzie tylko gorzej i zareagowanie obecnie zaoszczędzi Ci koszta w przyszłości. Jestem 100% pewny, że ten crawler by działał wyśmienicie ze wszystkimi 28 serwisami na jednym mocnym dedyku, sam mam podobne rozwiązania w swoich projektach, tylko że nie stawiam ich na PHP. W godzinach szczytu moja aplikacja ma otwarte ponad 1000 portów i wszystkie są aktywnie używane.

Nie wiem jak innych, ale mnie by to dość mocno zdenerwowało i kliknąłbym [X] w prawym górnym rogu. Jak chce odpalić okienko ze streamem to klikam przycisk, jak chce je schować również, a nie najeżdżam na ikonę - nie definiuj UX na nowo, tylko poczytaj guideline'y. To tak na marginesie.

Ja bym to rsynciem na steroidach spiął, ale co kto lubi.

Masz tyle osób u siebie w wydającym się dojrzałym community, to nie możecie się zrzucić po złotówce? Ja was mogę przyjąć na swój semi-prywatny serwer, ale na pewno nie będę tworzył nowego specjalnie dla określonej grupy - nikomu się to nie kalkuluje, firmy hostingowe płacą z własnej kieszeni na ATHP, a NPLowcy tacy jak ja nie rozdają serwerów, a co najwyżej wypożyczają kawałek swojej piaskownicy.

Te pakiety UDP są specyficzne, już kilka lat temu napisałem regułkę iptables, która działa mi do dziś - nie dopuszcza żadnego ataku po UDP do aplikacji - w oparciu o wiele rzeczy takich jak rozmiar pakietu, częstotliwość, a nawet sam content (który też jest do przewidzenia, w szczególności jak serwer używa szyfrowania). Nie, nie podzielę się. ServerQuery to zło konieczne, 10011 u mnie jest zablokowane od początku istnienia, otwarte tylko dla określonej puli adresów IP, które trackują mój serwer, i żadne inne. Wszystko się da, tylko trzeba mieć dostęp tam gdzie trzeba, dlatego właśnie lubię OVH i magiczny dostęp jaki dają przez API do regułek swojego firewalla. Mumble jest spoko, ale nie ma wielu bajerów do których przyzwyczaił mnie TS, do tego ma nieco większe wymagania odnośnie jego hostowania. Jakby TS3 stał się open-source to by był najlepszym programem głosowym opartym o architekturę klient/serwer, bo community naprawiłoby te wszystkie fuckupy, które się w nim znajdują. Ale firma jest nastawiona na zysk, a nie na pracę w formie wolontariatu dla dobra swoich użytkowników, jak co poniektórzy sądzą na WHT odnośnie niektórych firm.

Ja nadal uważam, że BFQ jako I/O scheduler powinien wejść do mainline'u, ale Linus chyba nie chce . Tak, z jądrem można naprawdę ciekawe rzeczy zrobić, jak ktoś się zna i wie gdzie grzebać. Grsec to tylko jeden z co najmniej 4 patchy, które sam aplikuje (Grsec, march=native, O3, BFQ).

Odnośnie tego to ostatnio ktoś sobie upatrzył mojego web crawlera jednej strony - bo się zgłaszał z ładnym useragentem "ArchiBoT/1.0.0.0", więc strona postanowiła, że zrobi sobie na niego blacklistę, bo jak to tak żeby jakiś ArchiBoT sobie odwiedzał stronę. ... Teraz crawler dla tej jednej specjalnej strony zgłasza się jako "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36" .

Jeśli lubisz marnować kolejne godziny na pisanie nikomu niepotrzebnych i bezwartościowych poradników, oraz tworzenie nikomu niepotrzebnej i bezwartościowej strony, to nikt Ci w tym nie przeszkodzi - na głupotę nie ma lekarstwa. Może jak gimbazjalna część użytkowników skomentuje twoje poradniki jako "nic niewarte i nieprzydatne śmieci" na które tak się wyprodukowałeś to będzie ten krytyczny moment o którym wspomniałem powyżej . Zatem życzę powodzenia i dużo szczęścia.

Nie, usługi Steam nie zmieniają często swoich adresów IP. Miałem zhardcodowaną jedną listę connection managerów od 3 lat, i po tych 3 latach jak je sprawdziłem to 86% nadal stała i ma się świetnie, tylko sobie zsyncowałem z tym co jest obecnie. Z DDoSami jest tak, że jak ktoś chce - najlepiej i admin, i firma hostingowa, to można zdziałać naprawdę dużo i pomóc zarówno sobie jak i firmie, ale to trzeba się po pierwsze znać, a po drugie rozumieć drugą stronę, i dotyczy to zarówno ciebie jak i firmy. MH nie jest moim zdaniem dobrym wyborem pod względem takiej współpracy anty-DDoSowej, ale to tylko moje zdanie.

Temat jest spalony z powodu zainteresowania. Jeśli naprawdę sądzisz, że jest rzesza użytkowników, która zakłada swoje serwery, szuka "pomocy" albo "rozwiązań" problemów, i nie ma gdzie ich znaleźć, to po prostu jesteś w jednym wielkim błędzie i musisz zaryć łbem o beton, żeby się o tym przekonać - czyli wystartować z projektem i odnieść kolejną już klęskę. Argument "domena xxx nie nadaje się pod SEO" jest tak słabym argumentem, że równie dobrze mógłbyś powiedzieć, że zapomniałeś domeny opłacić, a nawet to by miało więcej sensu. Żeby założyć dobry portal trzeba trafić w niszę, osoby które zrzeszają się w konkretnym celu, na konkretnym forum o konkretnej grze, a nie na wszystkim i niczym jednocześnie. Kopiując jeden do jednego swój poprzedni pomysł, nie wyciągając żadnych wniosków, celując w najgorszą możliwą grupę docelową, i do tego podtrzymując wymierający temat, jedyne co robisz to tracisz czas, chęci i możliwości, bo nie przełoży się to w żaden, nawet najmniejszy sposób na efekty. GameHosting umiera, wielkie firmy wydające gry online wolą mieć wszystko pod kontrolą we własnej architekturze, bo po prostu poprzedni model serwerowy przestał się komukolwiek opłacać. Nie, to się nie zmieni, będzie tylko gorzej, a ty usilnie twierdzisz że masz wybitny pomysł na wybitne forum - świetnie, szkoda tylko że jakiekolwiek cuda byś nie zrobił to jesteś z góry skazany na porażkę z tego jednego jedynego powodu - twój temat się wypalił, nikogo nie obchodzi, nikt tego nie potrzebuje, i nikt z tego korzystał nie będzie. Jeśli to cię nie przekonało i nadal zostajesz przy swoim, to jak już mówiłem - część ludzi musi mocno zaryć łbem w beton, żeby zrozumieć dlaczego jakiś Archi w internetach twierdził, że coś nie wypali. W tym wypadku i tak cokolwiek bym nie napisał, nie przekonałoby cię to do poświęcenia tego cennego czasu na coś bardziej produktywnego, więc w tym miejscu zakończę i zaproponuję poświęcić kolejne 5 minut na przemyślenie tematu.

Dzięki, że piszesz, myślę, że autor przez całe te 3 miesiące dzień w dzień oczekiwał takiej odpowiedzi jak twoja.

Problem z nginxem rozwiązało usunięcie nginxa. ... OK.

CSF też ma built-in integrity test i potrafi powiedzieć które binarki są replacowane.

Pamiętaj, że TS działa po UDP, a nie po TCP, więc jak w regułkach ustawiasz jakieś state'y to UDP się w to nie wlicza po UDP jest bezstanowy.

Jak wyżej, reinstalacja jest obowiązkowa, a zanim to zrobisz warto poszukać poszlak co mogło pójść nie tak, ja bym spakował całe /var/log do tara, przesłał do siebie do późniejszej analizy, a potem reinstall.

Zasada jest odwiecznie ta sama - wynosisz hosting WWW i inne usługi mogące się schować za cloudflare na jeden serwer, a wszystkie teamspeaki, CS-y i inne directy na drugi, w ten sposób minimalizujesz potencjalne straty.

Baza danych obowiązkowo, już przy 100-200 klientach było trzeba się zastanawiać. SQL się tutaj sprawdzi. Jak masz ambicje i chcesz ułatwić paniom życie to naprawdę niewielkim kosztem i np. MySQL connectorem można zrealizować prostą aplikację w C# - desktopową, dzięki której wprowadzanie/zmiana/usuwanie danych będzie bardzo proste, i bez-przeglądarkowe. Co więcej, będziesz miał nad tym programem pełną kontrolę, a jak najdzie potrzeba rozbudowy tego rozwiązania o coś jeszcze np. funkcję automatyczne wysłania maila czy cokolwiek, to masz z górki. I przy okazji rozwiązujesz kilka innych problemów jak np. autoryzacja bo aplikacja może być dołączana z configiem czy czymkolwiek. Imho duże możliwości, C# się świetnie do tego nadaje, ale zrobisz jak uważasz.

Jestem niestety najmniej przydatnym forumowiczem pod tym względem bo mam mojego kebaba w GRA1, które bardzo dobrze się trzyma .

A żeby dodać coś konstruktywnego to polecam zainteresować się tym jak działa routing, bo zapewne masz dwa interfejsy np. eth0 i eth1, i wystarczy wskazać aplikacji, żeby użyła drugiego.

I po raz kolejny śpię spokojnie.