kafi

To zdanie jest zakręcone, to fakt. Ale znaczy ono, że naszybszy (w tym teście) vps z nazwa jest 3x szybszy od najwolniejszego (w tym teście) vpsa konkurencji.

Tu raczej do doczepienia się jest bardziej to 50 zł / rok, które powinno brzmieć "50 złotych za pierwszy rok", bo ta konfiguracja (hosting, cdn, kompresja obrazków i 2fa poczty) jest nie do dostania za 50 zł poza pierwszym rokiem. Chyba, że się mylę, ale to z chęcią wtedy wezmę to hurtem na 10 lat na część prywatnych zabawek Mierząc szybkość jako czas generowania strony sztucznego benchmarku - to tak, trzeba przyznać, że po moich testach u różnych usługodawców, czy to hostingowych czy nawet chmurowych, to są tacy, którzy co najwyżej dorównują nazwie, natomiast u żadnego usługodawcy (włącznie z chmurzastymi instancjami high-cpu-performance) pobić tego czasu się nie udało. Tylko... co z tego? Szybkość jest oczywiście dostępna i benchmark ją pokaże. Ale tak wyśrubowane parametry bezpieczeństwa i różne haczyki powodują, że to tylko iluzja, bo w normalnych zastosowaniach nic tego cpu nie będzie w stanie realnie wykorzystać na tym poziomie, bo zostanie to ścięte przez różne poboczne limity lub regulaminy. Porównując - najszybszym samochodem na świecie możemy uznać Bugatti Chirona Super Sport. Ale tę szybkość, to wykorzystać można jedynie do licytowania się i chwalenia się, że jeździ się najszybszym autem, a nie w jakichś realnych zastosowaniach. Wyobraźmy sobie korporację taksówkarską, która reklamuje się, że ma flotę złożoną z takich samochodów. Ale żeby nie było tak różowo, to korporacja zdefiniowała parę "parametrów bezpieczeństwa". Przykładowo - jechać może tylko jedna osoba; osoba może ważyć maksymalnie 100kg i mieścić się w jednym kubełkowym fotelu nie wystając za jego obrys; jako bagaż może mieć co najwyżej saszetkę czy małą damską kopertówkę - za więcej trzeba dopłacić; dodatkowo jak się chce mieć więcej miejsca na nogi (aka - kierowca odsunie mocniej przedni fotel) kolejna dopłata. Czy jazda taką taksówką spowoduje, że korzystający z niej klient najszybciej dojedzie do celu? Niekoniecznie. Czasem wyjdzie, że wzięcie nieco wolniejszego czy nieco gorzej klasy auta wcale nie spowoduje, że jakoś znacząco wolniej dojedzie się do celu, a będzie miało w ogólnym rozrachunku dodatkowe zalety. Np. to, że będzie się dało pojechać na współkę ze znajomymi albo przy większej tuszy w spokoju zająć dwa miejsca, kierowca przymknie oko na posiadany spory bagaż, czy po prostu ekonomicznie - będzie taniej.

Żadne DC nie zaoferuje ci internetu w formie "access" z takim wolumenem ruchu. Po prostu zapewnią ci miejsce na sprzęt, prąd do niego i peeringowe łączniki do poszczególnych operatorów internetowych. I to z nimi zawierasz umowy na throughput. Jak będzie cię stać na wykupienie u nich n*100Gbit/s ciągłego ruchu, to ci taki dostarczą. Jak nie, a taki potężny ruch przyjdzie, to będą się bronić; na początek policerem obcinającym ponadnormatywny ruch na porcie, a jak będzie go dłużej zbyt dużo, to zerwą peering (efektywnie - przestaną rozgłaszać, że przez nich dostępna jest twoja adresacja). Musisz pamiętać, że zasadniczo analiza i limitowanie ruchu "kosztują" i póki obsługa dużego ruchu nie generuje to kosztów albo nie ścina zysków, to (z technicznego punktu widzenia) nikt nie będzie w tej materii nadgorliwy.

To akurat jest bardzo prosto wyjaśnialne. Być może osoba, która pisze, jest tylko technicznym / outsourcowanym partnerem zajmującym się "stroną", podczas gdy abonentem usługi jest ktoś zupełnie inny. Żeby takie dane podawać w takim przypadku, to wypadało by mieć zgodę tego abonenta. A tak to po prostu "zanonimizowane" story ze współpracy To, że nie masz takich informacji (przy tej skali firmy) wcale nie oznacza, że takie coś się gdzieś nie pojawiło. No chyba, że kultywujecie micromanagement na poziomie znajomości każdego pojedynczego ticketa przez kierownictwo bok. Niby można. Ale. Dla osób siedzących "w branży" to jest, stety czy niestety, tak, że większość ma swoich ulubieńców z którymi im się dobrze współpracuje. No i wtedy jeśli dostają zlecenie u innego providera, to zamiast babrać się i wyjaśniać coś z supportem dostawcy, to po prostu końcowemu klientowi proponują zmianę na TegoSwojegoUlubionego, u którego z pewnością będzie działać, a nie to co tu. A klient końcowy, jako, że zazwyczaj "się nie zna" no to w to idzie. Inna sprawa jest taka, że przy dużych usługodawcach nie ma od razu połączenia z osobą techniczną, co niektórych irytuje, że muszą tracić na mówienie do konsultanta sprawy, on łaskawie przełączy gdzieś wyżej i wtedy znowu trzeba od początku mówić o co chodzi. Zasobożerność i długogenerowalność stron www to temat rzeka. Mierzenie tylko jednego parametru, jakim jest ta szybkość generowania stron, to takie sobie jest... Oczywiście, jest to dość mocno mierzalne i marketingowo fajnie się porównuje. Ale wcale to nie musi wpływać na całkowity współczynnik jakości. Bo co z tego, że mi się odpowiedź wygeneruje w 0,01s. skoro co druga to będzie błąd 503/509 o przekroczeniu dostępnych zasobów? Czasem korzystniejsze będzie poczekanie do nawet tej 1s. ale z pełną poprawną obsługą wszystkich przychodzących żądań.

Internal Cloud z flavorem High CPU: a ze standardowym generic flavorem:

Tak chyba nie do końca. Usługodawca dostając wiarygodną informację o nielegalnym rozpowszechnianiu ma prawo zareagować, inaczej sam naraża się na odpowiedzialność. Kwestia tylko co to jest wiarygodna wiadomość. Bo jeśli przyjdzie info od kancelarii mającej pełnomocnictwo Microsoftu, że na serwerze masz pliki chronione/dające dostęp do chronionych np. Windows i z grubsza wygląda, że mają rację (bo rzeczywiście, czy to strona, czy zgrubnie plik wygląda faktycznie na tego Windowsa a nie zdjęcie bukietu kwiatków) to wygląda to wiarygodnie; jeśli napisze Kowalski, że to jego obrazek bez podawania jakichś dowodów, to nie musi być wiarygodna informacja. Polecam poczytać sobie jeden z wyroków SN podsumowujący takowe, co prawda dotyczy to plików audiowizualnych, ale przy innych cyfrowych dziełach stanowisko będzie dość podobne: http://www.sn.pl/sites/orzecznictwo/orzeczenia3/ii cskp 3-22.pdf

Zatem ten element oferty czy reklamy wprowadza jawnie w błąd. Wyrażenie "ta sama cena po roku" oznacza, nie mniej, nie więcej, tylko tyle, że po roku od zamówienia zapłacę dokładnie tyle samo. Zauważ, że nikt nie ma pretensji do podwyżek cen, jako takich, bo one są zrozumiałe i macie do nich pełne prawo. Ale zapewniając klienta, że za rok zapłaci tyle samo, podczas gdy zapłaci więcej, może jak najbardziej frustrować i powodować utratę zaufania do firmy, która za nic ma składane obietnice. Tym bardziej, że na zwróconą na to uwagę reagujecie dość agresywnie: A tu po prostu może wystarczy przestać w komunikacji stosować obietnic bez pokrycia? Na moje oko by wystarczyło po prostu usunąć to hasło o tych samych cenach ze strony i napisać komunikat- przez długi czas obiecywaliśmy brak podwyżek; podwyżki są niestety nieuniknione - więc dla osłody najbliższe odnowienie będziesz Kliencie mieć po starej cenie, ale kolejne już zgodnie z cennikiem na stronie.

