plwm je nový, poměrně minimalistický správce oken pro X11. Podporuje dynamické dláždění okny, plochy, pravidla pro okna atd. Zvláštností je, že je napsaný v logickém programovacím jazyce Prolog. Používá implementaci SWI-Prolog.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Sean Heelan se na svém blogu rozepsal o tom, jak pomocí OpenAI o3 nalezl vzdálenou zranitelnost nultého dne CVE-2025-37899 v Linuxu v implementaci SMB.
Jiří Eischmann v příspěvku na svém blogu představuje typy, jak lépe chránit své soukromí na mobilním telefonu: "Asi dnes neexistuje způsob, jak se sledování vyhnout úplně. Minimálně ne způsob, který by byl kompatibilní s tím, jak lidé technologie běžně používají. Soukromí ovšem není binární věc, ale škála. Absolutního soukromí je dnes na Internetu dost dobře nedosažitelné, ale jen posun na škále blíže k němu se počítá. Čím méně dat se o vás posbírá, tím nepřesnější budou vaše profily a tím méně budou zneužitelné proti vám."
Byla vydána nová stabilní verze 25.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Warbler. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Multiplatformní open source spouštěč her Heroic Games Launcher byl vydán v nové stabilní verzi 2.17.0 Franky (Mastodon, 𝕏). Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 26 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Klávesnice IBM Enhanced Keyboard, známá také jako Model M, byla poprvé představena v roce 1985, tzn. před 40 lety, s počítači IBM 7531/7532 Industrial Computer a 3161/3163 ASCII Display Station. Výročí připomíná článek na zevrubném sběratelském webu Admiral Shark's Keyboards. Rozložení kláves IBM Enhanced Keyboard se stalo průmyslovým standardem.
Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
Java má dnes 30. narozeniny. Veřejnosti byla představena 23. května 1995.
Posílám za kolegu Zaatharena:
Ahoj, socket M podporuje maximálně dvoujádrová Core2Duo CPU generace Merom na 65nm procesu, původně vzniknul na Core Duo, což bylo takové nedokonalé Pentium M s dvěma jádry a v době kdy neměli koupené x64 instrukce od AMD. Když přišla C2D T5xxx a T7xxx přišel i pak socket P s rychlejším FSB, správně píšeš, že top CPU na socket M je T7600. Socket P kromě rychlejšího FSB přinesl tuším lehce jiné napájení snad + digitální snímaní teplotních čidel v CPU, to ale podporuje až Penryn.
Socket P v první iteraci byl typicky z 965kou chipsetem a 800FSB v roce 2007. TOP CPU je tam T7800, v roce 2008 s příchodem Penrynu se TOP CPU stala T9600, socket P získal druhou iteraci získáním 1066FSB s Intel PM45 či GM45 chipsety a také první mobilní quad-core ale má to velká ALE.
Quad-Core CPU fungují v socketu P, ale JEN v malém množství notebooků. jednak mají TDP 45W + ale jinak trochu komunikují s chipsetem, je jen malé množství notebooků co je podporuje a umí s tím pracovat, pokude se tedy bavíme o Q9000/91000 či QX9300.
Pokud máš ntb co má socket P a FSB1066 velmi zajímavá CPU na tento socket jsou P9700, T9900 a X9100, jen ta X9100 má dsot vysoké TDP.
on by ten athlon na lecos stačil ještě dneska, ale obrovskej problém je že nemá instrukční sadu SSE2, takže už hromada věcí nefunguje, včetně například všech novějších verzí openoffice, flashe, pětková plasma a kwin, steam, secondlife, google earth a spousta dalšího. prostě se to nespustí nebo to okamžitě padne na sigill :-/
mam v plánu přendat disky do jinýho kompu kde je sempron, stejně slabej, možná i slabší, ale 64bitovej postavenej na novějšim jádře se všema potřebnýma instrukcema. teď mi kde4 kterej už je vyhozenej z repozitářů blokuje i všechny ostatní updaty a přejít na pětku na tomhle procesoru nemůžu, zůstal bych jen s kurzorem na černý ploše, oveřeno 2x...ffmpegu mohl být kód, který neměl SIMD asamblér v MMX2, ale jenom SSE2Tak ve ffmpegu byly šílenosti jako dekodér pro XScale. Nějaký SSE/MMX/3DNow by tam bylo tak od začátku IMO. Nehledě na to, že se SSE generuje v gcc přímo (když není asm optimalizace a dělá se to přes C).
V určitých kruzích je zvykem zdůrazňovat nevýhody LCD a nevýhody CRT zamlčovat. Takže se třeba řeší (nebo spíš donedávna řešily) pozorovací úhly, ale že při pohledu z úhlu byl obraz na CRT monitoru (geometricky) zkreslený až běda (a na "plochých" CRT byl zkreslený i zepředu), to je tak nějak v pohodě. Že můj poslední CRT monitor (a to byla "pouhá" 19") měl běžnou pracovní spotřebu 90-100 W, na to se už taky nějak zapomnělo. O podivně rozmlžených pixelech, jak se paprsek náhodně trefoval do mřížky, se kupodivu také nemluví. Prostě se vybere jeden parametr a na tom se točí diskuse, aby se ukázalo, jak jsou LCD k ničemu.
(Podotýkám, že nejsem žádný evangelista, sám jsem LCD odolával výrazně déle, než bylo běžné - ale i tak jsem přešel někdy kolem roku 2006 a řešit dnes přednosti CRT v době, kdy LCD roky používají i profesionální grafici, mi přijde úsměvné.)
Problém je ale obecnější, stačí se podívat na stále se opakující litanie o tom, jak DSLR nesahají kinofilmu ani po kotníky, nesmrtelný vinylový fetišismus nebo kult Nepřekonatelné plazmy.
O podivně rozmlžených pixelech, jak se paprsek náhodně trefoval do mřížky, se kupodivu také nemluví.+1000, to byl IMHO ten nejzásadnější humus na CRT a vůbec nechápu, proč to těm apologistům nevadí. Ty reálné pixely u LCD - i u špatných TNek - byly velký krok vpřed v ostrosti a tak. Pro mě bylo tak během první půlhodiny následující po vybalení prvního LCDéčka (ve škole i všude tehdy byly CRT, takže jsem s ním tak trochu skákal do neznámých vod) stoprocentně jasno.
Za mě byla nejvýznamnější výměna D-SUB kabelu za DVI-D u prvního LCD, najednou zmizelo všechno co tam nepatří a obraz byl perfektní <3
A vinyl vydrzi skoro vecne, digitalni data odchazi (i orig CD) a je nutno se o ne starat3/10, čumák se mi při čtení ani nepohl ;P
Teď už je asi jasné, proč tomu říkám vinylový fetišismus a jakou souvislost to má s vychvalováním CRT monitorů.
Ač nemám rád konspirační teorie, při pohledu na tohle velebení gramodesek a neustále se opakující články o tom, jak jsou gramofonové desky jediné fyzické (hudební) médium, jehož prodeje rostou, se otázka "Qui bono?" prostě nabízí. A nemůžu si pomoci, ale jako ten, kdo z toho má největší prospěch, mi vycházejí vydavatelé. Když místo CD, které se dá triviálně bezztrátově kopírovat nebo nagrabovat, mohou za dvojnásobek prodávat gramofonovou desku, která je mechanicky choulostivější a bezztrátově z ní záznam nedostanete, to je pro vydavatele splněný sen.
Ja používam LCD kúpený v roku 2004 (17" 1280x1024). Aj v tej dobe boli už LCD celkom dobré. Dosť paradoxné je, že aj pri používaní cca 8h-12h denne vrátane víkendov s vypínaním a zapínaním dosť často (keď mám hibernovaný notebook neviem prečo ale asi každých 5 minút sa prebudí VGA, na chvíľu zasvieti monitor a znovu vypne) má CCFL podsvietenie farbu ako pri kúpe. Čo sa týka podsvietenia ... no nemám reguláciu takže stále beží na 100%, svietivosť podľa kalibračnej sondy vyše 150cd/m2. Nieviem nakoľko môžem veriť kalibračnej sonde pretože žiaden monitor v bývalej práci 150cd/m2 s max jasom po zahriatí nedosiahol.
Hmm, ja som vždy predpokladal, že je to životnosťou CCFL. Na internáte som mal 2 spolubývajúcich s ASUSmi a obom 2 a pol roka po kúpe stmavlo podsvietenie a malo ružovú farbu.
youtube-dl -FA tohle rozhodně není HTML5.
70% pri VDPAU? To sa mi nezdá. Na slabom ARM mi mpv používa do 10%.
Je to len na jedno jadro (inak by tam nemohla byť hodnota 150%). No aj tak je to moc moc vysoká hodnta. Na allwinneri A20 s vdpau to mpv dá hlboko pod 10% na 1 jadre (pri surových predpripravených h.264 dátach bez demuxera to dokonca ide pod 1%) a to mám pozapínané blbosti ako OSD, takže ešte mixuje obraz s ovládacími prvkami. Povedal by som, že VDPAU buď vôbec nefunguje, alebo je nejak zbastardený vo inak by to muselo žrať podstatne menej.
Na x86 to nemám ako overiť, mám len intel X3100 bez VDPAU. Ak sa pri VDPAU podtaktoval potom sú celé výsledky "benchmarku" irelevantné. Len sa mi zdá divné, že low cost ARM za myslím 8€ či koľko to stojí pri veľkom množstve s frekvenciou 1GHz to zvláda na necelých 10% 1 jadra a druhé je nečinné.
Počkať nie je náhodou VDPAU práve o tom? Nemala by dekódovať h.264 práve nvidia? A áno používam samozrejme hw dekóder cez libvdpau-sunxi (vdpau implementácia pre cedar video dekóder / enkóder) inak by to išlo tak 1-5fps
No veď práve to mi na blogu nesedí. Podľa mňa autor síce tvrdí, že prehráva cez VDPAU, ale tipoval by som, že tam bude mať problém s driverom.
něco starýho jako třeba ta 8600GT co tu někdo zmiňoval toho asi moc nedá...8600 je druhá generace a H.264 dává úplně v pohodě i na 1920x1080 (Blu-Ray ripy) tak s 10%-20% vytížením procesoru (nějakej čas se kopírování dat a správu přehrávače sežrat musí). Osobě vyzkoušeno. Pokud se dívám dobře, tak VP8 nebo VP9 nemá implementovaný ani jeden set, možná proto moc nemá smysl ho cpát přes VDPAU a něco odměřovat protože se to stejně dekóduje na procesoru.
samozřejmě pojede softwarověSamozřejmě. Na to aby se to cpalo do VDPAU by musel mít tuhle volbu v sobě Firefox zakompilovanou a nějak sem ji nepostřehl, takže pokud ji tam nenacpeš skrze nějaký plug-in tak těžko to bude cpát Firefox sám od sebe do VDPAU.
media.hardware-video-decoding.enabled trueMyslel jsem, že zapíná akceleraci přehrávání videa zrovna třeba přes to VDPAU.
Na allwinneri A20 s vdpau to mpv dá hlboko pod 10% na 1 jadre (pri surových predpripravených h.264 dátach bez demuxera to dokonca ide pod 1%) a to mám pozapínané blbosti ako OSD, takže ešte mixuje obraz s ovládacími prvkami.No, vzhledem k tomu, že pokud se grafické jádro krmí oněmi surovými daty (u MPEGu[2,4] to může být, pokud si dobře pamatuju, i nemultiplexovaný elementary stream), tak jediné, co procesor řeší, je režie vstupního zařízení (tj. úložiště a/nebo síťová karta) a přepínání bufferů, protože přesun dat do dekodéru uvnitř grafické karty obstarává DMA engine a věci jako OSD a spol. se dělá přes průhlednou overlay vrstvu taktéž v grafické kartě. Ostatně, s podobnou zátěží zvládnou "přehrávat" (nebo nahrávat) H264 i 200-300MHz ARMy v5 v různých zařízení typu PVR nebo IP kamery.
pc2005
jsem na to mrknul a zjistil, že Firefox ve Windows XP to tahá nejspíš jako mp4/h264, má nastaveno media.mediasource.webm.enabled falsezatímco Firefox v Xubuntu 16.04 to tahá nejspíš jako webm/vp9, má nastaveno
media.mediasource.webm.enabled trueKaždopádně po úpravě parametru kleslo vytížení procesoru při sledování videa ve 360p na cca 90% a obraz se netrhá (ale je to na hraně). Odtud ale můžou pocházet i problémy s případnou akcelerací.
AMD A10-6790K (4x 4GHz), driver radeon, 1080p60 v HTML5 a FF 45.0a2 naprosto plynule. Ale to rozšíření se mi líbí, zkusím
Tiskni
Sdílej: