Pan Kot

Fajna domena.

Stream jest uwarunkowany w dużej mierze od sposobu streamowania a nie samego faktu. Jak kupujesz kartę Nvidii (nową, a nie trupa), to masz NVENC. NVENC nie obciąża praktycznie w ogóle ani CPU, ani GPU, można powiedzieć, że stream jest prawie, że "za darmo" jeśli chodzi o sprzęt, i zapewnia całkiem dobrą jakość jak za coś co nie pożera prawie żadnych zasobów. Pójdzie Ci to w każdej grze i na każdym nowszym setupie, a NVENC masz już szeroko wspierane chociażby w ulubionym przeze mnie OBSie. Jeśli natomiast szukasz czegoś lepszego to schodzimy do klasycznego streamowania x264, i tutaj pierwsze skrzypce gra CPU, GPU ma prawie, że zerowy udział w całym procesie. Osobiście sądzę, że osiągniesz na aktualnym setupie całkiem dobre wyniki nawet na x264, oczywiście w zależności od gry i tego jak bardzo upodobała sobie CPU. Generalnie polecam zestawy z PurePC, naprawdę nie można się na nich przejechać i każdy jest świetnie dobrany. Osobiście sądzę, że ze streamowaniem nie będzie większych problemów, ale jednocześnie widziałbym tutaj oczko wyżej - GTX 970, i może jakiś i5 z nowszej serii.

Podjęliście się również szerzenia opinii, że jesteście lepsi od wszystkich innych usługodawców, macie najlepsze zabezpieczenia i stabilną infrastrukturę, a ataki ddos na teamspeak'a wciągacie nosem. Firmę hostingową się ocenia po awariach, a nie po tym jak działa w przerwach między nimi. Jakby E24 podczas awarii swojej macierzy dyskowej, która trwała bodaj miesiąc czy dwa zrzucali winę na HP albo innego IBMa to chyba bym ze śmiechu nie wytrzymał . To świetnie, że STARACIE SIĘ pracować nad problemem i go rozwiązać, ale osobiście sugeruję zejść na ziemię i okazać nieco pokory, bo jeśli byłbym waszym klientem, i po takich kabaretach wciąż czytał o 99,99% uptime, super zabezpieczeniach i "co złego to nie my, to oni!", to bym się czym prędzej zabrał gdzieś, gdzie ci "inżynierowie" są świadomi swojej sytuacji i nie stosują takich śmiesznych zagrywek jak te, które @Spoofy wymienił już wcześniej. Osobiście życzę wszystkiego dobrego, ale niesmak na ustach jeszcze mi przez jakiś czas pozostanie .

Nie lubię takiego stwierdzenia. Preferuję: "Wytworzenie duplikatu danego klucza jest złożonym algorytmicznie zadaniem, które opiera się na trudności faktoryzacji dużych liczb złożonych przez dzisiejsze komputery". W pewnym momencie dojdziemy do takiego momentu, gdy to zadanie będzie do pewnego poziomu osiągalne, jednym z takich zagrożeń są komputery kwantowe. A kiedy rzeczywiście się to zdarzy, to będzie można uznać RSA za algorytm niebezpieczny. Przypominam, że podobna rzecz już się stała spory czas temu z algorytmem DES, który cierpiał na podobny problem złożoności obliczeniowej. Plusem jest to, że wytworzenie duplikatu klucza RSA nadal jest zadaniem bardzo trudnym, wymagającym ogromnej mocy obliczeniowej, więc całe "bezpieczeństwo" polega na tym, że nikt nie będzie inwestował takiej sumki pieniędzy na złamanie danego klucza. Jeśli technologia pójdzie do przodu i osiągnięcie takiej mocy będzie w zasięgu crackerów, to RSA będą łamane cały czas, ale na tym etapie pewno już będziemy mieli co najmniej kilka alternatyw, bo przepaść technologiczna nadal jest ogromna.

Pan wyżej trafił w sedno. Sam staram się unikać takiego podejścia, ale doświadczenie uczy, że niektórzy muszą zostać zrobieni w konia nawet kilka razy, żeby wyciągnąć jakieś wnioski. Nie lubię obwiniać oszukanego, bo to nie jego wina, ale to tak samo jak zostawiać otwarte drzwi do domu i być zdziwionym, że ktoś go sobie wyczyścił. Jest naprawdę dużo zaufanych osób sprzedających te śmieszne "wPLN", i nie trzeba się uciekać do jedno-postowców, a już na pewno nie płacić z góry. A jak już trzeba, to chociaż głupie allegro co byś nie musiał nerwów zjadać o jakieś 80 zł.

Od kiedy Mono zaczęło wspierać na naprawdę dobrym poziomie C# i całe .NET to nie widzę dalszych przeciwwskazań do twierdzenia, że jest "be". Sam mam już 4 konsolowe aplikacje w C# i 1 stronę na ASP.NET i działa to naprawdę porządnie, wszystko na Linuxie i bez żadnej potrzebnej wirtualizacji.

Wszystko zależy od tego jakie to dane i na ile duże są. Ja mam osobiście coś takiego: 1 serwer główny i 1 serwer backupowy. Serwer backupowy co określony czas (w moim przypadku jest to 4-5 w nocy codziennie) łączy się z main server za pomocą klucza SSH. Następnie robi rsync wszystkich plików, które chce zbackupować (rsync tutaj świetnie działa bo wykrywa zmiany w plikach i tylko je synchronizuje, a nie przesyła wszystko jak leci), a następnie robisz dumpa określonych baz MySQL, oczywiście w skompresowanej gzipem formie, i również zasysa do siebie. Jest to świetne rozwiązanie do dużej ilości potencjalnie niewielkich plików (oraz binarek które się rzadko zmieniają), a także dobre podejście do małych-średnich baz danych. W przypadku dużej ilości danych binarnych sugerowałbym nie używać rsynca, a spiąć to jakimś network filesystemem, np. glusterfs. W przypadku dużych baz SQL natomiast, dobrym pomysłem jest zwyczajna replikacja. Sam osobiście tego nie używam głównie z tego powodu, że te skompresowane bazy łącznie nie ważą więcej jak 100 MB, a rsync sprawdza się świetnie niepotrzebnie nie obciążając filesystemu, co by miało miejsce w przypadku glustera.

Poważna sprawa, nie ma nic gorszego niż strona 2be.pl zwracająca timed out. Szkoda, że akurat na nich wypadło .

Zawsze można rozwiązanie zduplikować i stworzyć 2 takie serwery, to chyba oczywiste. Cały sens polega na tym, żeby admin był kontrolowany i za pomocą swojego klucza miał dostęp tylko do tych 2 serwerów proxy i za pomocą nich dalej. Dzięki temu mamy łatwy sposób logowania co się dzieje w infrastrukturze, i łatwy sposób zrevokowania klucza danego admina, zamiast zmieniania konfiguracji wszystkich serwerów.

Meliski zaparzyłem na dwa tygodnie, a tu już dzisiaj wszystko działa. 8 dni, nie jest tak źle .

reCaptcha działa w miarę dobrze i jest dość wygodna, aczkolwiek żadne rozwiązanie nie gwarantuje "bezpieczeństwa" i możesz być prawie pewien, że na każde z nich są już napisane obejścia, tyle że żadne nie jest publiczne.

Iii... tydzień!

Myślałem, że dla każdego jest oczywiste, że do tego NDA należy dołożyć jeszcze odpowiednie zapiski w umowie o pracę o nie robienie fuckupów własnoręcznie. Ala "Pracownik zobowiązuje się do nie działania umyślnie na szkodę pracodawcy, w szczególności dostępu do infrastruktury pracodawcy do której nie jest uprawniony". IMHO dobrym pomysłem jest postawić jeden serwer ala-proxy w firmie, który ma dostęp do wszystkich zasobów prywatnych, dać pracownikowi dostęp do VPN, po zwolnieniu ten dostęp zrevokować. W ten sposób można kontrolować kto co i jak, i przy okazji zebrać dowody jeśli pracownik dopuści się fuckupu.

