Bylo oznámeno vydání Fedora Linuxu 44. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách
… více »David Malcolm se na blogu vývojářů Red Hatu rozepsal o vybraných novinkách v GCC 16, jež by mělo vyjít v nejbližších dnech. Vypíchnuta jsou vylepšení čitelnosti chybových zpráv v C++, aktualizovaný SARIF (Static Analysis Results Interchange Format) výstup a nová volba experimental-html v HTML výstupu.
Byla vydána verze R14.1.6 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Jon Seager z Canonicalu včera na Ubuntu Community Hubu popsal budoucnost AI v Ubuntu. Dnes upřesnil: AI nástroje budou k dispozici jako Snap balíčky, vždy je může uživatel odinstalovat. Ve výchozím nastavení budou všechny AI nástroje používat lokální AI modely.
Nový ovladač Steam Controller jde do prodeje 4. května. Cena je 99 eur.
Greg Kroah-Hartman začal používat AI asistenta pojmenovaného gkh_clanker_t1000. V commitech se objevuje "Assisted-by: gkh_clanker_t1000". Na social.kernel.org publikoval jeho fotografii. Jedná se o Framework Desktop s AMD Ryzen AI Max a lokální LLM.
Ubuntu 26.10 bude Stonking Stingray (úžasný rejnok).
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.3.0. S experimentální podporou FLTK 1.4. S příkazem dilloc pro ovládání prohlížeče z příkazové řádky. Vývoj prohlížeče se přesunul z GitHubu na vlastní doménu dillo-browser.org (Git).
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Vývojáři v přehledu vypíchli vylepšenou instalaci, podporu senzoru okolního světla, úsporu energie, opravy Bluetooth nebo zlepšení audia. Vývoj lze podpořit na Open Collective a GitHub Sponsors.
raylib (Wikipedie), tj. multiplatformní open-source knihovna pro vývoj grafických aplikací a her, byla vydána ve verzi 6.0.
Ahoj,
resim takovou blbinu.
Mam skript na parsrovani veci z textaku a insertuju to - pod Widlema (XP) PHPkem (5.3) do PostgreSQL (8.2). V pohode to jede, ale po nekolika minutach to skonci s touto hlaskou:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, admin@local.domain and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
V error logu je neco takoveho:
Premature end of script headers: php-cgi.exe, referer: http://127.0.0.1/iskn/upload.form.php
Server status v PgAdmin III mi hlasi tohle:
LOG could not receive data from client: Unknown winsock error 10061
LOG incomplete startup packet
Zajimave je, ze kdyz tohle spustim na Linuxu (FC 8), tak vse jede OK. Strejda Google mi neprozradil nic co by mi pomohlo, tak se panove obracim na Vas. Predpokladam, ze by mohl byt problem v tom, ze mam pokazde jinou instalaci Apache a jinej konfigurak php.ini, ale v tom az tak zbehly nejsem.
Dik za odpoved.
Na Win pouzivam FF stejne jako na Lin., ale asi to bude tak jak rikas. Skript funguje tak, ze se nahraje docasny soubor a pak se zavola funkce na parsrovani a inserty do DB. Trvale ukladat soubor na disk nechci (nemusim se starat o mazani). S PHP se teprve ucim, co myslis tim, ze: "PHP skript lze spouštět i jinak než z prohlížeče, pokud je potřeba :) Tedy pokud je to tento případ." ? Nevim jak jinak to vyresit, aby browser necekal na vysledek skriptu.
Nevim jak jinak to vyresit, aby browser necekal na vysledek skriptu.Tento problém řeším tak, že soubor určený ke zpracování nechám uložit na disk (nebo do databáze apod.) a uživatel si dál může dělat co chce (třeba sledovat průběh zpracování pomocí nějakého pěkného AJAXu). Vedle toho běží program, který tyto soubory zpracovává. Tento program může být buď neustále spouštěn z cronu, nebo běžet jako démon a v nějakých intervalech kontrolovat, zda se objevil soubor pro zpracování.
Aha, ..., a naka jina moznost by nebyla? Neco jako preruseni vlakna nebo to udelat nak per partes ... ? Kdyz to hodim nekam na hosting, tak si nemuzu dovolit instalovat programy jaky chcu. Musi to byt co nejvice uzivatelsky bezproblemove. Nahraju skripty, nastavim pripojeni k DB a ficim.
Tak jsem tam dodelal echo pri kazdem vytvoreni tabulky a jede to o neco dele, ale skonci to touto hlaskou:
(70007)The timeout specified has expired: ap_content_length_filter: apr_bucket_read() failed, referer: http://127.0.0.1/iskn/upload.form.php
Napada nekoho co s tim? Chapu, ze skript bezi asi moc dlouho, ale mam v php.ini nastaveno max_execution_time: 1600 a porad to stejne do 15min zdechne. Nevim, jestli je rozumne prilis protahovat cas, ale na druhou stranu jak vyresit tento problem?
je to vymenny format exportu z databaze. cca 600 000 radku. Textak ma 90 MB. Je potreba to udelat webove. Ted to zkousim narvat po radcich do DB, tak jak to lezi a bezi a vytvorim nakou interni funkci v PL/pgSQL kterou to vysekam a narvu do tabulek. Myslim si, ze to bude podstatne rychlejsi nez PHPkem. Mel jsem to udelat driv, ale to me se nechtelo. :-]. Nechapu, ze na Linuxu mi to jede uplne v pohode. Sedim tu u toho uz nejmin pul hodiny a inserty v pohode jedou. Na widlich mi to po asi 10-15 min zkolabuje. Asi to bude naky nastaveni Apache nebo php.ini nebo nevim co.
Indexaci jsem vubec neresil. Tim importem zakladam novou databazi, tabulky a rvu do toho data. Teprve potom jsem chtel delat indexaci. Takovy blazen nejsem, abych rval 600 000 zaznamu do indexovanych tabulek. Vice radku v jednom insertu mam, ale ta transakce me nenapadla-dik za tip. Rozhodne prostor pro optimalizace tu je (vcetne interni PL/pgSQL funkce), ale to neresi muj problem. Proc to na Linuxu jede a widlich ne. Co mam kde blbe nebo co se deje. Ted se mi to treba povede zoptimalizovat, ze se to "stihne" do tech 15 min nez mi zarve skript na widlich, ale co kdyz nakej blazen udela jeste vetsi export z databaze? - coz vzhledem k tomu jak je napapana neni problem.
Tiskni
Sdílej: