Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
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.