Archi

Polecam wysłać maila i się zatem spytać dlaczego twoje meteo się zdecydowało na taki krok. Albo nie wysyłać i zdać sobie sprawę z tego, że nawet jak odwiedzam zdjęcia kotów to powinny one być szyfrowane niezależnie od contentu i tego co tam się znajduje. mrViperoo wyżej wrzucił odpowiedni link.

Chociażby po to, żeby twój ISP i osoby w LANie obok nie wiedziały jakie serwisy w ogóle odwiedzasz. Powodów ekstra jest jeszcze co najmniej kilka - jak już powiedziałem wyżej, jeśli ktoś nie rozumie dlaczego szyfrowanie https jest dobre niezależnie od serwisu to powinien zrezygnować z administracji bo nie ma zielonego pojęcia o faktycznym wykorzystaniu szyfrowania dla bezpieczeństwa samych użytkowników.

Realnie to jeśli ktoś serwuje stronę http zamiast https bo jest "szybciej" to powinien się mocno walnąć w głowę i iść doić krowy, bo do żadnej administracji się nie nadaje.

Jak we Francji to prawdopodobnie SBG, ale raczej celowałbym w WAW.

Najważniejsza podstawa bez której ani rusz to dobry SPF i pole from: w mailu. SPF powinien mieć dość restrykcyjne zasady (np. mx -all), najlepiej z hard failem a nie soft. Pole from musi nie tylko się zgadzać z domeną, ale i również być tym samym co odpowiedź do. Dodatkowo revdns skonfigurowany na tą samą domenę lub sudomenę pomaga, choć nie jest wymagany. Reszta to już dodatki takie jak dkim i dmarc, ale nie jest to absolutnie obowiązkowe, a jedynie poprawia zaufanie. Ogromną rolę w mailu nie gra serwer, tylko sam mail i jego treść - takie rzeczy jak brak wersji html, załączników, linków. Oczywiście nie sposób pozbyć się wszystkiego, ale czym bardziej generyczny mail tym lepiej. W przypadku newsletterów opcja unsubscribe jest cholernie istotna bez której nie przejdzie prawie żaden. Polecam wyżej już wspomniany https://www.mail-tester.com - i nie z testem jakiegoś maila śmiecia, tylko dokładnie tego samego którego wysyłasz do innych osób (treść, nagłówki, nadawca). Jeśli poprawisz się w sposób dostateczny do jego wymagań to masz dużą szansę na to, że za jakiś czas gmail zacznie Ci ufać. Mój serwer ma wynik 9/10 (-1 za brak DKIM), każdy może taki uzyskać niewielkim kosztem. Jeśli masz coś w granicy takiego to nic więcej nie zrobisz, poza czekaniem. Nawet wynik 10/10 nie gwarantuje, że wszystkie maile od razu trafią do skrzynek, google zaczyna ufać z czasem.

W żadnej szanującej się firmie gdzie płacą takiemu pracownikowi więcej jak 49 zł za godzinę nie będą odnawiać certyfikatów LE z palca

https://blogs.vmware.com/vsphere/2015/07/custom-certificate-on-the-outside-vmware-ca-vmca-on-the-inside-replacing-vcenter-6-0s-ssl-certificate.html Nie widzę tutaj niczego, czego by nie załatwił prosty skrypt w bashu.

Kto miał odejść z nazwy zrobił to już dawno temu, realnie klientów im pewno ubyło, ale wątpię żeby to były znaczące liczby.

Nawet kalkulując 6 odnowień na rok, godzina pracy tego pracownika w większości przypadków wyniesie mniej niż 49 zł. Z drugiej strony jeśli hosting nie oferuje certyfikatów LE z automatu to może warto się przenieść do takiego, który to robi, bo ja znam co najmniej kilkanaście takich, wiele z nich na tym forum .

Jeśli nie masz konkretnego, logicznego powodu, którego ja na tą chwilę nie znam, to kupowanie certyfikatu DV w dobie LE jest po prostu głupie, żeby nie powiedzieć gorzej. Taki certyfikat poza tym, że kosztuje, nie oferuje absolutnie NIC czego nie oferuje LE, co więcej, oferuje ZNACZNIE MNIEJ niż certyfikat LE, bo certyfikat LE chociażby możesz odnowić z automatu, a certyfikaty DV już niekoniecznie (zależy od firmy, wdrożenia itp.) Dzisiejszy logiczny wybór to wybór pomiędzy LE a dużo droższym EV. LE ma zastosowanie co najmniej w 90% przypadków, a EV w pozostałych 10%, lecz ten segment na ogół składa się tylko z banków, zaufanych instytucji i innych serwisów operujących danymi poufnymi (ale może to być również większy sklep czy usługodawca, tam gdzie ktoś przetwarza dane personalne). Nic pomiędzy LE, a EV nie ma sensu - płatne DV są dużo gorsze od darmowego LE (nie tylko pod kwestią ceny) i nigdzie bym dzisiaj nie brał typowego SSLa sprzed czasów LE. EV, jak kogoś stać i uważa, że ma to sens dla jego strony, jest nadal dobrym wyborem i podwyższa poziom bezpieczeństwa, ale trzeba go również wybierać z głową, bo na bloga o motoryzacji serio nie jest do niczego potrzebny. Dobrym wyznacznikiem tego czy warto brać EV jest stopień zainteresowania RODO, bo jeśli przetwarzasz dane personalne to jest chociaż jeden dobry powód na EV. Oczywiście tutaj już zdania są podzielone, bo różne osoby różnie będą na to patrzeć - ja mam zasadę wpisywania swoich danych personalnych takich jak imię, nazwisko czy numer konta na EV, ale wszędzie indziej gdzie używam e-maila i pseudonimu serio nie jest mi to do niczego potrzebne. Oczywiście w kwestii DV nie będę się na siłę sprzeczał z kimś kto stwierdzi, że nie ma zaufania do LE i woli sobie wziąć np. Comodo. To są jego pieniądze i jego wybór, ale z merytorycznego punktu widzenia jest to po prostu idiotyczne. EV ma sens, DV poza LE żaden. P.S. Umyślnie nie wspomniałem o "gwarancji" certyfikatów DV innych niż LE bo nawet nie warto tracić czasu na tłumaczenie. Odsyłam do wpisu SH (ale też polecam brac poprawkę np. na to, że certyfikaty LE już są dostępne z wildcardami).

To zdefiniuj czy zwykły SSL czy EV, bo do zwykłego SSLa wystarcza w zupełności Let's Encrypt, a do EV masz dość dużo możliwości i w zasadzie nie możesz źle wybrać.

O 2be.pl też głośno nie było dopóki nie padły pierwsze strzały. Zakładanie, że z firmą nic się nie stanie i będzie się z nią do końca życia jest co najmniej idiotyczne, żeby nie powiedzieć gorzej. Jeśli masz sklep, którego nawet nie możesz sam przenieść do innej firmy czy przynajmniej na 1 własne rozwiązanie, to nie masz sklepu, tylko wynajem usługi z nalepką "zgadzam się na wszystkie aktualne i przyszłe warunki". Nie mówię tutaj, że musisz obowiązkowo mieć dostęp do fizycznych danych 1:1 i w każdej chwili przenieść całość, ale opcja eksportu w stopniu "zadowalającym" (patrz: pozwalającym na odtworzenie co najmniej listy produktów na dowolnym innym, alternatywnym rozwiązaniu, czy to w innej firmie czy na własnym softwarze) powinna być obowiązkowa dla każdego kto nie jest skończonym idiotą. I tutaj nawet nie chodzi o to, że nazwa zwariuje i zacznie żądać takich kwot jakich żąda, ale chociażby o to że mogą sobie w miesiąc wypowiedzieć umowę bez konkretnych przyczyn (a raczej takich o których się nie dowiesz). Nie wyobrażam sobie w takiej sytuacji stwierdzić "to co panowie, hehe, nowy sklepik robimy, kto na ochotnika 1000 produktów do bazy wrzuci?" Tutaj nawet nie ma dyskusji, tu publiczny lincz powinien być. I bynajmniej nie nazwy, tylko tych baranów co się na takie warunki godzą.

