Byla vydána (Mastodon, 𝕏) vývojová verze 3.1.4 příští stabilní verze 3.2 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání.
Zakladatel ChimeraOS představil další linuxovou distribuci zaměřenou na hráče počítačových her. Kazeta je linuxová distribuce inspirována herními konzolemi z 90. let. Pro hraní hry je potřeba vložit paměťové médium s danou hrou. Doporučeny jsou SD karty.
Komunita kolem Linuxu From Scratch (LFS) vydala Linux From Scratch 12.4 a Linux From Scratch 12.4 se systemd. Nové verze knih s návody na instalaci vlastního linuxového systému ze zdrojových kódů přichází s Glibc 2.42, Binutils 2.45 a Linuxem 6.15.1. Současně bylo oznámeno vydání verze 12.4 knih Beyond Linux From Scratch (BLFS) a Beyond Linux From Scratch se systemd.
Organizátoři konference LinuxDays ukončili veřejné přihlašování přednášek. Teď je na vás, abyste vybrali nejlepší témata, která na letošní konferenci zaznějí. Hlasovat můžete do neděle 7. září. Poté podle výsledků hlasování organizátoři sestaví program pro letošní ročník. Konference proběhne 4. a 5. října v Praze.
Byla vydána verze 11.0.0 vizuálního programovacího jazyka Snap! (Wikipedie) inspirovaného jazykem Scratch (Wikipedie). Přehled novinek na GitHubu.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma. Vypíchnout lze, že v Plasmě byl implementován 22letý požadavek. Historie schránky nově umožňuje ohvězdičkovat vybrané položky a mít k ním trvalý a snadný přístup.
Wayfire, kompozitní správce oken běžící nad Waylandem a využívající wlroots, byl vydán ve verzi 0.10.0. Zdrojové kódy jsou k dispozici na GitHubu. Videoukázky na YouTube.
Před necelými čtyřmi měsíci byl Steven Deobald jmenován novým výkonným ředitelem GNOME Foundation. Včera skončil, protože "nebyl pro tuto roli v tento čas ten pravý".
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 156 (pdf).
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 25.8.1. Přehled novinek v Changelogu.
No nevím, takové RubyOnRails jsem ještě na Apachi neviděl (pokud není Apache použit jen jako reverzní proxy a na statický obsah). U TurboGears je tohle řešení (Apache jako reverzní proxy) taky myslím oficiální dokumentované a to už mi přijde o dost rozumější na takovýhle úkol použít lighttpd nebo nginx. Docela jsem se o tohle zajímal (chtěl jsem mít všechno po kupě s Apachem) a vím, že k Apachi to nijak zvlášť přátelské není (respektive jde to, ale v takové podobě, že jestli je tam Apache nebo něco 100x menšího, tak to nejde poznat). Hmm.
Jde mi o to, že v některých předchozích článcích jsem tu řešil. jak mít všechno "pod jednou střechou" - chci, aby se aplikace (ať už PHP, nebo Python nebo Ruby) každého klienta spouštěly pod jeho UID/GID a pak nebyla nutná různá složitá zabezpečovací řešení. K čemuž se FastCGI použít dá, ale nedá se konfigurovat z databáze nebo nějak dynamicky, jako třeba mod_ruid (o tom je taky na blogu nebo v předchozích zápiscích, nejsme si jistý, kdyžtak to najdete googlem). S lighttpd to jde AFAIK napíchnout na MySQL, nejsem si jistý. Neříkám, že něco nejde, ale pokud budete mít Apache + *CGI, tak kde je ten rozdíl proti nginxu nebo lighttpd (které jsou podle benchmarků rychlejší a žerou méně RAM)?
No, třeba se přes FastCGI dá ovlivnit, s jakým UID/GID ta spouštěná aplikace pojede - můžete pro každého klienta nastavit zvlášť. FastCGI je v tomhle ohledu lepší a univerzálnější, řekl bych.
Jak můžu i HTTP aplikace ovlivnit (ve sdíleném prostředí, kdy jeden webserver obsluhuje více hostů, které mají být odděleny) za jaký UID/GID se bude spouštět? U Apache třeba pomocí mod_ruid, u jiných webserverů nevím, reverzní proxy s tím nemá co dělat. Takže to není ani trochu stejné, jestli budete z webserveru posílat požadavky přes FastCGI nebo jako reverzní proxy - v případě FastCGI můžete ovlivnit věci, které s reverzní proxy ovlivnit nemůžete. A myslím, že v tom mám dost jasno na to, abyste mi neodpovídal "LOL" :/
Hmm :/ Já opravdu stojím o komentáře a diskusi, jen mám pocit, že kvůli tomu, že jsem napsal blogpost ve stylu, který vám nesedne, se ze mě snažíte udělat blba, což není příjemné asi nikomu, i když máte samozřejmě ve většíně věcí pravdu (nejsou ale v rozporu s tím, co jsem psal v postu). A ke konkrétnímu případu - spouštět Apache pod speifickým uživatelem Vám přijde efektivní? Tak, aby se nepřemnožil a zároveň zvládal vykrýt requesty, by to bylo vážně dost těžké (protože si vydržuje pro každou instanci nějaký počet procesů == zbyteně vyplýtvaná RAM). I pro menší webservery (lighttpd je to plýtvání ve srovnání s tím, jak je efektivní řešení s FastCGI, které udělá suid až potom, co mu přidje request a webserver mu oznámí, na jaké uid:gid má ten suid udělat. V případě nginxu to beru, ten je tak malý, že tyhle funkce nepotřebuje a můžete si jich pustit v systému dostatek bez toho, aby to mělo podobný efekt jako s Apachem. Já ten nadpis snad kvůli Vám ještě přepíšu :D
Ale já nechtěl jen reverse proxy. "Bulvární" nadpis možná trochu je, původně to bylo v mém blogu, kde si toho dovoluju víc (protože to nikdo nečte), ale prostě to tak je, no. A že bych nevěděl, co si vybrat ... tak to taky nebylo. Ten server už běží delší dobu, nginx je záležitost poměrně nová, řešení s pouze reverzní proxy (Pound) bylo náročnější než řešení s reverzní cachovací proxy, takže tady bych s Vámi dost nesouhlasil ... aneb, ne, já vím, co chci :)
Ale já jsem se vůbec Squid shazovat nesnažil, ach jo. Jen jsem měl radost, že se mi podařilo rozjet řešení, které není tak obecně použitelné, jako je squid (protože musíte provádět nějakou tu magii s documentrooty) a chtěl jsem se o to podělit. Ale pokud už do sebe rýpeme, tak bych Vám doporučil se mrknout na stránky Varnishe, protože tam se o Squidu dost mluví a také o tom, k čemu byl a nebyl udělaný - Squid jako reverzní proxy primárně dělán nebyl a neodvádí jako reverzní (a to ani cachovací) proxy tu nejlepší práci. Ale to jen na okraj.
Lidi (klienti) jsou zvyklí na Apache, tím myslím především jeho rewrite. I já bych byl trochu naštvaný, když bych nainstaloval redakční systém s nachystaným .htaccess pro Apache, aby fungovali SEF (Search Engine Friendly) URL a ono to nejelo. A další věci na to jsou navázané. Ale máte pravdu, kdybych nedělal mass hosting, ale jenom nějaký jeden specifický projekt, tak bych Apache už asi nepoužil.
Jak jinak než rewritem chcete řešit Search Engine Friendly URLs (třeba to co je vidět tady na Ábíčku, ale v PHP aplikacích na Apachi)?
A co když je na stránce galerie s 25 obrázky po 30kB – uživatel začne načítat stránku a … buď je najednou server zahlcen (málo RAM), nebo se nedostává na ostatní uživatele, nebo se stránka zase pomalu načítá tomu jednomuSlušní weboví klienti (prohlížeče, proxy, roboti) mají nastaven limit pro maximální počet souběžných spojení k jednomu hostname, který se zpravidla pohybuje v řádu jednotek (např. můj Firefox má nastaveno 8, což je u něj výchozí hodnota). Může být nastaven vyšší limit pro persistentní spojení (u mne je nastaveno 12), což u modelu process-per-connection může trochu vadit, protože ten proces musí existovat, i když zrovna nic nedělá. Jetty s SelectChannelConnectorem tohle umí řešit tak, že spojení, které je otevřené, ale nic se na něm zrovna neděje, nemá přiřazené ani svoje vlákno, takže těch prostředků vázaných takovým spojením je opravdu minimum. Taky předpokládám, že většina paměti, kterou zabírají procesy Apache, je ve skutečnosti sdílená paměť – kód Apache a případně modulů. Takže by to s tou žravostí paměti nemělo být zas tak špatné.
No nevím, rozhodně když porovnám paměťovou náročnost situací "pouze Apache", "Apache+Squid" a "Apache+Nginx", tak z toho první vychází nejhůř a poslední nejlíp. Co dělají slušní klienti je jedna věc, druhá je, že na různých tunerských stránkách jsou tipy na zrychlení načítání stránek založené právě na zvyšování těchhle hodnot. Ale zas tak moc jsem to nezkoumal, vím jen, že ve srovnání s řešením přes squid mám teď místo loadu 0.3-0.5 asi 0.02-0.1.
Jo, místo Squidu už jsem poměrně dlouhou dobu používal Varnish, rozdíl značný a problémy popisované v blogu taky úplně neřešil (neříkám, že jsem to od něj čekal, neshazuju cachovací reverzní proxy, prostě to bylo řešení, které jsem použil - to abyste mě zas neobviňoval...). Apache s nginx a bez budu moct brzo otestovat (přijde nový server, takže si budu mít s čím hrát), ale už jen když se nad tím zamyslím, tak by to dávalo docela smysl, ne? Navíc testování v lokální síti, kde přenos větších souborů bude řádově rychlejší (tedy bude muset viset méně procesů Apache) taky úplně neodpovídá reálnému provozu, takže nevím, jak to objektivně otestovat, ale co už ...
Jisté ale je to, že když mám Apache MPM Prefork (což musím mít kvůli mod_ruid a PHP) a _jeden_ proces Apache už bere sám o sobě asi 20x víc než proces nginxu (který se nedělí), tak to bude paměťově mnohem náročnější (pouze Apache) a výpočetně určitě taky (vytvoření procesu a jeho zánik je - i když nejsem ani trochu expert - myslím docela náročné, ne?). Nemám pravdu?
Na webu nginxu tuším nějaké je, vychází to pokud vím přibližně na stejno, v blogu jakéhosi člověka jsem četl, že lighttpd leakuje a má dost bezpečnostních problémů (což je pravda, ale opravují je).
Ale určitě, proto taky jásám nad tím, že jsem mohl odstranit Squid/Varnish a nahradit je nginxem, což si myslím že je už jen z hldiska návrhu lepší řešení. Apache je pořád v mém systému nenahraditelný a prozatím tam zůstane a na něj taky nenadávám ... :)
A abychto ještě upřesnil, já nenadávám ani na reverzní cachovací proxy, vyřešila dočasně můj problém, prostě ne ideálně a teď to (myslím) ideální je. Takže ten příspěvek je vpodstatě jen o těch pár posledních odstavcích (hlavně ten konfigurák :D), aby se z toho mohl někdo (až dospěje do podobné situace) poučit. Díky za pochopení :)
Tiskni
Sdílej: