Skocz do zawartości

Archi

Donatorzy
  • Ilość treści

    137
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    15

Archi wygrał w ostatnim dniu 16 Lipiec

Archi ma najbardziej lubianą zawartość!

Reputacja

73 Excellent

1 obserwujący

Ostatnio na profilu byli

669 wyświetleń profilu
  1. A ja nigdy nie twierdziłem, że każde rozwiązanie budżetowe będzie lepsze od dedykowanej usługi, jeśli by tak było to by wszystkie płatne rozwiązania poznikały z rynku. Jedyne co powtarzam to to, że można podobne wyniki osiągnąć we własnym zakresie, zakładając posiadaną wiedzę, czas i umiejętności. Emaillabs jest pewnie dobrą usługą dla osób, które wolą przynajmniej ten segment zlecić komuś innemu, i nie ma w tym nic złego, tak samo jak nie ma nic złego w dedykowanej administracji serwerem dedykowanym czy VPSem, przecież nie każdy wysyłający maile jest jednocześnie adminem . Jednocześnie dalej nie uważam, że takie rozwiązanie z definicji musi być lepsze, jakbym się uparł to pewnie nawet byłbym w stanie merytorycznie udowodnić testując wielu różnych providerów, że jestem w stanie wyrobić więcej dostarczalności niż oni, ale to nie są zawody, a jedynie udowodnienie, że emaillabs nie ma żadnej prywatnej specyfikacji protokołu SMTP, w której filtrowanie spamu jest pomijane, a po prostu sztab ludzi takich jak ja, którzy świadczą taką usługę odpłatnie. Mi nawet nie zależy na byciu lepszym, mi wystarczy, że maile które wychodzą ode mnie zawsze trafiają tam gdzie trzeba, a czy to jest 99.95% czy zaledwie 90% to już mi wszystko jedno, tak długo póki spełnia moje oczekiwania i jednocześnie jest tańsze niż alternatywy, bo w końcu o to chodzi. Podsumowując, bo nie odpowiedziałem na pytanie z wątku, jeśli masz wiedzę lub osoby, które są ogarnięte w temacie to taniej można osiągnąć podobne rezultaty we własnym zakresie i środowisku, ale żadne rozwiązanie nie gwarantuje 100% dostarczalności, a co najwyżej konkretną dostarczalność w obrębie testowanych providerów (i też nie do końca, bo treść maila, jego konstrukcja, nagłówki i pozostała część są co najmniej równie ważne jak serwer, z którego się wysyła, jeśli nie ważniejsze).
  2. Ponoć "żaden inny dostawca nie ma 100%" według twojego jedynego słusznego mail testera, no to już masz dwa. Koszt powyższego rozwiązania: 4 zł na miesiąc za IP (które ma jeszcze inne zadania), chyba że liczysz jeszcze najtańszego VPSa, który uciągnie wysyłkę maili, no to będzie może z dyszka . Nie wiem co test wyżej ma potwierdzić, ale skoro mi rzuciłeś wyzwanie to proszę bardzo.
  3. Nigdzie nie napisałem, że dedykowany IP zastępuje ludzi i umowy z providerami. Napisałem, że dedykowany IP z odpowiednim środowiskiem jest w stanie działać porównywalnie lub nawet lepiej do emaillabs, jednocześnie kosztując ułamek jego ceny, z racji że sam IP to koszt ok 4 zł netto na miesiąc. Jestem w stanie zbudować takie środowisko (a nawet już takie mam na produkcji), i o ile ciężko mi oszacować procentową dostarczalność maili, tak nigdy nie miałem informacji o żadnej zwrotce, wylądowaniu w spamie czy zagubieniu, i w pełni uważam, że wszystko co oferuje emaillabs jesteś w stanie osiągnąć samemu, zakładając że wiesz co robisz. Oferta dedykowanych providerów do poczty niczym się nie różni od oferty zarządzanych VPSów czy dedyków. Próbujesz mi udowodnić, że serwer WWW postawiony na dedyku przez profesjonalnego administratora, z usługą kosztującą 999 miesięcznie musi być z definicji lepszy od dedyka, którego postawię sam, a prawda jest taka że nie dość, że jestem w stanie postawić identyczny w cenie 200 zł na miesiąc, to jeszcze i lepszy. Tutaj jest bardzo podobnie, i jedyny argument jaki w ogóle możesz podnieść to właśnie umowy z partnerami, które w pełni rozwiązuje długofalowa reputacja danego IP jako serwera SMTP, i jest czasem nawet wyżej punktowana niż whitelisty, właśnie z tego powodu, że w przypadku emaillabs każdy może zapłacić i zacząć wysyłać spam, a do mojego serwera dostęp mam wyłącznie ja sam. Polecam zobaczyć jak te umowy i whitelisty wyglądają w praktyce, to zobaczysz że jest to wyłącznie wyższy score w ogólnym zestawieniu, a nie żadna biała lista 100% dostarczalności (które nie istnieje, jak już omówiono powyżej). Umowa polega na wzajemnym informowaniu siebie i punktowaniu, a nie na żadnym "dobra to my puścimy wszystko od was i załatwione". Co więcej Ci powiem, nie zastąpiłbym swojego rozwiązania Twoją usługą emaillabs nawet gdyby kosztowała tyle samo, właśnie dlatego że mam pewność co do historii mojego IP, jego rejestracji oraz użycia, czego nie mogę powiedzieć o firmie, która będzie nad tym czuwać w moim imieniu. Wystarczy, że jeden użytkownik kiedyś wysłał spam z emaillabs (i to zupełnie innego IP), i już w tym momencie ma rekord gorszy niż mój serwer, który spamu nie wysłał nigdy, a historia wzajemnego zaufania sięga lata wstecz. I dlatego usługi takie jak emaillabs istnieją, tak samo jak serwery dedykowane z administracją czy zarządzane serwery VPS. Problem zaczyna się wtedy, kiedy próbujesz wmówić doświadczonym, dedykowanym administratorom i developerom, że Twoje rozwiązanie jest najlepsze, powołując się na ładny obrazek, zapewnienia firmy i statystyki z czapy, zamiast na wartości merytoryczne, które punktuje ja. To tak jakby nazwa.pl napisała, że ma najlepszy krajowy system do rejestracji domen, no bo przecież ma najwięcej zarejestrowanych .plek w Polsce. Emaillabs to usługa jak każda inna, i nie jest w stanie w żaden sposób wspiąć się powyżej własnych, dedykowanych, często autorskich rozwiązań, a co najwyżej zrównać się z nimi i oferować względnie dobrą usługę za odpowiednią cenę. Jeśli nie masz doświadczenia, możliwości lub pieniędzy stworzyć takiego sam, lub po prostu jest Ci emaillabs na rękę, to nikt tutaj nie będzie się z Tobą kłócił, bo nie wątpię że są w stanie robić swoją robotę dobrze, ale nie zapędzaj się ze stwierdzeniami niższości własnych rozwiązań, chyba że masz merytoryczne argumenty i doświadczenie, które z miłą chęcia mogę zweryfikować z własnymi.
  4. To polecam tylko żyć w swoim świecie, bo widocznie wszyscy się zgadaliśmy, że będziemy na forum bullshit wypisywać .
  5. Emaillabs z dedykowanym IP nie gwarantuje Ci, że wczoraj z tego samego IP nie wysłałem setki spamu. Nawet jak podepniesz swoje własne IP to również nie gwarantuje, że wczoraj z tego samego IP nie wysłałem niechcianego mailingu, przed zwróceniem go do odpowiedniego ISP. Poczta ze 100% dostarczalnością nie istnieje, można jedynie wyposażyć się w dedykowany adres IP i o niego dbać, a dbanie o niego to posiadanie go przez kilka dobrych lat i upewnienie się, że żaden spam z niego nigdy nie wyjdzie. Pewnie, są firmy które w Twoim imieniu dbają o własne adresy, i dlatego takie emaillabs może mieć wyższe współczynniki dostarczalności niż losowy shared hosting z brzegu, ale to wciąż nic nie gwarantuje, a jedynie zwiększa szansę. Jak @patrys napisał wyżej, własne środowisko, własne IP i własne rozwiązania mają największą skuteczność, ale reputację się buduje latami, a nie w jeden dzień. Nawet 100% czyste dopiero co zarejestrowane IP nie daje żadnej gwarancji, a raczej właśnie takie z dużą ilością zaufanych maili, które były wysyłane i weryfikowane przez ostatnie lata. Ja osobiście stosuje mix, i mój SPF ma zadeklarowane kilka serwerów, które są uprawnione do podpisywania się daną domeną, a serwer z którego wychodzi mail jest niejako powiązany z jego ważnością i źródłem, przy czym wszystkie serwery są trzymane na najwyższym poziomie (ale jednocześnie jest oczywista różnica między np. SMTP dla całej firmy, a SMTP tylko dla dyrekcji).
  6. Prawidłowym rozwiązaniem jest nie używać w ogóle CURLOPT_FOLLOWLOCATION, a zamiast tego poprawić swój kod, żeby nie używał linków, które redirectują 3xx (co nie jest zbyt bezpieczne jeśli mowa o wykonywaniu requestów curlem). Jeśli dhosting chce używać open_basedir'a (co jest wskazane), to jest to w zasadzie jedyna słuszna opcja. safe_mode jest deprecated od bardzo dawna i wątpię, żeby ktokolwiek go jeszcze dzisiaj używał, nie wspominając nawet o tym, że od PHP 5.4 w ogóle go nie ma.
  7. Zależy co konkretnie chcesz ograniczać, bo ograniczenie pamięci dla poola PHP osiąga się zupełnie inaczej niż ograniczenie limitów na całego usera. Jak usługa, to warto najpierw pogrzebać w niej samej i sprawdzić czy ma jakieś ustawienie, które osiągnie to co chcesz. Jeśli nie, możesz zastosować cgroups z limitami per proces, które działa bardzo fajnie i sprytnie. Jeśli chcesz limitować całego usera czyli wszystkie jego procesy, to raczej ulimits, chociaż cgrupy również się sprawdzą. CPU nie polecam w żaden sposób ograniczać, a raczej odpowiednio ustawić priorytety i depriorytetyzować userów. Jednak jeśli chcesz, to polecam znowu cgroups, ewentualnie cpulimit, ale do niego mam sporo technicznych zastrzeżeń.
  8. To też zauważyłem. Generalnie nie uważam tego za złe biorąc pod uwagę, że sztucznie nie ograniczają, a jedynie dowalają oszczędność mocy jak tylko mocno się da, ale faktem jest że każdy świadomy administrator pierwsze co powinien zrobić to albo wywalić to jądro całkowicie, albo zrekompilować pod siebie, bo części z tych opcji podczas runtime'a nie ruszysz.
  9. Kompilacją nie benchmarkuje się ani CPU and I/O z powodu niejednoznaczności kompilowanych źródeł, użytego kompilatora oraz maści czynników trzecich. Benchmark CPU czy I/O dokonuje się programami do tego służącymi, które używają tych samych kryteriów aby wygenerować sensowny wynik. GCC, który na jednym CPU użyje instrukcji SSE 4.2 żeby przyspieszyć proces translacji kodu źródłowego na binarny, a na drugim AVX2 nie jest obiektywne i w żaden sposób nie przekłada się na rzeczywistą wydajność obydwu maszyn w starciu z np. ilością requestów na sekundę nginxa. Więc nie, jeśli robisz benchmark maszyny przez puszczenie kompilacji php to robisz to źle i nie masz zielonego pojęcia o zasadzie działania benchmarków i czym się różni benchmarkowy test od kodowania wideo, obsługi requestów na socketach czy kompilacji właśnie. Jak chcesz się kurczowo trzymać swojego przykładu z samochodem to w tym momencie stwierdzasz, że samochód który maksymalnie jedzie 200 km/h jest szybszy od tego co ma na liczniku 190 km/h, a to że pierwszy dobija do dwusetki w 5 minut i przejedzie krótszy dystans w ciągu minuty niż drugi, który dobija do 190 km/h w 3 sekundy już całkowicie ignorujesz, bo nie patrzysz na żaden inny współczynnik ani sam fakt, że maksymalna prędkość może nie mieć nic do gadania w sytuacji, gdy test trwa 3 sekundy i nigdy jej nie uświadczysz. I właśnie taką zasadniczą różnicą jest np. wielkość cache L1/L2/L3 w CPU, który w kompilacji odgrywa znacznie większą rolę niż w wykonywaniu kodu już skompilowanego. To, że jedna maszyna radzi sobie lepiej z A nie oznacza, że jednocześnie radzi sobie lepiej z B, i to nawet porównując kompilację dwóch różnych projektów, a co dopiero kompilację z zupełnie innym zadaniem.
  10. Ja już od dawna jadę na oficjalnym kernelu dystrybucyjnym, czasem jeszcze na własnym. Kernel od OVH ma zbyt dużo generycznych śmieci, które są ładowane w każdym wypadku. Zakładając, że twoja maszyna potrzebuje 30% kernela, w kernelu debiana załaduje się core 5% bez którego kernel w ogóle działać nie może, a pozostałe 25% dociągnie się z modułów, gdzie w kernelu ovh na siłę leci 40% czy Ci się to podoba czy nie, bo wszyscy w OVH boją się modularnego kernela jak ognia. W efekcie końcowym nie tylko jesteś podatny na o wiele więcej bugów niż zwykle (bo każda linijka kodu ma szanse na konflikt), ale sam kernel działa dużo wolniej i potrzebuje więcej pamięci bo ma na twardo załadowane co najmniej kilkadziesiąt modułów, które na twojej aktualnej maszynie do niczego nie są używane.
  11. KVM nie jest potrzebny do niczego mając tryb rescue. Administrator który zna się na swojej robocie wie o istnieniu takich rzeczy jak /proc/last_kmsg (ew. pstore) i nie potrzebuje bezpośredniego dostępu do konsoli. I to zakładając, że chcesz znać przyczynę problemu, bo zwykłe "kernel nie wstaje" załatwia grub fallback.
  12. Jeśli bottleneckiem jest I/O to warto rozważyć fs, który oferuje natywnie kompresję, ZFS będzie bardzo dobrym wyborem pod storage, i kompresję również oferuje.
  13. Punkt 2 w dużej mierze zależy od firmy/osoby zajmującej się tym serwisem. Jeśli jest to znak towarowy to sądownie można rządać zdjęcia Twojej domeny. Do tego dochodzi jeszcze sporo artykułów z zakresu zwalczania nieuczciwej konkurencji, w tym przede wszystkim w tym wypadku podszywanie się pod daną markę w celu wprowadzenia klienta w błąd. Nie sugerowałbym pójscia w tym kierunku, nawet jeśli Twój serwis nie byłby powiązany w żaden sposób z oryginalnym, a zajmowanie się dokładnie tym samym, o ile nie masz naprawdę dobrych argumentów na swoją obronę, może być bardzo łatwo potraktowane jako próba wyłudzenia. Oczywiście decyzję może wydać wyłącznie sąd i zdarzały się co najmniej "dziwne" wyroki w tych kwestiach, ale na ogół powinieneś się starać uniknąć problemów, a nie tworzyć z nadzieją, że nic z nich nie wyniknie, przynajmniej z biznesowego punktu widzenia.
  14. W zależności od wymagań i oczekiwań, PHP nie musi być wymagany. Sam ostatnio odkrywam ile rzeczy potrafi zrobić webpack z vue, i tak długo póki nie wchodzimy w tematykę baz danych i klasycznej wizji strony internetowej, tak długo można naprawdę sporo osiągnąć statycznym kodem generowanym dynamicznie w oparciu o bardzo skomplikowane czasem źródła.
  15. Też korzystam z keepassa - mając trochę umiejętności jesteś w stanie bez problemu zrobić sobie własną chmurę synchronizując bazę z hasłami tam gdzie trzeba. Do tego jest sporo dodatków, które automatycznie łatają niewygodne dziury (mam tu na myśli przede wszystkim chromeipass dla chrome'a i chromium), przez co jest to bardzo fajne, otwarto-źródłowe rozwiązanie, całkowite niezależne od czegokolwiek i oferujące Ci wybór na ew. rozszerzenia we własnym zakresie. Nic nie stoi na przeszkodzie w używaniu keepassa np. z nextcloudem, wraz z apką na androida. Na pewno mam większe zaufanie do takiego rozwiązania niż do czegokolwiek "online".
×
×
  • Utwórz nowe...

Ważne informacje

Korzystając z forum, wyrażasz zgodę na: Warunki korzystania z serwisu, Regulamin, Polityka prywatności.