Nie do końca, w zależności od implementacji ale na ogół w tabeli userów, konkretnym wierszu użytkownika istnieje taka, a nie inna kolumna przechowująca jednorazowo wygenerowany token, który jest przesłany na maila, a następnie użyty w celu ustawienia nowego hasła. Zauważ jednak, że każdy może taki token wygenerować znając (na ogół) jedynie Twój adres e-mail. Jeśli byłoby tak jak mówisz, to wygenerowanie takiego tokena jednocześnie pozbawiłoby Cię dostępu do usług, bo system jak sam mówisz "nie ma możliwości przypomnienia dotychczas ustawionego hasła". Nie jest to dobra praktyka z oczywistych względów i nie powinna być stosowana. Zresetowanie hasła powinno być całkowicie niezależnym i w 100% odseparowanym procesem od logowania i korzystania z serwisu. Natomiast to w jakiej formie hasła są przechowywane to już zupełnie inna historia i wszystkie serwisy, które nie korzystają z odpowiednio bezpiecznego hashowania powinny być publicznie linczowane.

Naturalna kolej rzeczy biorąc pod uwagę, że nikt normalny dzisiaj nie przykłada do C większej wagi, i z oczywistych powodów. Rekruterzy zaznaczają to w swoich ofertach głównie z powodu wykorzystywania takich, a nie innych rozwiązań, być może autorskich, być może open-source, nad którymi ktoś musi czuwać i je rozumieć, przynajmniej w zakresie podstaw. Nie ma zasobów, możliwości, czasu albo pieniędzy, żeby je przepisać, a wspierać je z jednego lub drugiego powodu trzeba. A czemu nie przykłada się już do C żadnej wagi? Bo nie ma takiej potrzeby. Soft pisany w C to albo soft, który był pisany w C z powodu konkretnych, bardzo wąskich wymagań (kernel, sterowniki, mikroprocesory, komunikacja na poziomie OS-sprzęt), albo pisany 10+ lat temu. C, a nawet C++ dzisiaj nie robi nic lepiej czego nie robią języki bardziej przystosowane do konkretnego zadania, a w szczególności C# i znienawidzona przeze mnie Java, na półce razem z hipsterskimi node.jsami i resztą języków, w którym pojęcie wskaźnika czy alokacji pamięci po prostu nie istnieje. Znajomość C, o ile nadal przydatna w wielu zastosowaniach, nie jest dzisiaj absolutnym wymogiem dla wielu dziedzin programistów, i z bardzo dobrych powodów. Nic więc dziwnego, że liczba osób z takową się zmniejsza, a ilość przestarzałego oprogramowania do wspierania wręcz przeciwnie.

I właśnie to proponuję jak chcesz prawidłowo izolować wszystkie niezależne od siebie serwisy. Oczywiście masz jasną stratę zasobów (niekoniecznie wydajności, ale zasobów) spowodowaną duplikacją procesów dla każdej strony. Plusem jednak jest to, że ewentualny fuckup w kontenerze #1 nie wiąże się z fuckupem w kontenerze #4, nawet jeśli wykorzystują ten sam soft i konfigurację (ponieważ atakujący musiałby jeszcze wiedzieć o tym, że ten kontener w ogóle istnieje na tym samym serwerze, i dostać się do niego). Skonfontuj to sobie z sytuacją, w której dostaje się do serwera mysql i wywalam w kosmos wszystkie strony jednym DROP ALL DATABASES. Jasne, nie zrobi tego zwykłymi uprawnieniami, bo te mu zabierzesz, ale izolację robi się głównie na 0daye i czynniki nieznane, a nie te które możesz załatać, bo te które możesz załatać łatasz bez potrzeby używania dockera.

Jak chce coś zrobić na szybko np. w celach testów, środowiska dev czy czegoś co nie jest otwarte na świat, to jak najbardziej. Wszędzie indziej dalej preferuje KVM, przynajmniej na razie.

Bardzo prosto - możesz przykładowo zdefiniować, że kontener 1 (nginx) może się porozumiewać z kontenerem 2 (php-fpm) tylko przez port 9000 i tylko w kiernku nginx -> php-fpm, a więc kontener 2 miałby zablokowane wszystkie porty poza allow na TCP ESTABLISHED oraz TCP SYN na 9000, i jedynie od kontenera 1. https://docs.docker.com/v17.09/engine/userguide/networking/default_network/container-communication/ Idąc o krok dalej, obydwa kontenery miałyby wspólną przestrzeń plików dla danej strony WWW, ale mógłbyś ograniczyć uprawnienia w taki sposób, że nginx miałby dostęp tylko do statyki (wszystko poza plikami .php), a php-fpm tylko do plików .php (a nie do statyki). Oczywiście to już zależy od wymagań strony WWW (nie wiem czy np. nie czytasz plików txt z poziomu php), ale definitywnie można to ograniczyć. Jedno z takich ograniczeń to np. fakt, że nginx nie potrzebuje w ogóle mieć dostępu write do tego folderu, bo on nigdy żadnych plików tam tworzyć ani modyfikować nie będzie. Idąc o krok dalej - nginx nie powinien mieć żadnego dostępu do kontenera 3, którym jest mysql. Połączenie pomiędzy php-fpm, a mysql wyglądałoby bardzo podobnie co między nginxem i php-fpm, z różnicą portu 3306. Dzieki takiemu zabiegowi, zakładając, że ktoś by całkowicie przejął kontener 1 np. poprzez 0daya root na nginxa, jedynie co byłby w stanie zrobić to przeczytać pliki statyczne (które i tak serwujesz), oraz zawiesić/rozwalić samą usługę. O ile rzecz druga jest oczywista (w końcu 0day na nginxa), o tyle naprawa fuckupu po takiej akcji jest praktycznie bezbolesna i nie niesie za sobą żadnych innych problemów, jak np. fuckup całego serwera, wyciek danych czy dorzucenie malware'u po stronie serwowanych plików. Podobnie rzecz ma się w przypadku 0daya na mysql, ale tutaj byłoby już lepiej bo tego kontenera (jak i php-fpm) w ogóle nie wystawiasz na świat - pójście o krok dalej wymagałoby albo 0daya na php-fpm w specyficznej dla nas konfiguracji nginx -> php-fpm (co jest bardzo trudne biorąc pod uwagę, że nawet nie możemy stworzyć żadnego pliku), albo 0daya na dockera albo sam kernel. Obydwie dziury wymagają o wiele więcej zachodu niż jedynie 0day na nginxa i dodają bardzo sporą barierę w potencjalnej eskalacji, do tego stopnia że raczej bym się nie przejmował taką ewentualnością, choć jest ona oczywiście możliwa.

O, hash plików, który Piotr GRD opisał wyżej jest jedną z lepszych metod, tyle tylko że zamiast robić to na około to zrobiłbym albo mount w trybie readonly, albo chattr +i.

