Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
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).
nice
pouzivam casto (renice
jakbysmet)
proc, prioritu portage de nastavit i v make.conf ...
load se dostává ke 100 % na obou jádrech
A to je špatně? Pro mne by spíš bylo špatně, pokud by to tak nebylo.
nice
, na což padl argument, že je dobré, když se dá během kompilace i pracovat, nacož Heron argumentoval, že se mu na relativně starém jednojádru nepřehoupne load přes 15 %. Tak jsem jen napsal, že mívám vytížena 2 jádra na 100 % a pracovat při tom nejde (takže také považuji použití nice
za normální)
takže snad Heron opravdu myslel 15 %.
Nemyslel. Heron myslel load 15, tedy 15 procecesů ve stavu Run, každý schopný samostatně vytížit (jednojádrový) procesor na 100%. Ostatně, je to POVRay, že.
Zkus si to. Stačí ti xkrát pustit cat /dev/zero | bzip2 > /dev/null
a load bude => x.
ab
. Měl jsem na dva dny k dispozici Sun Fire V20z a nemohl jsem odolat. :-)
Pokud má Load 15, tak by si měl pořídit silnější stroj.
To není tak jednoduchá odpověď. Samozřejmě, pokud má někdo trvalý load při běžné práci větší, než je počet procesorů (jader, výpočetních jednotek, nebo jak k tomu chceme říkat), tak je rychlejší HW na místě. Na druhou stranu budou vždy existovat úlohy, které vytíží jakýkoliv HW. Myslel jsem si, že ten příklad s POVRay bude dostatečně výmluvný.
Na jednojádře (AthlonXP) jsem míval bez problémů load 15 (nechtěla se mi řešit fronta pro render v PovRAY, tak jsem to pustil současně) a šlo tam dál normálně pracovat.Asi taky záleží na typu zátěže. Pokud se jenom něco počítá, tak to celkem jde. Ale pokud se moc seekuje po disku, tak už je to horší.
Conův alternativní návrh je ve větší míře vložit řízení interaktivity do rukou uživatelského prostoru. Ke každému procesu by přidal parametr, který bude popisovat jeho potřeby, co se latence týče. Aplikace by poté mohly svoje požadavky sdělit jádru; aplikace přehrávající zvuk by od jádra žádalo co nejmenší latence, zatímco make by jádro informovalo o tom, že na latenci záleží jenom málo. K tomu by se přidalo globální nastavení udávající, jestli by procesy s nízkými latencemi také měly dostat více času CPU. Výsledkem by podle Cona bylo to, že by se explicitně preferovaly procesy „na popředí“ (za předpokladu, že to budou ty, které vyžadují nižší latenci). Distributoři by pro tyto parametry mohli nastavit výchozí hodnoty; uživatelé by je potom mohli změnit.
Kde jsou ty doby, kdy se Linuxáři smáli Windows, že plánuje podle toho, jestli je okno aplikace má fokus nebo ne. Teď už se tato prasárna diskutuje i v JN.
Kde jsou ty doby, kdy se Linuxáři smáli Windows, že plánuje podle toho, jestli je okno aplikace má fokus nebo ne.Špatně čteš - o fokusu okna tam není ani zmínka.
že plánuje podle toho, jestli je okno aplikace má fokus nebo neNo, ono to je v podstate velmi smysluplna featura. Samozrejme je nesmysl takovou heuristiku rvat primo do planovace, ale kdyby muj window manager nabizel dynamickou zmenu priorit procesu podle fokusu, tak bych si to urcite zapnul. Samozrejme, implementace takove featury by vyzadovala asi nejake dalsi zmeny v Linuxu (napr. zminene group schedulovani podle sessions a moznost prirazeni a uzivatelske zmeny priorit tem skupinam).
Pokud bude scheduler potřebovat, aby programy říkaly, jak moc interaktivní jsou, tak to zákonitě někdo do všech programů musí dodělat.Ale proč by to bylo potřeba? Od toho jsou výchozí hodnoty a není problém, aby byly stejné jako doteď. Když program nebude chtít specifikovat, že potřebuje malou latenci, tak to neudělá; a hádal bych, že programy na přehrávání hudby/videa se adaptují hodně rychle, protože tam to dává smysl.
Nedosti na tom, interaktivita programů se mění v čase: ledasjaká klikací aplikace se občas na pár sekund zamyslí a tou dobou ji opravdu nechci upřednostňovat.Opět nevidím problém - jestliže je aplikace udělaná tak, že si specifikuje požadavek na interaktivitu, pak si ho taky bude moci změnit předtím, než začne chroustat.
#include <pthread.h> #include <stdio.h> #include <unistd.h> void* th_main(void* a) { printf("T2: %u\n", getpid()); return NULL; } int main() { pthread_t t; printf("T1: %u\n", getpid()); pthread_create(&t, NULL, th_main, NULL); pthread_join(t, NULL); return 0; }
User-space glibc/NPTL typ pthread_t (vrací ho pthread_create()) sice vypadá na první pohled dál jako integer, ale uvnitř pod haubnou NTPL je to ve skutečnosti "struct pthread*" = ukazatel na struct, ve kterém si NPTL drží data o daném jednotlivém vlákně...
V jakési starší verzi to bylo o to pikantnější, že na 32-bitových systémech byl pthread_t
pointer, zatímco na 64-bitových integer. Velmi praktické, hlavně když ho člověk potřeboval vypsat do logu…
Tiskni Sdílej: