[opinia] Prohost.pl

[is_wm 287]

Domyślnie cpanel aktualizuje się codziennie A jak ktoś używa wersji EDGE to może się ona zmieniać nawet pare razy dziennie (http://changelog.cpanel.net/)

 

Standardem w MySQL jest UTF-8 (nie latin1), jednak to faktycznie 2 kliknięcia żeby zmienić sobie kodowanie w PMA.

 

Trochę ostra opinia jak na takie pierdoły.

[Prohost 345]

Standardem w MySQL jest UTF-8 (nie latin1)

 

Standardowe ustawienia mysql:

 

character set client utf8

(Wartość globalna) latin1

character set connection utf8

(Wartość globalna) latin1

character set database latin1

character set filesystem binary

character set results utf8

(Wartość globalna) latin1

character set server latin1

character set system utf8

collation connection utf8_unicode_ci

(Wartość globalna) latin1_swedish_ci

collation database latin1_swedish_ci

collation server latin1_swedish_ci

[www.ionic.pl 535]

Standardowe ustawienia mysql:

 

character set client utf8

(Wartość globalna) latin1

character set connection utf8

(Wartość globalna) latin1

character set database latin1

character set filesystem binary

character set results utf8

(Wartość globalna) latin1

character set server latin1

character set system utf8

collation connection utf8_unicode_ci

(Wartość globalna) latin1_swedish_ci

collation database latin1_swedish_ci

collation server latin1_swedish_ci

 

Ojej ... Panowie standardowe jest takie jakie się wkompiluje albo wymusi

[Prohost 345]

Ojej ... Panowie standardowe jest takie jakie się wkompiluje albo wymusi

 

Z dokumentacji mysqla:

 

By default, MySQL uses the latin1...

 

Standardowo używa latin1. Tak samo collation latin1_swedish_ci jest standardem.

[malu 460]

Co nie oznacza, że nie powinno się go zmienić...

Ale jeżeli klienci nie mają zastrzeżeń to niema problemu. Jednak według mnie mniej problematyczne jest ustawienie UTF8 jako domyślnego kodowania

[www.ionic.pl 535]

Co nie oznacza, że nie powinno się go zmienić...

Ale jeżeli klienci nie mają zastrzeżeń to niema problemu. Jednak według mnie mniej problematyczne jest ustawienie UTF8 jako domyślnego kodowania

 

Dokładnie bo późniejsza zmiana lub przenosiny baz lubią być problemowe.

[Prohost 345]

Co nie oznacza, że nie powinno się go zmienić...

Ale jeżeli klienci nie mają zastrzeżeń to niema problemu. Jednak według mnie mniej problematyczne jest ustawienie UTF8 jako domyślnego kodowania

 

Najmniej problematyczne jest używanie standardowego kodowania

Wtedy użytkownik wie czego może się spodziewać.

 

Tyle, że w przypadku mysqla różnice kodowania między jakimiś serwerami to nie jest problem i każdy może sobie ustawić jak mu się podoba.

 

U nas zawsze jest ustawiony standard tam gdzie nie jest wymagane lub wskazane inne ustawienie.

[bukox 0]

1. Updgrade cpanela trwa około 5 minut i dostęp do niego się zwyczajnie wyłącza - więc nie można nic w nim wtedy zrobić - a kiedy go robimy to zależy od potrzeb - może to być 4 w nocy lub 4 w dzień.

Skoro dostęp się wyłącza to jakim cudem mnie udało się wejść a przy próbie zapisu pojawiły się różne błędy. Efekty mojej pracy znikły o czym z resztą Panu pisałem jak miałem tam jeszcze konto.

 

2. Każdy użytkownik sobie konfiguruje pocztę jak mu się podoba - to, że pan nie skonfigurował antyspamu to pana problem.

Widzę, że kompletnie Pan nie rozumie o czym ja piszę. Wyjaśnię może nieco bardziej łopatologicznie skoro inaczej się nie da. Pocztę skonfigurowałem prawidłowo, ustawiłem catch-all i teraz proszę mi wyjaśnić jakim cudem miałem zgadnąć, że jest włączony jakiś filtr który kłoci się z catch-all? A już fakt, iż maile zniknęły bezpowrotnie to żenada. Wg Pana miałem przeklikać całego cPanela szukając czy przypadkiem jakaś opcja może wejść w konflikt z ustawieniem catch-all? Jeśli tak to na to faktycznie nie wpadłem.

 

Pana problemy wynikają z pana ignorancji. Pozdrawiam.

Ja rozumiem, że to forum jest dla Pana źródłem klientów i dba Pan jak może o dobrą opinię ale ale mam wrażenie, że kompletnie nie czyta Pan tego co piszę i odpowiada gotowymi hasłami z BOK. Korzystałem z wielu różnych hostingów ale takich "ficzerów" jeszcze nigdzie nie spotkałem.

 

pozdrawiam...

[Prohost 345]

Skoro dostęp się wyłącza to jakim cudem mnie udało się wejść a przy próbie zapisu pojawiły się różne błędy. Efekty mojej pracy znikły o czym z resztą Panu pisałem jak miałem tam jeszcze konto.

 

 

Widzę, że kompletnie Pan nie rozumie o czym ja piszę. Wyjaśnię może nieco bardziej łopatologicznie skoro inaczej się nie da. Pocztę skonfigurowałem prawidłowo, ustawiłem catch-all i teraz proszę mi wyjaśnić jakim cudem miałem zgadnąć, że jest włączony jakiś filtr który kłoci się z catch-all? A już fakt, iż maile zniknęły bezpowrotnie to żenada. Wg Pana miałem przeklikać całego cPanela szukając czy przypadkiem jakaś opcja może wejść w konflikt z ustawieniem catch-all? Jeśli tak to na to faktycznie nie wpadłem.

 

 

Ja rozumiem, że to forum jest dla Pana źródłem klientów i dba Pan jak może o dobrą opinię ale ale mam wrażenie, że kompletnie nie czyta Pan tego co piszę i odpowiada gotowymi hasłami z BOK. Korzystałem z wielu różnych hostingów ale takich "ficzerów" jeszcze nigdzie nie spotkałem.

 

pozdrawiam...

 

1. Logiczne jest, że jak ktoś jest w cpanelu i odpala się update to po kliknięciu jakiejś opcji dostaje błąd. Nie wiem ile pan pracował nad tym ale wiele zniknąć nie mogło bo każdy klik daje błąd. Nie przesadzajmy.

 

2. Antywirus nie ma nic do ustawień poczty. To jest oddzielna opcja. Wszystkie filtry są wyłączone poza blokowaniem maili wysyłanych na nieistniejące adresy aby klienci nie płakali po kilku dniach, że nie mają miejsca na dysku bo spam się znalazł na głównym koncie. Dodatkowo jest ostrzeżenie, że jeśli jest włączony ten filtr to catch all nie działa. Proste.

 

Może pan nie odpisywać bo szkoda czasu - przyczepił się pan rzeczy które działają prawidłowo a swoje problemy ze zrozumieniem opisów funkcji czy też brakiem wiedzy na temat mysqla przypisuje "złemu" hostingowi.

[is_wm 287]

default = domyślnie != standard

 

Standard, w sensie, że używa go większość firm na rynku, a nie dlatego, że taka jest domyślna konfiguracja...

[Prohost 345]

default = domyślnie != standard

 

Standard, w sensie, że używa go większość firm na rynku, a nie dlatego, że taka jest domyślna konfiguracja...

 

Standard ustala organizacja do tego wyznaczona czy też producent produktu - w przypadku mysqla nie są to firmy używające go. Standardowym ustawieniem według mysql jest latin1 - jak podano w jej dokumentacji. To, że 50% używa latin1 a 50% używa latin2 nie zmienia faktu, że standardowym ustawieniem jest latin1.

[is_wm 287]

Czy naprawdę tak boli przyznanie się do błędu?

Standard - wspólnie ustalone kryterium, które określa powszechne, zwykle najbardziej pożądane cechy czegoś, np. wytwarzanego przedmiotu (np. standardem jest, że każdy współcześnie wytwarzany telewizor wyświetla kolory) czy ludzkiego zachowania (norma kulturowa).

Powtarzam, to że coś jest ustawione domyślnie, to wcale nie znaczy że jest to standardowe. 90% firm hostingowych w internecie ma UTF-8 w MySQL. Pewnie z 7% nie wie jak zmienić domyślne kodowanie, stąd ma latin1.

[Prohost 345]

Czy naprawdę tak boli przyznanie się do błędu?

 

Powtarzam, to że coś jest ustawione domyślnie, to wcale nie znaczy że jest to standardowe. 90% firm ma UTF-8 w MySQL.

 

Napisze inaczej - standardowym kodowaniem mysql według producenta mysql jest latin1. Jest to zrozumiałe? To, że ty możesz mieć swoje standardy to mnie nie interesuje. I nie ma sensu mówienie o standardzie i ustawieniu według polskich firm hostingowych bo nie ma takiego porozumienia i nie ma dokładnych danych przedstawiających kto czego używa. Nie ma takiego standardu w Polsce ani nigdzie na świecie. Ja przyjmuję jedyny oficjalny i znany z dokumentacji mysqla. EOT.

[Lan Hikari 3]

I mamy OT na całą stronę Przecież to logiczne, że jeśli nie podoba się kodowanie bazy u jednej firmy, bierzesz u innej w której jest takie które Ci odpowiada... Robicie problemy Każdy ma takie jakie mu i (zazwyczaj) klientom odpowiada Proste

[Prohost 345]

Domyślne kodowanie nawet nie ma znaczenia bo każda baza, każde pole w bazie może mieć ustawione inne kodowanie przez użytkownika. Ktoś kto potrzebuje konkretnego ustawienia sobie je zwyczajnie ustawi i nie będzie płakał, że domyślnie jest tak czy tak.

 

Cała strona OT to prawda.

[Gość nrm]

Standardowo używa latin1. Tak samo collation latin1_swedish_ci jest standardem.

Juz mnie ktoś ubiegł ale widzę, że trzeba podkreślić: mylisz pojęcia standard i domyślnie. latin1_swedish_ci NIE JEST standardem tak samo jak NIE JEST nim wincp1250

[Prohost 345]

Juz mnie ktoś ubiegł ale widzę, że trzeba podkreślić: mylisz pojęcia standard i domyślnie. latin1_swedish_ci NIE JEST standardem tak samo jak NIE JEST nim wincp1250

 

Nie ma przyjętego standardu w tej sprawie więc ich domyślne to dla mnie standard. Standard to szerokie pojęcie. I jaki sens ma dalszy OT?

[Gość nrm]

A dla mnie ziemia jest płaska i leży na 6 krokodylach.

Fakt, nie ma sensu.

[Prohost 345]

A dla mnie ziemia jest płaska i leży na 6 krokodylach.

Fakt, nie ma sensu.

 

Masz gdzieś aktualnego manuala potwierdzającego to?

[bukox 0]

1. Logiczne jest, że jak ktoś jest w cpanelu i odpala się update to po kliknięciu jakiejś opcji dostaje błąd. Nie wiem ile pan pracował nad tym ale wiele zniknąć nie mogło bo każdy klik daje błąd. Nie przesadzajmy.

 

Prawda jest taka, że aktualizacje oprogramowania powinny przebiegać tak aby w minimalnym stopniu utrudniać życie użytkownikom a z tego co czytam dla Pana jest zupełnie naturalne, że w środku dnia kiedy użytkownicy pracują dokonuje się aktualizacja, która uniemożliwia operacje a dodatkowe powoduje błędy. Gratuluje podejścia!

 

2. Antywirus nie ma nic do ustawień poczty. To jest oddzielna opcja. Wszystkie filtry są wyłączone poza blokowaniem maili wysyłanych na nieistniejące adresy aby klienci nie płakali po kilku dniach, że nie mają miejsca na dysku bo spam się znalazł na głównym koncie. Dodatkowo jest ostrzeżenie, że jeśli jest włączony ten filtr to catch all nie działa. Proste.

 

Jaki antywirus? O czym Pan pisze? A wracając do temu to nie było żadnego ostrzeżenia a poza tym, to nie catch-all nie działa ale filtr usuwa nieodwracalnie wszelkie maile które mimo ustawionej opcji catch-all powinny trafić do skrzynki. Dla mnie jest to ewidentny konflikt pomiędzy ustawieniami i nie wiem dlaczego Pan dalej brnie w zaparte. Nie wierzę, że ktokolwiek nieznający konfiguracji Pana systemu zgadł, że ustawiając catch-all trzeba jeszcze przeszukać filtry czy nie ma tam jakiejś "niespodzianki".

 

Może pan nie odpisywać bo szkoda czasu - przyczepił się pan rzeczy które działają prawidłowo a swoje problemy ze zrozumieniem opisów funkcji czy też brakiem wiedzy na temat mysqla przypisuje "złemu" hostingowi.

 

Szkoda Pana czy mojego czasu? Ja poświęciłem swój czas aby pokazać łagodnie mówiąc "niedoskonałości" Pana hostingu bo od tego jest to forum. Podsumowując uważam, że ma Pan źle skonfigurowany system a reakcją na słowa krytyki jest próba wytknięcia ignorancji i wymijające tłumaczenia. Może by tak po prostu zając się problemem i go rozwiązać?

 

pozdrawiam...

[Prohost 345]

W opisie catchall jest napisane, że włączony filtr no local powoduje nie działanie tej opcji, więc ja nie wiem o co panu chodzi. Wystarczy czytać. Każda opcja u nas jest opisana w panelu.

[Prohost 345]

Widać zaznaczone na czerwono?

 

A uaktualnienia oprogramowania robione są kiedy są potrzebne - już o tym pisałem. Straszna sprawa jak komuś 5 minut panel nie będzie działał. Naprawdę ludzie mają lepsze rzeczy do roboty niż czytać kilka razy w tygodniu spam na email, że 5 minut nie będzie działał bo upgrade robimy.

 

Pana opinia jest trochę śmieszna dla mnie - jest pan tak zbulwersowany czymś co jest normalne i jak już wcześniej pisałem wynika albo z pana niewiedzy albo niedoczytania opisu. Jeszcze takiego klienta to nie było u nas i raczej się cieszę, że nic pan u nas nie kupił bo jak pomyślę co mogło być dalej...

[bukox 0]

Nie będę wnikał kiedy zostało to dopisane bo o ile pamiętam niczego takiego tam nie było ale takie tłumaczenia są dla mnie śmieszne. Nadal upiera się Pan przy swoim i uważa, że tylko i wyłącznie Pan ma rację a Pana opinia to jedyna słuszna więc faktycznie dalsza dyskusja nie ma sensu.

 

Rozumiem, że dba Pan jak może o opinię na tym forum ale proszę mi uwierzyć, że powyższe tłumaczenia Panu nie pomogą. Jest Pan jednym z niewielu który broni własnego hostingu na tym forum co już może dawać do myślenia.

 

Kończąc ten wątek dodam tylko, że jeśli uważa Pan, że czepiam się czegoś "co jest normalne" to współczuję, bo proszę mi uwierzyć, że na konkurencyjnych hostingach opisane przez mnie sytuacje nie występują czyli więc to raczej u Pana jest nienormalna sytuacja.

 

pozdrawiam...

[Prohost 345]

Nie będę wnikał kiedy zostało to dopisane bo o ile pamiętam niczego takiego tam nie było ale takie tłumaczenia są dla mnie śmieszne. Nadal upiera się Pan przy swoim i uważa, że tylko i wyłącznie Pan ma rację a Pana opinia to jedyna słuszna więc faktycznie dalsza dyskusja nie ma sensu.

 

Rozumiem, że dba Pan jak może o opinię na tym forum ale proszę mi uwierzyć, że powyższe tłumaczenia Panu nie pomogą. Jest Pan jednym z niewielu który broni własnego hostingu na tym forum co już może dawać do myślenia.

 

Kończąc ten wątek dodam tylko, że jeśli uważa Pan, że czepiam się czegoś "co jest normalne" to współczuję, bo proszę mi uwierzyć, że na konkurencyjnych hostingach opisane przez mnie sytuacje nie występują czyli więc to raczej u Pana jest nienormalna sytuacja.

 

pozdrawiam...

 

Wcześniej już ktoś panu napisał, że opinia oparta na pierdołach.

Jedno z ostrzeżeń jest oryginalnie w tej opcji od zawsze, a drugie było przez nas dodane.

 

Podsumowując:

1. Mysql - brak problemu.

2. Catchall - nie przeczytał pan opisu.

3. Update cpanela - to nie pan decyduje kiedy jest on potrzebny - to ADMINISTRATOR o tym decyduje zgodnie z aktualnymi potrzebami. Jak jest potrzeba to się nawet wszystkie serwery wyłącza. Nie tak dawno kei i inne firmy używające pewnego kernela w środku dnia wyłączały serwery bo była taka potrzeba aby zachować poziom usług. Ale pan wie lepiej.

 

Nie wiem o czym my tu rozmawiamy. I nie muszę dbać na tym forum o opinię. Generalnie jest ono źródłem klientów dla bardzo tanich hostingów i większość hostingów się tu nie wypowiada. Piszę bo lubię, a jak ktoś pisze pierdoły to odpowiadam. Jakoś nikt nie zgłasza takich problemów jak pan bo one nie istnieją - a mam dostęp do naszego helpdeska i logów czata. Widzę jaki kto ma problem. Cały czas wprowadzamy udogodnienia dla użytkowników i opcje które są rzadko dostępne u innych. Wspomnę chociaż o całodobowym Czacie, helpdesku z czasem odpowiedzi średnim do 5 minut, Litespeed, monitoring kont pod względem nieautoryzowanego dostępu, logach użycia cpu, logach antyspamu czy slow logach mysql. Ale nic nie poradzimy na to, że ktoś nie przeczyta zanim kliknie. Pozdrawiam.

[Gość Łukasz Tkacz]

Rozumiem, że dba Pan jak może o opinię na tym forum ale proszę mi uwierzyć, że powyższe tłumaczenia Panu nie pomogą. Jest Pan jednym z niewielu który broni własnego hostingu na tym forum co już może dawać do myślenia.

 

Jako klient posiadający już ponad rok konto w prohost skomentuję to w taki oto sposób (co zarazem jest oceną):

 

Cały czas wprowadzamy udogodnienia dla użytkowników i opcje które są rzadko dostępne u innych. Wspomnę chociaż o całodobowym Czacie, helpdesku z czasem odpowiedzi średnim do 5 minut, Litespeed, monitoring kont pod względem nieautoryzowanego dostępu, logach użycia cpu, logach antyspamu czy slow logach mysql. Ale nic nie poradzimy na to, że ktoś nie przeczyta zanim kliknie. Pozdrawiam.

 

Sama prawda, nie ma się do czego przyczepić.

 

Zresztą, jeżeli ktoś ma jakiś problem, to może napisać do helpdesku albo na czacie - sprawdzałem kiedyś z ciekawości, i nawet o 3 w nocy nie ma problemu aby uzyskać natychmiastową pomoc, czego rzeczywiście próżno szukać gdzie indziej. Choć z drugiej strony... cPanel to kombajn o niesamowitych możliwościach prosty w obsłudze jak cep (do tego opisane po polsku).