Ale co chcesz monitorować? Logi dostępu? Wykonywane akcje? Połączenia? Masz zamiar to czytać? Bo jeśli nie to wnioskuję, że równie dobrze możesz napisać skrypt w bashu w 2 min, który Ci wyśle na e-maila info o tym, że user X się zalogował z IP Y. Tylko co Ci to daje? Będziesz szukał narzędzia, które Ci zawali skrzynkę wszystkimi takimi logowaniami ze wszystkich możliwych usług na wszystkie możliwe sposoby czy jak? A jeśli jednak podchodzisz do sprawy praktycznie to nikt nie będzie siedział i analizował czy przypadkiem ktoś się nie włamał, bo przez ten zmarnowany czas mógłbyś wprowadzić kolejny layer security, chociażby kolejną regułkę iptables, która pozwoli na pakiety SYN wyłącznie na dane, z góry określone porty, co nie pozwoli na wystawienie jakiegoś exploita na nowy port i stworzenia serwera C&C. Logi prowadzisz po to, żeby w momencie ew. włamania albo fuckupu wiedzieć co się stało, gdzie i jak, a nie po to żeby je czytać, bo jak chcesz je czytać to możesz sobie grepem w basha wrzucić, nie wiem tylko po co. Monitorować możesz wiele rzeczy, ale jeśli coś monitorujesz to z definicji to coś jest przede wszystkim możliwe, a podstawowym założeniem w bezpieczeństwie jest to, że włamanie nie jest możliwe, poprzez dołożenie wszelkich starań, żeby to zdanie było jak najbardziej zgodne z rzeczywistością (co nigdy oczywiście nie ma miejsca, ale można mocno próbować). Ja wolę jednak łatanie dziur, a nie monitorowanie czy ktoś przypadkiem je wykorzystuje. Przy dobrze skonfigurowanym systemie atakujący nie odpali żadnego niepożądanego procesu, nie wrzuci żadnego podejrzanego pliku kopiącego bitcoiny, ani nie dotrze do wrażliwych danych. Przy takim systemie masz o wiele większą szansę na załatanie dziury znalezionej zupełnie przypadkiem i jednocześnie odcięcia atakującego niż "monitorowanie" całego ruchu sieciowego i "znalezienie" takiego intruza, zakładając oczywiście, że jesteś na pewnym poziomie wiedzy i bezpieczeństwa, bo jak monitorowanie u Ciebie znaczy grep "session opened" /var/log/auth.log to rozmawiamy jednak w zupełnie różnych kategoriach.

Podstawowa zasada, nieistotne czy w banku czy na kebabie u Olesa to limitowanie potencjalnego falloutu. Jeśli zakładasz, że atakujący wbije się np. przez twój serwery pocztowy (dajmy na to tragiczny 0day na postfixa), to robisz wszystko co w twojej mocy żeby wbił się TYLKO na tego postfixa, i nic poza tym. Teraz z kolei sposobów na izolację usług jest od groma, począwszy od chroota i jailkita, poprzez dockera, a na twardej wirtualizacji kvm kończąc, nie wspominając nawet o świetnym jailu z FreeBSD i podobnych narzędziach, które są wykorzystywane. Co jest najlepsze? A to już zależy od twojego widzimisię i tego jak bardzo ufasz lub też nie zabezpieczeniu, które chcesz stosować. Chroot przykładowo jest uznawany za jeden z najgorszych, a z patchem grsecurity stoi na tak wysokim poziomie, że nie znam osoby, któraby z niego dzisiaj wyszła. Działa? Działa, ale to nie znaczy że docker czy kvm jest gorszy, to jest kwestia doboru odpowiedniego narzędzia do potrzeb. Generalnie całość bezpieczeństwa się opiera o możliwie najniższy poziom dostępu dla danej usługi. Serwer pocztowy nie potrzebuje grzebać w bazie danych strony WWW, a php nie potrzebuje mieć dostępu do załączników w firmowej poczcie. Nginx nie musi odpalać nic poza swoimi własnymi procesami-dziećmi, a baza danych nie musi w ogóle akceptować połączeń z innych IP niż serwer php. To są tylko przykłady, bo tak naprawdę nie ma dolnej granicy i wszystko zależy od tego jak bardzo poniesie cię fantazja. Nie ma w 100% bezpiecznej usługi czy systemu, ale są takie, w których nawet hack nie stanowi zagrożenia dla reszty infrastruktury i jest w stanie co najwyżej spowodować problemy z tą jedną konkretną, a o wiele łatwiej naprawić jedną usługę niż cały serwer. Shakujesz mi postfixa, przechwycisz pocztę, w porządku, ale do danych klientów w bazie SQL już się tym nie dostaniesz (zakładając, że nie jestem skończonym kretynem i nie wysyłam haseł do roota e-mailem).

OK, postfix, albo exim jak ktoś ma uprzedzenia. Ale nie licz na to, że z marszu dostaniesz łatwą konfigurację. Z drugiej strony jak do tego postfixa dorzucisz jakiś panel typu ISPConfig to jest duża szansa, że nawet nie będzie trzeba dużo zmieniać. A całą resztę, której ISPConfig nie oferuje sam sobie skonfigurujesz z poziomu konfiguracji postfixa, bo wszystko co opisałeś to kwestia configa.

Główny wybór powinien być pomiędzy czymś stabilnym testowanym od lat o klasycznej strukturze, a nowinkami które równie szybko co się pojawiły mogą zniknąć. Z kategorii 1, która jest "pewniakiem" mamy m.in myBB, phpBB, SMF. Z płatnych nadal uważam IPB za najlepszy, ale jest jeszcze np. XenForo, które również kwalifikuje się jako pewniak. Z eksperymentalnych masz wszystkie nowinki, w tym FluxBB (to jeszcze żyje?), Flarum, Discourse, NodeBB. W szczególności ten ostatni jest ciekawy. Jakbym miał coś polecić od siebie to z obydwu kategorii to bym polecił myBB/Flarum. Jeśli jednak to ma być coś poważnego, a nie jedynie zabawka dla pięciu użytkowników to polecam IPB, które jednak stoi dużo wyżej od reszty.

