Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
Spouštět webový prohlížeč jenom kvůli nákupu kávy? Nestačí ssh? Stačí: ssh terminal.shop (𝕏).
Yocto Project byl vydán ve verzi 5.0. Její kódové jméno je Scarthgap. Yocto Project usnadňuje vývoj vestavěných (embedded) linuxových systémů na míru konkrétním zařízením. Cílem projektu je nabídnou vývojářům vše potřebné. Jedná se o projekt Linux Foundation.
Vyšel Linux 2.6.31 (LKML). ChangeLog má přes 7,3 MiB. Kromě jiného byla přidána podpora USB 3.0, CUSE (ekvivalent FUSE pro znaková zařízení), IEEE 802.15.4, NFS 4.1. Vylepšená správa paměti přispívá k lepší odezvě desktopu. Více na Kernel Newbies.
Tiskni Sdílej:
Podla mna je to cele o tomto povodnone povazovanom za nezmysel
Síťové ovladače již nějaký čas používají čím dál tím hůře pojmenované rozhraní NAPI („nové API“). NAPI umožňuje síťovému ovladači vypnout přerušení od rozhraní a přejít do dotazovacího [polling] režimu. Dotazování je obecně považováno za špatnou věc, ale problém je to ve skutečnosti jenom v případě, když dotaz nezjistí žádnou užitečnou práci. U vytíženého síťového rozhraní vždy budou nějaké pakety, které je potřeba zpracovat, takže „dotazovat se“ v tomto případě znamená „pustit se do vyřízení nahromaděné práce“. A když je vždy nějaká práce, přerušení informující systém o tomto faktu jsou jenom šumem navíc. Jonathan Corbet, autor tohoto článku, rád takovou situaci přirovnává k upozornění na nový e-mail; každý, kdo dostává větší množství e-mailů, takové upozorňování pravděpodobně vypne. Ruší a když se dotyčný dostane k tomu, aby se podíval do pošty, pravděpodobně vždycky nějaký nový e-mail najde.
http://www.abclinuxu.cz/clanky/jaderne-noviny/jaderne-noviny-12.-8.-2009
Ten benchmark nebyl k desktopu zrovna fér
To je to na co jsem se ptal níže, já taky používám openSUSE a dost by se mi líbilo, kdyby mi instalátor dal vybrat, ideálně s krátkým popisem, co která volba znamená, tj. jedno vhodné pro server/nižní interaktivita, druhé pro desktop/nižší výkon serverových aplikací.
Jenže v dnešní době pitomých syntetických benchmarků, kdy např. Phoronix porovnává distribuce podle výkonu a to testy, které jsou normálnímu uživateli uplně ukradené to vidím dost bledě. Prostě co na tom, že kliknete na menu a ono se 3s nic neděje, hlavně že to udělalo o 1000 dotazů do databáze (kterou nikdy nepoužijete) více.
Myslim si, ze toto(patchovanie kernelu pri boote ) je riesenie...
LWN: Thomas mi jednou říkal o schématu, ve kterém by se rtmutexy patchovaly do/z běžícího jádra během bootu, což by distributorům umožnilo dodávat jediné jádro, které by mohlo běžet buď v realtimovém, nebo "normáním" režimu. Je to stále něco, na čem pracujete?
Hlavním myšlenka Ksplice zůstává stejná: když je mu dán strom zdrojových kódů a patch, přeloží jádro jak s, tak bez patche a hledá rozdíly. Za tímto účelem je postup při překladu modifikován tak, aby každá funkce a datová struktura byly ve své vlastní spustitelné sekci. To je pro překladač a linker poněkud obtížnější, ale vývojáři jsou na potíže, které těmto nástrojům způsobí, výrazně necitliví. Když jsou věci takto rozděleny, je relativně jednoduché identifikovat minimální sadu změn v binárním obrazu jádra, kterou patch způsobí. S trochou opatrnosti potom Ksplice může patchovat nový kód do běžícího jádra. Když je to dokončeno, staré jádro používá nový kód bez nutnosti rebootu.
http://www.abclinuxu.cz/clanky/jaderne-noviny/jaderne-noviny-26.-11.-2008
To stoji za vyskusanie, z popisu to vyzera, ako revolucia v Linux desktope a zeby sa konecne Linux vyrovnal vo vykone GUI Windowsu?Ano. Opravdu. Za posledních 10 let v Linuxu nebylo nic revolučnějšího. Ach jo. Je vůbec něco na co scheduler není lékem? A nebo už by se spíš měl jít někdo konečně léčit?
Ty Ingovy benchmarky jsou zcela zcestnéV čem vlastně? Nepokrývají sice všechny situace (a interaktivitu měří asi jenom pipe benchmark), ale jasně ukazují, že existují případy (a na desktopu mohou bez problémů nastat), ve kterých BFS naprosto propadne. Napsat scheduler, který je někdy lepší a někdy výrazně horší než defaultní, není žádné velké umění. Zato napsat takový, který interaktivní odezvu zlepší a nic dalšího podstatně nezhorší (řekněme jenom o procenta) ...
Pointa je v tom, ze BFS obetuje vykon ve prospech nizsi latence.
Cili kompilace kernelu nutne vyjde hure (tim spise na NUMA procesorech, na krete BFS nebyl psan), ale rychlost desktopu ma byt (a dle odezev tady i je) vyssi. Tohle ale uz nemuzes benchmarkovat.
Tohle ale uz nemuzes benchmarkovat.Jistě že ne. "Nainstaloval jsem si jiný plánovač a hned mám pocit, že máš všechno rychlejší odezvu", se benchmarkuje opravdu špatně.
Pointa je v tom, ze BFS obetuje vykon ve prospech nizsi latence.Jenže Ingovy testy jasně ukazují, že toho výkonu jednak obětuje strašně moc (ne jednotky procent, ale často desítky) a druhak že latenci v některých případech uškodí. Osobně BFS považuji spíš za šťouchanec, který může schedulerové hackery upozornit na to, že některé věci lze dělat ještě lépe, než za použitelný scheduler.
Tohle ale uz nemuzes benchmarkovat.Proč bych nemohl? Latence přeci je objektivně měřitelná veličina.
Zkousel jste to nekdo na Gentoo a gentoo-sources-2.6.31? Me se ten patch moc nedari aplikovat
biohazard linux # patch -p1 < /home/jirka/download/2.6.31-sched-bfs-211.patch
patching file Documentation/sysctl/kernel.txt
patching file fs/pipe.c
patching file include/linux/init_task.h
patching file include/linux/sched.h
patching file kernel/sched.c
patching file kernel/sysctl.c
Hunk #3 succeeded at 259 (offset 18 lines).
Hunk #4 succeeded at 692 (offset 18 lines).
patching file kernel/workqueue.c
patching file kernel/sched_fair.c
patching file kernel/sched_idletask.c
patching file kernel/sched_rt.c
patching file kernel/sched_bfs.c
patching file kernel/Makefile
patching file kernel/kthread.c
patching file kernel/posix-cpu-timers.c
patching file kernel/exit.c
patching file kernel/fork.c
patching file mm/oom_kill.c
patching file init/Kconfig
patching file kernel/delayacct.c
patching file kernel/trace/trace.c
patching file fs/proc/base.c
patching file kernel/sched_debug.c
patching file include/linux/ioprio.h
patching file Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
patching file kernel/Kconfig.preempt
dik za tip
Jen aby to nebyl placebo efekt :)
Asi neco delam spatne... Mel bych to pak hledat v Enable the block layer --> IO Schedulers ??
zkousel jsem s vanilla-sources-2.6.31-rc9
Planovac (neplest s I/O schedulerem) mas jenom jeden. Patch proste nahradi jeden planovac druhym.
Projdi si ten Makefile.rej, není to nic závažného. BFS patch jen přidává vlastní suffix ke kernel verzi, Gentoo patche ho samozřejmě přidávají také. Takže ten failed hunk ničemu nevadí :)
Je nějaké šance, že by se BFS dostalo i do normálních distribucí, např. jako volba v instalaci? Opravdu mi je jedno, jestli moje MySQL na localhostu co mám jen pro vývoj zvládne 10000 dotazů za sekundu nebo 15000, ale není mi jedno, když mi myš cuká a pořád čekat na odezvu systému.
FreeBSD
taky jsem si to chtel vyzkouset, ale neprecet jsem si config a tak jsem mel po necelych 3 hodinach jadro, ktery z moji reiserfs partisny nedokazalo nabootovat. tak ted si pockam na update na 2.6.31 a pak to zkusim znovu a lepe :)
Do Source Mage se BFS také dostalo.
Pokud lze Source Mage považovat za "normální distribuci".
LKLM -> LKML
Děkuji, opraveno.
tak jsem aktualizoval a tohle je vysledek:
end_request: I/O error, dev cciss/c0d1, sector 0
end_request: I/O error, dev cciss/c0d2, sector 0
kazdou vterinu desitka radku s touhle chybou.