Cytując stonę a dalej już To w końcu korzystając z Authenticatora to jest całkowicie za darmo, czy za 200 zł netto rocznie?

NASK bez problemu dopuszcza renew z podaniem okresu 1-10 lat i nie spotkałem się z tym, żeby to kiedykolwiek było problematyczne... Szkopuł w tym, że trzeba zrobić to jednym zapytaniem EPP bo każde następne odnowienie do końca roku kalendarzowego będzie faktycznie rzucać błąd.

Może i tak. Ale finalnie to twoim (jako usługodawcy) problemem będzie udowodnienie mu, że to on je usunął i w jaki sposób. Bo on zgłosi ci jedynie tyle, że w programie pocztowym zniknęły wszystkie maile Poza tym, to tu dochodzimy jeszcze do innych ciekawych rzeczy jak np. tajemnica korespondencji itp. (ja przykładowo będąc w roli szefa firmy bym nie chciał, aby pracownik techniczny czytał moje maile bez jakiegokolwiek uwierzytelnienia czy chociażby logowania że je przeczytał ) i integralność danych (czy ten mail to rzeczywiście był wysłany, czy technik podrzucił coś do maildira).

Najlepiej będzie, jak po prostu podasz tu nazwy tych domen, to sprawdzi się o co chodzi, inaczej to tylko wróżenie z fusów. dnssec wymaga wprowadzenia przez rejestratora domen klucza wygenerowanego przez dostawcę dns. Jeśli w tym przypadku ustawione są DNSy ovh (i tam przekierowanie na hosting rekordami A) to będzie to z grubsza działać. Jeśli została zmieniona delegacja na hosting i nie zostały wprowadzone nowe klucze od dnssec dostawcy hostingowego lub dnssec nie został wyłączony całkowicie, to wtedy taka domena będzie działać wybiórczo - u tych, którzy nie sprawdzają podpisów dnssec.

Mam wrażenie, że ja o gruszce, ty o pietruszce Fajne marketingowe przedstawienie oferty (całkiem fajnej), ale nijak nie odnosi się do (mam wrażenie dość celowego) moim zdaniem niedopowiedzianego przedstawienia składników wpływających na rzeczywistą opłatę za usługę.

Ja to rozumiem. Ale tylko dlatego, że widząc takiego cukiereczka i mając techniczne obycie zacząłem szukać dokładnego cennika i dokładnych zasad rozliczeń (stąd pytanie o cpu). Obstawiam, że przeciętny Kowalski zrozumie ten przekaz tak, jak napisałem - "mam dodaną stronę, to za 10gr/h mogę hulać ile wlezie; usunę ją, to nie płacę tych 10 gr."

Rozumiem, całkiem ciekawe i dość uczciwe podejście do rozliczania tych dodatkowych zasobów... ... ale już do komunikacji i przedstawiania tej oferty nie. Takowy widok sugeruje dość mocno, że płaci się jedynie za czas działania danej strony (w godzinach) i w ramach tej opłaty 10gr/h hulaj dusza w ramach tych pokazanych parametrów. Uczciwe by było napisanie stawek cennikowych w tej tabelce (że bez limitu, ale dopłacasz xx za pojemność, xx za transfer czy xx za procesor). No cóż, znaczki pocztowe do wysyłania listów zwykłych kosztują i jakoś nikogo to nie dziwi

Co to znaczy "użycie procesora"? Czy to opłata za jakąkolwiek jego aktywność w ciągu zegarowej godziny, czy też może za zużycie każdego 1GHz w ciągu godziny, czy też może mierzony jest dosłowny cpu-busy-time w ciągu 24h i na koniec dnia zaokrąglony do pełnych godzin? Jedna inna pozycja jest też wg mnie ciekawa. "Obsługa poczty wychodzącej", Ciekawy jestem, czy i kiedy branża pójdzie za tym w swoich usługach

Galera to nie jest synchronizacja „w tle”, tu każda aktualizacja jest propagowana na wszystkie węzły klastra i dopiero wtedy potwierdzana klientowi (czasem kończąc się komunikatem o konieczności restartu transakcji). Przy rozłożeniu jej geograficznie i dobrych łączach będzie działać dość stabilnie, ale koszmarnie wolno. Ja miałem z wydajnością tego nawet problem przy serwerach w różnych dc w ramach francuskiego ovh, flow control mocno przymulał całość.

