Skocz do zawartości

Archi

Donatorzy
  • Ilość treści

    127
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    11

Archi wygrał w ostatnim dniu 7 Listopad 2018

Archi ma najbardziej lubianą zawartość!

Reputacja

58 Excellent

1 obserwujący

Ostatnio na profilu byli

553 wyświetleń profilu
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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".
  6. Zbyt dużo zależy od domeny. Nie wyobrażam sobie jakiegoś portalu informacyjnego na czymś pokroju x7z.pl i na ogół domeny z liczbą są dość rzadko spotykane, żeby nie powiedzieć, że w ogóle. Wyjątkiem jest nazwa jakiegoś brandu lub sama firma, bo tutaj domena jest tylko odnośnikiem po więcej informacji, a nie własnym niezależnym serwisem (np. h88.pl). Są jednak domeny gdzie cyfra na początku, albo na końcu nie robi aż tak kolosalnej różnicy, ale chyba nadal uważam, że o wiele lepiej tego unikać - jakiekolwiek pozycjonowanie czy budowanie marki/brandu na czymś takim jest o ile nie skazane na porażkę, to na pewno mocno pod górkę w stosunku do innych.
  7. Polecam postawić sobie jakiś prosty panel do zarządzania subdomenami, czasy gdy z palca się robiło configi nieco odeszły już do lamusa. ISPConfig świetnie współgra z nginxem, korzystam i sobie chwalę. Wszystkie regułki możesz sobie wpisać do panelu, a i sporo rzeczy masz z automatu, chociażby certyfikaty LE. Sam nie przepadam za większością paneli hostingowych, a niektóre z nich (np. VestaCP) powinno się wręcz wymazać z historii. M.in dlatego lubię ISPConfig, bo nadal masz pełną kontrolę nad tym co panel ma robić, a co chcesz robić manualnie, więc pomagasz sobie tam gdzie chcesz, a nie tam gdzie musisz. Jest to też jeden z niewielu paneli, który działa dosłownie z każdą, nawet najbardziej egzotyczną konfiguracją, w tym z moją produkcją na debianie testingu opartej właśnie o nginxa. Zero problemów.
  8. Rzeczywiście trudno będzie znaleźć coś taniej i lepiej niż aruba, przynajmniej za tę cenę. Oczko wyżej będą najtańsze kimsufi, ale to już koszt co najmniej 20 zł / mc, co najmniej czterokrotnie więcej, więc jeśli będzie działać OK to nie ma sensu zmieniać (sam nigdy nie testowałem jak u nich ze stabilnością).
  9. GZIP na ogół działa na plikach tekstowych gdzie możesz osiągnąć kompresję wynoszącą ułamek pliku docelowego - w przypadku perfekcyjnie kompresowalnych danych rzędu 1/1032. Nawet z przeciętnymi plikami html jesteś w stanie bez większych problemów osiągnąć od 1/5 do 1/20 rozmiaru docelowego. Samo przesłanie tych danych może kosztować Cię więcej niż ich skompresowanie, i jak najbardziej mówię tutaj o CPU na transmisję TCP - wyliczanie sum kontrolnych pakietów również swoje kosztuje. Użycie gzip -1 na dobrze kompresowalnych plikach (text/html, text/css, text/plain, application/javascript itp) niemal zawsze poprawia lub przynajmniej zrównuje wydajność zarówno po stronie użytkownika jak i serwera. Nie ma żadnego logicznego powodu na rezygnowanie z kompresji dobrze kompresowalnych plików, musiałbyś serwować miliony plików o wielkości pojedynczych bajtów, żeby koszt ich kompresji przewyższył ich przesył. Jak ostatnio sprawdzałem benchmarki to już przy 130 KB (skompresowanych do ~13 KB) plikach gzip się zrównuje z CPU na TCP. Do tego poza samym CPU dochodzi Ci jeszcze koszt przesłania tych danych, odebrania ich po drugiej stronie i sparsowanie - coś co również będzie o wiele szybsze po stronie klienta gdy odbierze 13 KB i zdekompresuje niż sparsuje pełny ciąg 130 KB.
  10. Nie zapominaj o "pomyłkach systemu" i dostawaniu nieprawidłowych kodów authinfo, które co najmniej kilku użytkowników zgłaszało w przypadku nie tylko tej firmy .
  11. TLS 1.3 prawdopodobnie rozwiąże ten problem. Poza tym w wielu przypadkach (np. Cloudflare) w żaden sposób nie identyfikuje to końcowej strony.
  12. 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.
  13. 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.
  14. 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.
×
×
  • Utwórz nowe...

Ważne informacje

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