Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi 2023.05. Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Linux Foundation Europe představila projekt RISE (RISC-V Software Ecosystem), jehož cílem je urychlit vývoj open source softwaru pro architekturu RISC-V.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu pro jednodeskové počítače na platformě ARM, byl vydán ve verzi 23.05. Přehled novinek v Changelogu.
Minulý týden proběhla openSUSE Conference 2023. Mimo jiné bylo oznámeno přejmenování systému MicroOS Desktop. MicroOS Desktop GNOME byl přejmenován na openSUSE Aeon a MicroOS Desktop Plasma na openSUSE Kalpa.
Thom Holwerda z OSnews si všímá, že vývoj operačního systému MINIX je prakticky mrtvý. Jeho hlavní autor, Andrew Tanenbaum, formálně odešel do důchodu v roce 2014 a příspěvky do kódu v následujících letech vůbec ustaly. Stav projektu shrnuje diskuze z roku 2020. Sice vyšlo najevo, že Intel používal MINIX v Management Engine, ale změny nezveřejňoval.
Google Chrome 114 byl prohlášen za stabilní. Nejnovější stabilní verze 114.0.5735.90 přináší řadu oprav a vylepšení (YouTube). Vypíchnut je CHIPS (Cookies Having Independent Partitioned State). Opraveno bylo 16 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byly zveřejněny prezentace a videozáznamy přednášek a fotografie z česko-slovenského setkání poskytovatelů přístupu k internetu, provozovatelů telekomunikačních sítí, registrátorů domén a provozovatelů počítačových sítí a technických nadšenců CSNOG 2023 (Czech and Slovak Network Operators Group) konaného 16. a 17. května ve Zlínu.
Soutěž amatérských robotů Robotický den 2023 proběhne v neděli 4. června v Kongresovém centru Praha.
V Tchaj-peji probíhá počítačový veletrh COMPUTEX 2023. Firmy představují své novinky. Nvidia například superpočítač DGX GH200 AI.
Vyšla nová verze XMPP (Jabber) klienta Gajim. Nejvýznamnější novinkou je integrace OMEMO pluginu přímo do jádra aplikace, takže již není třeba plugin samostatně instalovat. Přehled dalších novinek je dostupný na oficiálních stránkách. Gajim je vytvořen v jazyce Python s využitím knihovny GTK a vedle Linuxu jej lze vyzkoušet i na platformách MacOS a Windows.
Dobry den,
mam domaci server s Intel Atomem, na kterem mi bezi pouze cups server a nfs. Oddily ze serveru mam normalne pres mount pripojene na pracovni stanici. Pokud si chci napr. pustit nejaky film primo ze serveru, tak se stane, ze v nahodnych intervalech se film zastavi na cca 20 sekund a pote se znovu rozjede a cas filmu mezitim uplyne. Takhle se muze zastavit 2x behem 5ti minut nebo 1x za hodinu. Xine mi napise, ze zaznamenalo hodne ztracenych snimku. Logicke vysvetleni by bylo, ze je server zatizen, ale on bezi neustale maximalne kolem 5% vytizeni. Nedokazu si predstavit co by vyvolavalo takove jednorazove zatizeni. Setkal se nekdo s podivnym chovanim ? Sit je klasicky 100Mbit ethernet. Server bezi na Debian Lenny a pracovni stanice na Debian testing.
bezi neustale maximalne kolem 5% vytizeni
Zásadní je 5% vytížení čeho? Klidně může být 100% vytížení I/O za současného +- flákání procesoru. Musíš zjistit co přesně se děje během těch 20s. Na klientu i serveru prozkoumej logy a zjisti co se děje (iotop, iftop, MRTG, jnettop).
zkusil jsem vsechny programy co jsi mi doporucil a zjistil jsem, ze pri preruseni prehravani klesne v programu iotop cteni z disku 0 kB/s a potom se zase rozjede na 120kB/s-250kB/s (tim padem samozrejme prestane komunikace i v siti, ale problem je primarne nejspis v disku. Takze dalsi otazka - jak to resit ?
Nastává stejný problém i s:
$ mplayer -cache <kBytes> input.avi
Ahoj,
a zkusil jsi i jiny prehravac? Treba mplayer nebo vlc, pokud totiz prehravas normalni avi a ne zadny stream, tak by se tohle dit nemelo ani v pripade ze server bude pretizeny, nanejvis se film na chvilku stopne. Dalsi moznost je pouzit nfs na tcp protokolu, pak budes mit jistotu ze se zadne packety ztratit nemuzou.
Dalsi moznost je pouzit nfs na tcp protokolu, pak budes mit jistotu ze se zadne packety ztratit nemuzou.
Stejnou jistotu máš i s NFS na UDP, rozdíl mezi nasazením NFS nad TCP/UDP nespočívá ve "ztrácení paketů", ale v rychlosti. Protokol TCP je stavěný na znovuposlání ztracených paketů, kdežto u UDP se to musí řešit přímo v implementaci NFS.
Nebo si snad myslíš, že někdo jako Sun nasazuje v produkčním prostředí síťový FS, který nezaručí konzistenci dat. Navíc myslíš, že by se vůbec prosadil síťový FS, který by si na UDP nekontroloval ve vlastní režii zda-li protistrana všechna data úspěšně přijmula. Příště bacha na FUD. 
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
7.6.2009 08:15