Steve Jobs a superpočítač Cray-1 budou vyobrazeny na pamětních jednodolarových mincích vyražených v příštím roce v rámci série Americká inovace. Série má 57 mincí, tj. 57 inovací. Poslední 4 mince budou vyraženy v roce 2032.
Byl zveřejněn průběžně aktualizovaný program konference OpenAlt 2025 o otevřeném softwaru a datech, IT bezpečnosti, DIY a IoT. Konference proběhne o víkendu 1. a 2. listopadu v prostorách FIT VUT v Brně. Vstup je zdarma.
Senát včera opětovně nepřijal návrh ústavního zákona, který měl do Listiny základních práv a svobod zakotvit právo občanů platit v hotovosti nebo být off-line. Návrh předložila skupina senátorů již v roce 2023. Senát dnes návrh neschválil, ale ani nezamítl. Pokud by ho přijal, dostala by ho k projednání Sněmovna a vyjádřila by se k němu vláda.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 13.0 (Mastodon). Forgejo je fork Gitei.
Společnost Eclypsium se na svém blogu rozepsala o bezpečnostním problému počítačů Framework. Jedná se o zranitelnost v UEFI umožňující útočníkům obejít Secure Boot.
Editor kódů Zed (Wikipedie) po macOS a Linuxu s verzí 0.208.4 už běží také ve Windows.
Apple dnes představil 14palcový MacBook Pro, iPad Pro a Apple Vision Pro s novým čipem M5.
Debian pro mobilní zařízení Mobian (Wikipedie) byl vydán ve verzi 13 Trixie. Nová stabilní verze je k dispozici pro PINE64 PinePhone, PinePhone Pro a PineTab, Purism Librem 5, Google Pixel 3a a 3a XL, OnePlus 6 a 6T a Xiaomi Pocophone F1.
Operátor O2 představil tarif Datamanie 1200 GB . Nový tarif přináší 1200 GB dat s neomezenou 5G rychlostí, a také možnost neomezeného volání do všech sítí za 15 Kč na den. Při roční variantě předplatného zákazníci získají po provedení jednorázové platby celou porci dat najednou a mohou je bezstarostně čerpat kdykoli během roku. Do 13. listopadu jej O2 nabízí za zvýhodněných 2 988 Kč. Při průměrné spotřebě tak 100 GB dat vychází na 249 Kč měsíčně.
Byly publikovány informace o útoku na zařízení s Androidem pojmenovaném Pixnapping Attack (CVE-2025-48561). Aplikace může číst citlivá data zobrazovaná jinou aplikací. V demonstračním videu aplikace čte 2FA kódy z Google Authenticatoru.
Tiskni
Sdílej:
Jak jsi dosel k tomu narustu na -j16 ve druhem grafu? Nejak divne to prokladas.
Nebo jsi delal i testy s -j8-16?
V pohode. Zajimavy pokus.
počet jobů by teda měl bejt takovej, do kolika vláken se kompilovaná věc dokáže rozložit, ne? :)
Off topic - ako sa da pracovat v DWM s GIMPom? Skusal som a je to bieda... Inac by som nemal na DWM nijake namietky...
Dwm je skvelý wm, ale spolieha sa na to, že aj programy budú podobne skvelé a nebudú nikomu nútiť, ako si má rozostaviť okná. Bohužiaľ to nie je často splnené, takže tu máme na to float. Proste odfloatuj gimp na nejakú plochu a tam ho môžeš používať úplne rovnako ako všetci ostatní.
{ "Gimp", NULL, NULL, 0, True, -1 },což způsobí, že se gimp bude spouštět vždy s přepnutím na plovoucí rozložení. dwm je totiž dynamický wm. Kromě tiling a floating módu však obsahuje ještě monocle (podobné ratpoison) a pomocí malinkého patche si můžeš třeba dodat vertical tiling (bstack patch). A pozor na jednu věc - dwm nemá jako wmii nebo jiné dynamic wm možnost používat tiling a floating vrstvy najednou, buď je kompletně celý wm floating nebo tiling (přepíná se pomocí zkratek)
To nie je úplne pravda. Napríklad okná s hintom TRANSIENT sú floating (logicky) aj keď si v tiling móde. A v prípade potreby je triviálne napísať patch (alebo možno aj existuje), kde budeš mať zoznam aplikácií, ktoré sa na danej ploche majú floatovať (tak to má napríklad xmonad). Dokonca mám pocit, že tak to aj v dwm kedysi bolo, ale už som ho rok nevidel, tak je to teraz možno inak.
Len pre budúcnosť: keď máš graf, kde 99% plochy zaberá prázdne miesto (v zmysle, že je rozdelený na dve časti a jedna z nich je taká), je rozumné závislosť prehnať logaritmom. Takto z toho veľa nemám, nevidím poriadne ani rozdiely medzi malým počtom jobs (kde sú najvýraznejšie), ani medzi veľkým počtom (kde sú pomalé). Ak sa ti s tým, ešte chce pohrať, mohol by si to skúsiť, stačí zadať "set log y" a ak to bude stáť za to, postni to sem znova. Dík.
V poriadku. Len pre istotu som na to upozornil, lebo s grafmi neskúsení ľudia robia veľa vecí, ktoré sú jednak neestetické a jednak sa stráca veľa informačnej hodnoty.
Btw, je pravda, že s tým logaritmom som sa silne sekol, tvoja závislosť je typu 1/x a po aplikácii logaritmu sa z nej rozhodne nestane priamka S tým sa toho moc robiť nedá (viď "plot 1/x"). Aspoň mňa teda nič rozumné nenapadá, ale možno niekto poradí
Hehe, my, co máme jedno jádro nemáme problém a nastavujeme bezmyšlenkovitě -j2.
A dělal jsi něco jako flush-all-caches před každým měřením? Protože jestli ne, tak tvrdím, že výsledky, ač pěkné jsou dost k ničemu.
Ještě dodám, že jsem nelenil a zeptal se googlu a google řekl, že odpověd mám hledat v linux-mm.org/Drop_Caches. Z toho článku bych vyvozoval závěr, že před každým testem nejlépe dělat
sync echo 3 > /proc/sys/vm/drop_caches
+1
Není až tak pravda. Brání mi v tom lenost. Respektive jelikož nevlastním vícejádro, nemyslím, že mi znalost toho, jestli jde o j=2*p, nebo j=p+1 momentálně bude k něčemu dobrá a tak se nebudu namáhat.
Jestli jsem urazil tak pardon, nebylo to tak míněno a příště se pokusím vnzášet námitky méně arogantně.
Daj link na tu hystericku reakciu ohladne toho conky...
Zase hysteria?
Možno mi niečo ušlo, ale podľa tých grafov je čas dokončenia úlohy klesajúci s n (v rámci chyby merania, ktorá nie je uvedená, ale nejakú som si tam domyslel), tak prečo nenastaviť rovno maximum, povedzme 10000?. Z tých grafov predsa nevyplýva, že keď nastavím 2*n + 10, alebo 4*n, tak to bude horšie, práve naopak, je tam ešte pokles.
tak prečo nenastaviť rovno maximum, povedzme 10000na to jsou dve odpovedi... jednak to asi nema smysl ... amdahl's law je priserna bestie a jde to videt i z tech grafu... od urciteho budu to zlepseni je absolutne nevyznamne. za druhe, tady v techto grafech to nejde poznat... ale s postupem casu by se tam objevil pokles vykonu, ktery je zpusobeny tim, ze udrzovani X procesu uz bude mit takovou rezii, ze se nevyplati vic paralelizovat.
To zlepšenie je bezvýznamné, ale aký má význam hádať sa o 2*n + 47 a 3^n - exp(n) + 1, keď to najlepšie riešenie je aj tak asymptotické?
Ten druhý bod to trochu vysvetľuje a presne také niečo som si aj myslel, že to bude overhead. Ničmnej, skutočne to v tých grafoch nevidím a ako také nemajú o dôkaze 2*n žiadnu vypovedaciu hodnotu. To, čo popisuješ ty, by bol totiž graf s minimom niekde okolo 2*n (n-1, whatever) a nie čisto klesajúci graf (modulo chyba merania). Lenže, aj tak je to zjavne závisle od toho, kde to použiješ (konkrétny program, ktorý sa prekladá), takže jaký to má zmysel? Keď už ten make spustíš raz, tak dostaneš správnu binárku a si hotový. Načo ho spúšťať znova a testovať, či by sa to nedalo vybuildovať o sekundu rýchlejšie? A ďalej, skutočne to riešenie, nastaviť proste n = 10000 je až tak zlé? Ak je to tak, že sa o moc tá asymptotická hodnota nelíši od minima, tak nie je dôvod skúmať nejaké závislosti a nastavovať to pre každý program zvlášť, najrozumejšie je zobrať raz a pre vždy n = 10000 a človek je vybavený. Fakt mi to pripadá ujeté
To, čo popisuješ ty, by bol totiž graf s minimom niekde okolo 2*n (n-1, whatever)ja jsem taky psal, ze to zalezi na typu ulohy a vetsina techto hodnot se nastavuje/odhaduje empiricky. mam napr. zkusenost s ulohami kde se ciste pocita je dobre se drzet kolem toho n... pokud se na neco musi cekat napr. diskove I/O, sit, jiny proces, je dobre mit pocet procesu vetsi.
Ak je to tak, že sa o moc tá asymptotická hodnota nelíši od minima, tak nie je dôvod skúmať nejaké závislosti a nastavovať to pre každý program zvlášť, najrozumejšie je zobrať raz a pre vždy n = 10000 a človek je vybavený.to neni dobry napad. kdyz seberes hodnotu n = 10000 takovy vypocet ti sebere vyrazne vic zdroju (napr. RAM) nez kdyz bude n = 100 a realny uzitek bude srovnatelny.
Aha dík za ozrejmenie, ale vôbec do toho nevidím a z blogpostu som to nepochopil. V tom prípade ale treba skúmať nie len zaťaženie CPU, ale aj zaťaženie RAM, ak chceme objektívny výsledok a tento blogpost bol tým pádom ešte viac na nič
Ty asi na konštruktívnu kritiku veľmi neveríš, čo?
# procesu, obsazeno RAM, obsazeno swap, load avg za posledni minutu 1100 1800 300 ? 1672 ? ? ? 1436 700 200 ? 2555 ? ? 855 2666 1942 670 899 2846 1931 433 428 3977 1726 953 568 3652 1938 1493 469Čas jsem nezaznamenával, kompilace probíhala něco přes 25 minut. Pak se na obrazovce objevilo několik hlášek "Out of memory: kill ... (make)" tak jsem to vzdal. Od počátku kompilace kontrolka disku ani jednou nezhasla. IMHO i kdyby kompilace dopadla úspěšně, trvala by s takovým chováním disku několik hodin (normálně kolem 30 minut). Stále zastávám názor, že nejvhodnější je n*2.
Tak toto je zaujímavé, dík. Keby sa ti nejako podarilo zmerať aj tú záťaž pamäte + čas pri -jX, tak to by bolo super. Ja osobne to totiž na starom jednojadre asi nezmeriam, ale aj tak by som bol zvedavý, ako sa to chová
Zajímavé by právě bylo dotáhnout ten test do konce – najít bod, kdy se to začíná lámat* a režie žere více než je mezní užitek z dalších vláken.
*) těch 89.910 → 90.142 nepovažji za zlom, ale spíš chybu měření.
idle
a iowait
nulový (na obrazovce top
je to čtvré á páté číslo). Většínou je výsledek opravdu dost blízký dvojnásobku počtu jader plus něco, i když záleží na poměru výpočty/I/O - čím víc I/O a čím pomalejší disky, tím víc procesů navíc.