Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
bud to bylo malo bezpecne, nebo neprosel temer zadny mail
když z X příspěvků, které dokládají cos tvrdil, vytáhnu jen jeden, tak že se ho budeš snažit takhle překrucovat.Když z X příspěvků, kde jsem údajně něco tvrdil, vytáhnete zrovna jeden, kde jsem to netvrdil, je to argument celkem k ničemu.
Ti fakt není blbé se takto přiznávat, že pro Tebe není relevantní, co jsi tvrdil, ale na co si oponent v diskusi vzpomene, že jsi tvrdil a připomene Ti to?Naopak, pro mne je relevantní to, co jsem doopravdy tvrdil. To, že vy si vzpomínáte na něco, co se vůbec nestalo, je váš problém. Až se místo vašich vidin začnete zabývat tím, co doopravdy píšu, můžeme pokračovat. Zatím to nemá smysl, protože vaše odpovědi jsou zřejmě zcela nezávislé na tom, co já píšu.
O lokálním serveru jsi mluvil všehovšudy v jednom příspěvkuKterý jste vy citoval. Za to já opravdu nemůžu, nenutil jsem vás k tomu.
Naprosto jednoznačně popíráš možnost, že by mohla nastat situace, kdy spojení není třeba navazovat.Opět si vymýšlíte.
Víš, jak se pozná demagog? Že vytrhává a překrucuje věty z kontextu diskuse.Ano, vím. Nejen teoreticky, vy jste přímo ukázkový příklad.
Což jsi právě předvedl: vytrhl jsi jednu svojí větu z kontextu a snažíš se na jejím základě tvrdit, žes tvrdil něco jiného nežs tvrdil.Takže já jsem vytrhl jednu svojí větu z kontextu, citoval jsem ji, polemizoval s ní, a pak to celé poslal vaším jménem? Není to spíš tak, že příspěvek z 26. 10. 2014, 18:31:10, u kterého je jako autor uvedeno "Logik", jste psal vy?
To jsi ještě furt nepochopil, že ty otevřené konexe mohou mít krátký čas života a tedy být jen pro těch pár uživatelů, u kterých právě dochází k hodně requestům a tedy je třeba u nich výkon řešit???My tady ale neřešíme případ, kdy webhoster má na jednom serveru pár webů, které server dost vytěžují, a pak další weby, na které se sem tam někdo zeptá. Tazatel, já a pár dalších lidí (vy ne) řeší případ, kdy je tazatel uživatelem sdíleného webhostingu, a chce aby jeho aplikace odpovídala na požadavek co nejrychleji, bez ohledu na to, jestli je to jeden požadavek za hodinu nebo jestli přichází jeden požadavek za druhým. Tazatel neřeší zátěž serveru ale dobu odezvy.
Jo, a dost lidí tady vysvětlovalo, proč to rychlejší nebudeOdkaz nebude, že? Protože to nevysvětloval nikdo, pouze vy jste vysvětlil, že vaše úplně jiné řešení bude pomalejší.
Co jiného než otevřený pool databázových spojení (aneb konexí) jsou..."Otevřený pool databázových spojení" je něco jiného než "[pro uživatele] připravený pool otevřených databázových spojení k MySQL databázi na lokálním serveru".
pokud považuješ mé PHP řešení za nefektivní, napiš lepší.To lepší řešení už tu bylo popsáno několikrát, dávno před tím, než jste napsal to vaše.
Jinak samozřejmě řešení v MySQL je daleko k optimu (nebyla nijak instalace vyladěná, nepoužil jsem např. memory engine atd...Jistě, na sdíleném webhostingu si každý může vyladit parametry databázového serveru podle sebe...
Naschvál jsem si předtím dal práci, aby vypsaná tvrzení byla přesně doložitelná tím, co jsi psalVýborně. Proč je tedy nedoložíte? Proč místo toho dokládáte, že já jsem napsal něco jiného, než co vy tvrdíte, že jsem napsal? Třeba "[pro uživatele] připravený pool otevřených databázových spojení k MySQL databázi na lokálním serveru" je něco jiného, než "sdílené konexe" (už jenom proto, že "sdílené konexe" není nic).
Jakto?Protože se tazatel ptal, jak nejlépe na sdíleném webhostingu blokovat přístup z určitých IP adres. To, že se to mermomocí musí řešit pomocí databáze nebo dokonce relační SQL databáze nebylo součástí zadání.
Implementace, kterou jste navrhoval vy.Nikoli. Já jsem psal o indexu uloženém v souboru, psal jsem také o tom, že ten index může být implementován úplně stejně, jako je v té databázi. Mohu vás ujistit, že MySQL neindexuje IP adresy tak, že si je neseřazené uloží v dekadickém zápisu do souboru, co řádek to jedna IP adresa.
Takze uz od zacatku se zde resi MySQL databaze, ktera ukladani a vyhledavani dat bude mit reseno mnohem efektivneji, nez jste schopen v php napsat (parsovani gramatiky ma nejakou rezii, vime?)Ne, tady se nebavíme o žádné databázi. Tady se bavíme o vyhledávání IPv4 adres. IPv4 adresa, to je jedno 32bitové číslo, v souboru zapsané jako čtyři po sobě jdoucí bajty. Pokud to chcete popisovat gramatikou a psát na to speciální parser, nikdo vám samozřejmě nebrání, ale je to zbytečné. Takže když odstraníte tu zbytečnou režii, kterou tam sám přidáváte, dostanete efektivnější řešení.
Zde se uplatni i vase "cache operacniho systemu", soubor je porad nejpomalejsi.Nejpomalejší to ovšem není z toho důvodu, že se používá soubor, ale z toho důvodu, že je to nejhloupější možná implementace.
Tomu se neříká diskuse, ale demagogie.Tohle je jediná pravdivá věta z vašeho komentáře. Své komentáře jste ohodnotil správně. A proč je to demagogie? Protože píšete, že tvrdím něco, co jsem nikdy nenapsal, nebo tvrdíte, že jste ukázal praktický test, který dokazuje vaše tvrzení, přitom ve skutečnosti dokazuje jenom to, že nevíte, o čem je řeč.
Keď tu začnem pastovať CVE-čka k linuxovému jadru, bude z toho vyplývať, že hosting sa nedá zabezpečiť nad servermi s Linuxom?Já jsem neodkazoval na jen tak nějaká náhodně vybraná CVE, ale na ta, která popírají, že PHP umí oddělit uživatele i bez oddělených systémových účtů.
Aby si ľudia nevideli súbory, na to je v PHP open_basedir. Je potrebné sa trochu pohrať s konfiguráciou a zakázať niektoré funkcie, ale tie by si musel zakázať aj pri CGI. Tvoj predpoklad, že sa to nedá, je jednoducho mylný.Můj názor je, že tímto způsobem se to bezpečně udělat nedá. Musíte zakázat některé funkce – opravdu si si vzpomenete úplně na všechny? A kontrolujete to s každou aktualizací? Pak se rozhodnete, že zákazníkům povolíte cron, nebo vedle FTP i SSH, nebo cokoli jiného – a budete vše znovu kontrolovat, zda neexistuje nějaká kombinace, jak to obejít? Pro řízení přístupu k souborům jsou určena přístupová práva na úrovni operačního systému, operační systém to hlídá a dělá to dobře. Nevěřím tomu, že to PHP dělá stejně dobře.
Přinejmenším některé hostingy pravděpodobně mod_php používají.On už umí mod_php fungovat v režimu suExec, tedy že se pro každý požadavek změní efektivní UID na daného uživatele? Nebo "sdílený webhosting" znamená, že zákazníci spolu sdílí i všechna data a skripty?
jaksi i v jakémkoli *CGI módu (mimo samotný CGI) normálně persistentní konexe fungujíTo, že je něco technicky proveditelné, je to zapnuté, a prakticky se to použije, jsou tři různé věci. To má ten sdílený webhosting v poolu navázaná spojení pro všechny uživatele? Nebo má navázaná anonymní spojení, která se musí při každém požadavku přihlásit?
Co kdybys místo mlžení se snažil říci nějaká fakta (např. většina sdílených hostingů používá technologii XY, ve které nefungují persistentní konexe protože YZ).Co používá většina sdílených hostingů je celkem jedno. I kdyby měl ten hosting v poolu navázaná spojení do databáze, která už prošla autentizací, pořád musíte poslat do databáze požadavek (nejspíš po síti), databáze jej musí rozparsovat, vyhledat v indexu, vrátit odpověď (opět nejspíš po síti), klient musí vytáhnout data z odpovědi - a má výsledek. Když to porovnáte s řešením bez databáze (vyhledat v indexu a má výsledek), zjistíte, že řešení s databází dělá všechno, co řešení bez databáze, a k tomu ještě spoustu dalších věcí. Které se zkrátka nestihnou udělat v nulovém čase.
Že to bude jako v tom vláknu o autorských právech - v okamžiku, kdy jsem od Tebe chtěl jasné vyjádření, z kterého by bylo jasně vidět, jaké tvrdíš blbiny, taks po pár pokusech se odpovědi vyhnout jsi z diskuse zmizel.Chcete diskutovat o tématu, nebo si chcete vymýšlet báchorky?
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