Obawiam się, że nie znajdziesz takiego usługodawcy pocztowego, który *każdą* wiadomość uznaną przez niego jako spam będzie przyjmował i zapisywał. Pytanie, co oznaczają jasne zasady. Heurystyka bayesowska czy inne spamowe AI to wybitnie niejasne zasady - nijak nie pozwolą ci stwierdzić konkretnie dlaczego ta konkretna wiadomość jest spamem, co najwyżej ulubione "bo była podobna do innych takich uznawanych jako spam" - co tak naprawdę nic nie mówi. Nawiązując trochę do wątku - to dla mnie wyrażenie to raczej żartobliwe określenie, że w skrzynce @Pawel_15 ma dokładnie to, czego potrzebuje i nie musi ani niechcianych wiadomości oglądać w inboxie, ani też szukać zagubionych wartościowych wiadomości po folderze ze spamem i niezbyt go te technikalia interesują.

Tylko... czy ty jesteś potencjalnym klientem, czy szukasz tylko powodu do zaczepki, żeby sobie publicznie "pojeździć" po jakiejś losowej firmie? Bo wiesz, Progreso na stronie ma podany nr telefonu, gdyby ci rzeczywiście zależało na odpowiedzi rozwiewającej twoje wątpliwości (a nie benchmarku obsługiwania jaśnie panicza) to z pewnością w trakcie rozmowy tel. by ci ktoś na to odpowiedział

Zgadza się, każda firma ma prawo ustalać ofertę według siebie i niezależnie od innych firm. Tylko tyle, że wtedy to powinna jasno napisać o tym, że to po prostu biznesowe strzyżenie owiec, a nie wymigiwać się tym, że to uwarunkowania techniczne. Widać to jest chociażby po tym DKIM dla domen, które z "technicznie się nie da" zbiło się w tej dyskusji do bycia "najprostszym sposobem" Za takie stwierdzenia powinien się zająć wami UOKiK. Bo nie, firma którą reprezentujesz nie jest jedyną wymieniającą ruch bezpośrednio z wieloma dostawcami Internetu w naszym kraju

Nie wymaga, czego Microsoft jest dość dobrym przykładem Tam konfiguracja jest taka, że umożliwia bezproblemowe rollowanie bez późniejszego dłubania w strefach domen klienta końcowego. Więc jak widzisz w takim modelu ile propagandy by w to nie włożyć, to nie da się nic zagwarantować, bo i tak znajdzie się coś, co może być przyczyną niedziałania usług

Domena może wygasnąć, domena może zostać z jakichś powodów zablokowana przez rejestr domen, wtedy poczta niezbyt będzie dochodzić, rozumiem że bierzecie wtedy za to odpowiedzialność? Próba mówienia, że to ograniczenia techniczne, a nie stricte biznesowe wyciąganie kasy, sugeruje raczej brak ogarnięcia administratorów niż jakiekolwiek przyczyny techniczne. Bo jak to jest, że zarówno Microsoft (Office365/Exchange Online) jak i Google (Workspace) bez problemu radzą sobie z podpisywaniem DKIM bez terroryzowania klientów pod tytułem "musisz korzystać z naszych serwerów". CloudFlare to nie tylko ochrona antyDDoS i CDN. To także chociażby waiting room (którego wy nie zapewniacie inaczej jak tylko serwując losowo response(5XX) ) czy Access

Ja wiem, że moja wypowiedź jest dosyć długa. Ale nawiązując do niej warto przeczytać ją w całości, bo komentarz dotyczący powyższego też w niej jest zawarty No ale to jest odrębna usługa, która już z samej oferty może sugerować brak neutralności technologicznej w jej świadczeniu.

Temat porządnej obsługi CDNów nie jest taki prosty, jak tu się niektórym wydaje. Oczywiście, można skonfigurować to po prostu na branie przez serwer www adresu IP z nagłówka X-Forwarded-For żądania HTTP zamiast pobierania go z nagłówka pakietu IP. Problem tylko taki, że... skąd pewność, że druga strona nie "oszukuje" i nie podstawia tam czegoś fałszywego? Przecież ktoś może połączyć się bezpośrednio do serwera upstream i wysłać tam spreparowany przez siebie nagłówek. Nawet nie złośliwie - może jego ruch przechodzić przez transparentne proxy które dodaje taki nagłówek; no i wtedy w logach nie wiedzieć skąd pojawi się np. adres 192.168.10.20. Więc dalej - w konfiguracji porządnych modułów do obsługi load balancerów, czy to mod_remoteip, czy to np. w LSWS definiuje się adresy/bloki zaufane z których może przyjść żądanie. No ale o ile LB jest pod naszą kontrolą, to aclkę zdefiniuje się raz i sama się nie zmieni; o tyle przy zewnętrznych usługodawcach ich adresacja lubi się zmieniać i ktoś tego musi na bieżąco pilnować. Do tego dochodzi pewna nazwijmy to neutralność technologiczna usługodawcy - czyli jeśli zacznie akceptować coś automatycznie od usługodawcy X, to z pewnością znajdzie się protestujący głośno dostawca Y czy Z, albo i klient z własnym CDN który będzie mówił, że jest dyskryminowany. Inna droga protekcji (ale stosowana jest ona zazwyczaj trochę z innych powodów) jest wymuszenie transmisji CDN-upstream przez SSL z wymuszoną obustronną weryfikacją certyfikatów - wtedy do aplikacji nie zostanie dopuszczony klient łączący się bezpośrednio. CF takie coś wspiera, ale ani to popularne w usługach hostingowych (nie znalazłem szczerze mówiąc żadnego który takie coś umożliwi stockowo) ani bezpieczne (jak CF się odwidzi proxować ruch i ustawi passthru, to nie będzie działać). I z innej beczki - to jeśli logi mają mieć jakąkolwiek wartość dowodową, to musi tam znajdować się adres IP łączącego się węzła, inaczej zostaną zakwestionowane przy porównaniu z logami operatorów telekomunikacyjnych. Bo gdy służby zwrócą się o informację, czy adres 1.2.3.4 łączył się z 2.3.4.5 to dostaną odpowiedź odmowną; bo 1.2.3.4 łączył się z CF a nie 2.3.4.5. A najlepiej jeszcze, jak znajdzie się tam SRCPORT, który jest bardzo pomocny dla znajdowania osób zza wszelakich CGN (carrier grade nat). Dla mnie najbardziej salomonowa metoda obsługi CDNów wszelakich, to: - modyfikacja formatu logów, żeby zawierał zarówno rzeczywisty adres IP łączącego się, jak też nagłówek X-Forwarded-For - danie klientowi możliwości zdefiniowania samemu trusted proxy list, z których akceptowana będzie translacja nagłówka X-Forwarded-For - opisanie w dokumentacji jak to działa i jak skonfigurować to pod dostawców najpopularniejszych CDNów ale nie robienie tego automatycznie, aby nie dyskryminować tu nikogo.

Tu nie o resolver chodzi. Znaczna większość systemów pocztowych (szczególnie te stockowe z cPanelu i DirectAdmina ) jeżeli domenę ma dodaną w swojej konfiguracji jako lokalną, to wtedy dokonuje "local delivery" nie odpytując nawet serwerów DNS (bo i po co je męczyć, skoro to poczta "lokalna"?). Takie to są wymogi niektórych rejestrów (to nie jest widzimisię rejestratora!) że serwery nazw muszą być poprawnie skonfigurowane. A czemu? W przypadku .de to chyba ot, żeby był niemiecki porządek - bo DE jest jednym z bardziej upierdliwych rejestrów w kwestii zonecheck. Musi być SOA, w SOA refresh, retry, expire i ttl muszą być z określonego zakresu; do tego w strefie muszą być utworzone dokładnie takie rekordy NS jak te, na które delegujesz domenę; no i serwery muszą mieć różne adresy IP (sytuacja, że ns1.domena.pl i ns2.domena.pl kieruje na ten sam IP jest tam niedozwolona). Kiedyś jeszcze wymogiem było to, że muszą być z różnych klas adresowych, ale od tego chyba odeszli.

Tak w dużym uproszczeniu przed tym, abyś nie mógł zaparkować domeny gmail.com i utworzyć w niej skrzynki catch-all zbierającej całą pocztę wysyłaną od innych klientów tej firmy hostingowej do Gmaila.