Wiecie co wam powiem, filmu na YT dla supportu OVH jeszcze nie wrzucałem, zawsze musi być ten pierwszy raz, nie? Za 10 godzin będę świętował tydzień semi-downtime'u. Już sobie zakupiłem backupowego VPSa i właśnie przerzucam zabawki bo pewnie im to jeszcze miesiąc zajmie. Serwerowy kabaret. Najlepsze jest jak im tłumaczę, że dropy są na wyjściu z ich sieci, a gość mi wrzuca tracerta zrobionego z tego samego DC i mówi "u nas wszystko działa". O żesz KU*WA JA PIER*OLE .

NDA. Klauzula poufności z sumkami opiewającymi na kilka milionów zł, tak żeby taki administrator się dwa razy zastanowił zanim zrobi fuckup.

Problem jest taki, że musisz jednak access to tego serwera backupowego jakoś autoryzować, więc jedynym sensownym pomysłem jest zrobienie takiego myku, żeby umożliwić jedynie zapis nowych plików, ale już nie usuwanie starych, co jest jednak nieco skomplikowanym zabiegiem, bo podstawowy access to rwx. A skoro włamywacz dostał się do main servera, który te backupy śle dalej, to pewno nie było problemu zalogować się i tam i te backupy skasować.

Co to znaczy standardowe?

Zastosowanie nie wynika z powodu pana od marketingu, który mówi "ten jest dla klienta, a ten dla administratora", tylko z powodu jak ten procesor działa. Procesor to procesor, i jeden jak i drugi będzie spełniał tą samą funkcję, aczkolwiek w przypadku serwerów stawia się na mniejszą responsywność, a większą wydajność, a w przypadku PCtów responsywność jest właśnie priorytetem bo nikt nie chce mieć sytuacji zawieszającego się systemu przy 3 aplikacjach. Nie polecam Xeonów na PCty.

I na podstawie locale przeglądarki to POWINNO być robione, IP nie jest żadnym wyznacznikiem lokalizacji.

Od 5 dni jedna z moich piaskownic w OVH jest semi-down bo VAC się niepoprawnie zdezaktywował. Od 4 dni support wmawia mi, że to moja wina, pomimo że pokazuje im MTRy i wysłane requesty z 0% packet lossem do 127.0.0.1 i sieci OVH, i 96% do reszty. Podtrzymuję opinię, że jak w OVH wszystko działa to jest cud, miód i malina, ale jak coś walnie to lepiej kupować drugi serwer bo ten stary już jest do kasacji. Kurw*cy można dostać czasem. Idę sobie meliski zaparzyć bo coś czuję, że jeszcze 2 tygodnie downtime'u mnie czekają.

Dla studentów PKO ma ciekawą ofertę - konto dla młodych. Sam mam, i za prowadzenie jest 5 zł (1 zł mniej za każdą transakcję kartą, aż do 0 zł przy 5+ transakcjach miesięcznie), 0 zł za kartę i wszystkie bankomaty + więcej. Dla wszystkich studentów, czyli osób w przedziale wiekowym 18-25 (pewnie od 15+), to jest jedna z lepszych ofert moim zdaniem, ale tylko jeśli spełniasz wymóg do założenia takiego konta.

Locki na całą tabelę masz tylko wtedy, gdy serwer SQL nie może sobie poradzić inaczej, przykładowo: UPDATE tabela SET kolumna1=1 WHERE kolumna2=2 Jeśli na kolumnie2 założony jest indeks to tylko te wiersze, gdzie warunek jest spełniony będą zablokowane, w przeciwnym wypadku - cała tabela. Dlatego zamiast dzielić wspólne dane na wiele tabel, wystarczy pozakładać odpowiednie indeksy po warunkach where. Tak jak mówiłem, zadaniem administratora jest odpowiednie indeksowanie, a nie łamanie postaci normalnych poprzez rozrzucanie tych samych danych na kilka tabel. I do tego też nawiązuję pisząc wyżej - jak się człowiek zna, to nie będzie miał większych problemów, a wydajność zarówno SQL jak i NoSQL będzie zbliżona. Jakbyś nie znał mechanizmu lockowania w MySQL to w przypadku zmiany możesz odczuć większą wydajność bo np. NoSQL może out of the box realizować blokady zupełnie inaczej, co nie zmienia faktu że w MySQL też można to efektywnie zrobić. Nie upieram się, że wydajność rozwiązania A jest lepsza niż rozwiązania B czy vice versa, jedynie twierdzę że zmiana SQL na NoSQL w imię zasady "bo tam jest szybciej" nie ma żadnego pokrycia z rzeczywistością, a obydwa rozwiązania zastosowane optymalnie dadzą podobne rezultaty.