@P-e-T-e-R Faktem jest, że w przeciągu miesiąca rozwaliłeś to, co na WHT było budowane latami - otwartą, przyjazną, specjalistyczną i fachową społeczność, która wspólnie podjęła decyzję o założeniu nowego forum, wyłącznie z powodu twoich własnych decyzji. Zastanów się, zgodnie ze swoją specjalistyczną wiedzą, której akurat nikt Ci nie próbuje odmówić, jaki wydźwięk miała każda twoja pojedyncza decyzja od zakupu WHT po dziś dzień i dojdź do wniosku dlaczego wyrzuciłeś kasę w błoto, bo czasy for już dawno się skończyły, a WHT jest obecnie archiwalnym cmentarzem postujących "gości", którzy z własnej woli lub też nie zostali zbanowani lub ich konta zostały usunięte. Efekt końcowy jest taki, że o ile na tematy merytoryczne jak najbardziej każdy może się wypowiedzieć, bo w końcu liczy się wiedza, a nie stanowisko czy firma, o tyle personalnie jak pewnie sprawnie zauważyłeś nie cieszysz się tutaj dobrą opinią, i z konkretnych, jasnych Ci powodów, których nie trzeba przedstawiać. Forum przede wszystkim jest dla wszystkich osób, które chcą przedyskutować dany temat w miejscu wolnym od cenzury i subiektywnego decydowania o tym co jest szeptanką, a co nie jest, co obecnie odbywa się na WHT. Zarówno Łukasz jak i ja to osoby niezwiązane z żadną firmą hostingową, niezależni fachowcy z branży, którzy postanowili stworzyć coś dla reszty, i nie jest żadną tajemnicą to, że stało się to wyłącznie z Twojej winy, o co wielu użytkowników RN ma do Ciebie bezpośredni, personalny żal i mało kto będzie w stanie zapomnieć jak nazwa.pl z Tobą na czele zmieniła liczące się forum dla specjalistów na własny słup ogłoszeniowy, w którym oprócz archiwalnego cmentarza jedyne co Ci zostaje to jednopostowcy pytający się jaki hosting wybrać, w temacie których moderatorzy twojego własnego forum odsyłają ich na PW w każdym momencie oznajmiając, że nie mogą im nic zaoferować. Nie wiem w tym momencie czy chociaż na sekundę zastanowiłeś się jaki wpływ mają Twoje decyzje na swój własny "plan" na forum, który napisałeś wyżej, bo albo jesteś jednym wielkim hipokrytą i nie możesz się pogodzić z tym co się stało, albo celem WHT jest przypominanie ludziom w jedynych tematach jakie jeszcze tam się znajdują, że te tematy już nie są mile widziane . W obydwu przypadkach powinieneś się zastanowić co chcesz osiągnąć, bo mam wrażenie że sam już nie wiesz. Odnośnie rankingu, merytorycznie będzie można na jego temat podjąc dyskusję jak już finalna jego wersja będzie udostępniona, z konkretnymi wynikami i algorytmami opisującymi działanie. Zakładając, że kod będzie open-source (a chłopaki mają taki zamiar), to każdy będzie mógł sam przejrzeć algorytm i zaproponować jego poprawę pod różnymi względami, w zależności od tego co konkretnie chcemy zliczać i jak definiować sam ranking. I jak już sam zauważyłeś wyżej - na forum każdy ma głos o tej samej wartości, to również dotyczy Ciebie i tego, że jesteś tutaj użytkownikiem tak samo jak każdy inny, bez prawa narzucania innym użytkownikom swoich zasad i tego kto co powinien mieć w stopce, a co nie. Jeśli uważasz, że stopka łamie regulamin RN, zgłoś to moderatorom. Jeśli uważasz, że regulamin RN powinien być zmieniony, zgłoś to administratorom. Jeśli nie chcesz podjąć żadnej z tych dwóch decyzji, powstrzymaj się od komentarzy, bo każdy ma identyczne prawo i wbrew temu co można zaobserwować na WHT, nikt tutaj nie usunie Ci stopki promującej nazwa.pl, tak długo póki będzie regulaminowa. To czy stopki są neutralne, szkodzą dużym firmom i pomagają małym, czy na odwrót, nie ma żadnego znaczenia w kwestii forum, które z definicji nie promuje żadnej firmy i jest niezależne od zarówno małych jak i dużych graczy, którzy mają swoje własne podwórka i tam mogą decydować o swoich własnych zasadach, co też sam robisz na WHT. Jeśli masz zamiar z niego wyjść i zawitać tutaj, to pomimo personalnego żalu witamy Cię z przyjemnością i zapraszamy do przestrzegania naszego własnego regulaminu i wspólnej dyskusji. Krytyka działania forum w pierwszym dniu rejestracji jedyne z czym się może spotkać to z poleceniem innego forum na którym zasady o wiele bardziej Ci odpowiadają, rzekłbym nawet że w 100%

Nie, to jest kwestia kosztów portu, który na ogół nie ma prawa się zwrócić. Jeśli wersja Linuxa w ogóle powstaje dla danej gry to na ogół jest to dodatek do używanego silnika (np. Unity), a nie kodowanie gry bezpośrednio z zamiarem wsparcia Linuxa jako takiego. Jeśli linuxowy gracz będzie chciał zagrać w daną grę to nie będzie go obchodziło czy jest windows only czy multiplatformowa, bo każdy szanujący się linuxowy gracz ma windowsa albo w dual-boocie albo w GPU passthrough już od lat, a ilość nowych graczy która by zagrała w dany tytuł wyłącznie dlatego, że wspiera ich platformę natywnie jest tak niska, że nawet nie ma co jej brać pod uwagę w jakimkolwiek zestawieniu. Sam koszt oficjalnego "wsparcia" poprzez informację, że nasza gra działa na Linuxie jest wyższy niż zyski z tej platformy. Wiele gier nie dostaje portów nawet na konsole poprzedniej generacji, a jest to tysiąc razy większy odsetek niż gracze linuxowi. Tutaj mogą być jakieś umowy, ale i tak wątpię, że dotyczą większości tytułów, raczej tylko te mocno nagłaśniane.