Nigdy nie powinno być czegoś takiego, w skrajnym przypadku ultra dużych danych możesz przeznaczyć oddzielną tabelę do tymczasowego zapisywania kluczy głównych wierszy, którymi jesteś zainteresowany, i potem z nich robić where. Dzieląc dane na kilka tabel łamiesz co najmniej kilka postaci normalnych i prowadzisz do degradacji wydajności. MySQL wie lepiej jak sobie radzić z dużą ilością danych, zadaniem administratora jest odpowiedni dobór indeksów pod najczęściej wykonywane zapytania, oraz niwelowanie złych zapytań takich jak joiny na innych polach niż te indeksowane. Generalnie moje zdanie raczej nie będzie jakoś specjalnie użyteczne, ale zauważyłem, że nie ma dużej różnicy w wydajności między bazami SQL, a NoSQL, oczywiście wtedy kiedy testujemy obydwa rozwiązania należycie. Te dwa typy się nieco różnią i w zależności od swojej wiedzy, umiejętności, jak i doboru oprogramowania możesz mieć zarówno wzrost jak i degradację wydajności. Przykładowo pod słowem "MySQL" kryje się najczęściej wersja Oraclowa, która dużo pozostawia do życzenia. Postgres, Percona czy MariaDB radzą sobie o wiele lepiej. Podobnie jest z NoSQL, chociaż tutaj akurat nie jestem w stanie powiedzieć co teraz jest najszybsze. Warto się zastanowić czy rzeczywiście jest sens inwestować w NoSQL swój czas, zamiast przejrzeć co można by poprawić z aktualnym setupem. Przykładowo, sam miałem SQLkę, która wykonywała się dobre 8-9 sekund, bo bazowała na znalezieniu konkretnych userów spełniających warunki X. Zmieniłem SQLkę odwracając ją, czyli ze wszystkich userów odejmuję tych nie spełniających warunków X, i wydajność wzrosła dziesięciokrotnie, a SQLka zwraca te same wyniki. NoSQL jest fajny, miło się na niego programuje, ale póki co zostaję przy swoich doświadczeniach i stwierdzam, że odpowiednio zoptymalizowany SQL, zarówno po stronie aplikacji, bazy, jak i serwera - będzie szybszy, a w najgorszym przypadku porównywalny do rozwiązań NoSQL. Sam wielokrotnie próbowałem się przekonać, robiąc benchmarki, próbując sobie wmówić, że programowanie pod NoSQL jest łatwiejsze, szybsze i bardziej przenośne... I suma sumarum nie udało mi się do niego przekonać. Nie mam żadnych dobrych argumentów dlaczego NIE używać NoSQL, ale argumentów ZA również mi brakuje, toteż stwierdzam że skoro już masz aplikację działającą na SQL, to warto się zastanowić nad poprawą tego co działa wolniej, aniżeli rezygnacji z tego na rzecz czegoś co niekoniecznie może działać szybciej. Nie ma nic gorszego niż strata czasu na coś, z czego nie ma żadnego pożytku. Oczywiście to tylko moje 3 grosze, jestem pewny że znajdą się osoby, które będą usilnie twierdziły, że NoSQL przebija pod każdym względem SQL, tak samo jak i Ci co stwierdzą, że SQL > NoSQL pod każdym względem - ja staram się być obiektywny i sam robić testy, a niestety z nich żadnych dobrych argumentów nie wyciągnąłem.

Najpierw zastanów się czy Ci to w ogóle potrzebne. Jeśli nie to można zignorować, a jeśli tak to może się znajdować np. w pakiecie firmware-linux, który includuje wiele proprietary driverów. Najczęściej jeśli coś nie jest open-source i w drzewie linuxa, to jest w firmwarze proprietary.

Nie, tak zrobisz od razu, uprzednio robiąc backupy podmontowywując swoje partycje.