Desktopové prostředí Budgie bylo vydáno ve verzi 10.10. Dokončena byla migrace z X11 na Wayland. Budgie 10 vstupuje do režimu údržby. Vývoj se přesouvá k Budgie 11. Dlouho se řešilo, v čem bude nové Budgie napsáno. Budgie 10 je postaveno nad GTK 3. Přemýšlelo se také nad přepsáním z GTK do EFL. Budgie 11 bude nakonec postaveno nad Qt 6.
OpenChaos.dev je 'samovolně se vyvíjející open source projekt' s nedefinovaným cílem. Každý týden mohou lidé hlasovat o návrzích (pull requestech), přičemž vítězný návrh se integruje do kódu projektu (repozitář na GitHubu). Hlasováním je možné změnit téměř vše, včetně tohoto pravidla. Hlasování končí vždy v neděli v 9:00 UTC.
Byl vydán Debian 13.3, tj. třetí opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.13, tj. třináctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Na stránkách Evropské komise, na portálu Podělte se o svůj názor, se lze do 3. února podělit o názor k iniciativě Evropské otevřené digitální ekosystémy řešící přístup EU k otevřenému softwaru.
Společnost Kagi stojící za stejnojmenným placeným vyhledávačem vydala (𝕏) alfa verzi linuxové verze (flatpak) svého proprietárního webového prohlížeče Orion.
Firma Bose se po tlaku uživatelů rozhodla, že otevře API svých chytrých reproduktorů SoundTouch, což umožní pokračovat v jejich používání i po plánovaném ukončení podpory v letošním roce. Pro ovládání také bude stále možné využívat oficiální aplikaci, ale už pouze lokálně bez cloudových služeb. Dokumentace API dostupná zde (soubor PDF).
Jiří Eischmann se v příspěvku na svém blogu rozepsal o open source AdGuard Home jako domácí ochraně nejen před reklamou. Adguard Home není plnohodnotným DNS resolverem, funguje jako DNS forwarder s možností filtrování. To znamená, že když přijme DNS dotaz, sám na něj neodpoví, ale přepošle ho na vybraný DNS server a odpovědi zpracovává a filtruje dle nastavených pravidel a následně posílá zpět klientům. Dá se tedy používat k blokování reklamy a škodlivých stránek a k rodičovské kontrole na úrovni DNS.
AI Claude Code od Anthropicu lépe rozumí frameworku Nette, tj. open source frameworku pro tvorbu webových aplikací v PHP. David Grudl napsal plugin Nette pro Claude Code.
Byla vydána prosincová aktualizace aneb nová verze 1.108 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.108 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Na lasvegaském veletrhu elektroniky CES byl předveden prototyp notebooku chlazeného pomocí plazmových aktuátorů (DBD). Ačkoliv se nejedná o první nápad svého druhu, nepochybně to je první ukázka praktického použití tohoto způsobu chlazení v běžné elektronice. Co činí plazmové chladící akční členy technologickou výzvou je především vysoká produkce jedovatého ozonu, tu se prý podařilo firmě YPlasma zredukovat dielektrickou
… více »Aktuální verze vývojového jádra: 3.19-rc3 Vývojové jádro 3.18-rc3 vyšlo dne 5. ledna (oznámení). Linus k tomu uvedl:
Je o jeden den opožděné – důvodem nebyl žádný konkrétní problém ve vývoji, ale včera jsme zkrátka doma obkládali koupelnu. Ale rc3 je už venku a všechno probíhá celkem v klidu. Opravdu doufám, že to znamená, že verze 3.19 vypadá dobře, ale je stejně dobře možné, že je to jen proto, že se všichni stále zotavují z dovolených.
Verze 3.19-rc2 byla vydána, s minimálním počtem změn, 28. prosince.
Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace. Aktualizace verzí 3.10.64, 3.14.28, 3.17.8 a 3.18.2 jsou v době vzniku tohoto textu v procesu kontroly, lze je očekávat nejdříve 9. ledna. Připomínáme, že verze 3.17.8 bude poslední aktualizace v sérii 3.17.
„Nové a vylepšené“ je ve skutečnosti vlastně jen vylepšené, pokud do toho zahrnete zpětnou kompatibilitu, místo abyste prohlásili: „Teď musí všichni všechno dělat nově a vylepšeně – a jinak.“
To, že v téhle fázi musím pořád žebrat, aby někdo opravil bufferbloat, je dost otravné. Podle té záplavy problémů jsem si vážně myslel, že si k nám všichni už dávno vyšlapou cestu a začnou používat to nepřeberné množství informací a kódu, které jsme pro vás zveřejnili on-line. Doufali jsme, že všichni řešení bufferbloatu nasadí, hlavně v extrémních případech, jako jsou letadla, přístup ve třetím světě a v odlehlých oblastech.
Proslulé zásady vývoje jádra uvádějí, že nejsou povoleny změny, které by poškodily programy v uživatelském prostoru; oprava, která by něco poškodila, musí být vrácena. Tyto zásady byly spuštěny ve zkušebním provozu minulý týden, kdy byly dvě takové změny vyřazeny z hlavního repozitáře. Tyto akce ukazují, že vývojáři jádra myslí princip regrese vážně, ale také ukazují, co to znamená, když se tyto zásady opravu dodržují.
V temných dobách před přelomem století byla podpora bezdrátových sítí v jádru optimisticky řečeno minimální. Ovladače, které existovaly, se většinou snažily, aby se bezdrátové adaptéry podobaly ethernetovým kartám s několika parametry navíc. Po čase byly tyto parametry standardizované v určitém stylu, v rámci rozhraní „bezdrátových rozšíření“. Toto rozhraní založené na ioctl() nebylo nikdy příliš oblíbené, ale několik let svůj účel plnilo, dokud se vývojáři v roce 2006 nezahnali vlastní vinou do kouta. Problémy s konflikty kompatibility nakonec vývoj tohoto API ukončily; dobrou zprávou bylo, že již existoval plán jeho nahrazení tehdy zaostalým API nl80211.
S odstupem času je nl80211 standardním rozhraním bezdrátového subsystému. Bezdrátová rozšíření, která jsou nyní jen kompatibilním rozhraním nad nl80211, jsou již několik let zastaralá a odpovídající vývojáři by se jich rádi zbavili úplně. Takže asi ani nikoho nepřekvapilo, že byla do verze 3.19 začleněna oprava, která odstranila možnost konfigurovat bezdrátová rozšíření do jádra.
Neméně překvapivý byl ovšem i příval stížností, který následoval v rychlém sledu. Zdá se, že správce sítě wicd stále používá API bezdrátových rozšíření. Ale možná ještě důležitější je, že nástroje uživatelského prostoru (například iwconfig), které byly součástí bezdrátových rozšíření, je stále používají – a ty se zase stále používají v bezpočtu skriptů. Takže to vypadá, že tato změna pravděpodobně rozbije pár systémů. Proto také Jiří Kosina zveřejnil opravu, která tuto změnu odvolává, a Linus ji okamžitě přijal.
Objevily se stížnosti vývojářů, že se uživatelé sami od sebe nikdy starých příkazů nevzdají a že je potřeba na ně trochu přitlačit. Ale jádro není pro takový nátlak nejvhodnější. Lepším přístupem, jak navrhl Ted Ts'o, by bylo:
Co se napíchnout do zpětné kompatibility příkazu „iw“ tak, že pokud argv[0] je „iwlist“ nebo „iwconfig“, poskytnout starším příkazům omezenou sadu kompatibility. Pak už vám jenom postačí, když přesvědčíte distribuce, aby nastavily pravidla tvorby balíčků tak, aby „iw“ kolidovalo s wireless-tools, a podaří se vám, aby všichni přešli na iw nejpozději do sedmi let.
Takový přístup by umožnil zabránit rozbití uživatelských skriptů. Ale i tak by trvalo dlouho, než by všichni uživatelé starých API přešli jinam, takže jádro musí podporovat API bezdrátových rozšíření do 20. let tohoto století.
Podstatně starší než bezdrátová rozšíření je koncept „bogomips“, odhad rychlosti procesoru používaný v jádře (některých verzích) pro smyčky s krátkým zpožděním. Hodnota bogomips zobrazená během startu (a uložená v /proc/cpuinfo) má jen volnou vazbu na skutečný výkon procesoru, ale lidé stejně rádi hodnoty bogomips porovnávají. Zdá se, že některé kódy uživatelského prostoru používají hodnotu bogomips pro vlastní účely.
Název bogomips nemohl působit důvěryhodně ani v začátcích a všechna ta léta mu příliš nepřidala. Funkce jako škálování napětí a frekvence způsobí, že se skutečný výkon procesoru v průběhu času mění. Hodnota vypočtených bogomips se může významně lišit podle toho, jak úspěšný je procesor v predikci smyček při spuštění kalibrační smyčku. Heterogenní procesory situaci ještě více komplikují. Ze všech těchto důvodů skutečné využití hodnoty bogomips v jádru v průběhu času klesá.
Kód architektury ARM na novějších procesorech tuto hodnotu vůbec nepoužívá, raději místo toho dotazuje časovač s vysokým rozlišením. U některých podarchitekturách se hodnota vypočtených bogomips značně lišily od toho, co někteří uživatelé považují za skutečnou hodnotu, což vede ke stížnostem. Vývojáři pro architekturu ARM se proto rozhodli jednoduše hodnotu bogomips z /proc/cpuinfo zcela odstranit. Oprava byla přijata do vydání verze 3.12 v roce 2013.
Téměř o rok a půl později si Pavel Machek stěžoval, že tato změna v jeho systému rozbila pyaudio. Když si všiml, že si stěžují i další, zveřejnil opravu, která tuto změnu ruší. Šlo podle něj o regresi uživatelského prostoru, tedy proti zásadám jádra.
Návrat této změny nepřijali v táboře ARM příliš pozitivně; Nicolas Pitre se jej snažil zablokovat se slovy: „Žádná konfigurace, která opravdu spoléhá na tuto zcela falešnou hodnotu bogomips neodrážející žádnou vazbu na skutečný hardware, nebyla označena za ‚funkční‘.“ Linus s tím ale nesouhlasil a prohlásil, že takové regrese nejde tolerovat a že: „Jádro slouží uživatelskému prostoru. To je naše práce.“ Tato změna byla řádně vrácena; jádra pro ARM počínaje verzí 3.19 budou znovu hodnotu bogomips exportovat; dá se předpokládat, že tato změna se dostane i do stabilního stromu.
Přesto však zůstává drobný problém, že hodnota bogomips vypočtená pro současné procesory ARM porušuje očekávání uživatelů; lidé se diví, když jejich zbrusu nový procesor udává hodnotu 6,0 bogomips. I systémy ARM by měly být rychlejší. Problémem podle Nicolase je, že tato vypočtená konstanta, která by měla pomoci se smyčkami zpoždění založenými na časovači, byla uložena jako hodnota bogomips; tradiční hodnota bogomips nebyla vůbec počítána. Podle něj neexistuje žádný skutečný důvod ke spojení těchto dvou hodnot. A tak zveřejnil opravu, která umožňuje vypočítat bogomips podle načasování spuštění těsné smyčky, která „nedělá nic“ – tak, jak se to dělalo na začátku.
Hodnota bogomips již dávno přežila svou hodnotu pro jádro samotné. Počítá se pouze pro uživatelský prostor, a i tam je tato hodnota přinejlepším marginální. Jak uvedl Alan Cox, hodnota bogomips se většinou vypisuje „pro uživatele, aby si ji mohli zkopírovat a tweetovat o tom, jak skvělé je jejich nový počítač.“ Ale protože některé programy závisí na přítomnosti této hodnoty, jádro musí toto hloupé číslo i nadále poskytovat, navzdory skutečnosti, že přinejmenším odráží realitu přinejlepším chabě. Ale i zbytečné číslo má hodnotu, pokud zabrání programu v havárii.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
23.3.2015 22:17
Petr Tomášek | skóre: 39
| blog: Vejšplechty
24.3.2015 11:32
Petr Tomášek | skóre: 39
| blog: Vejšplechty
26.3.2015 19:43
Petr Tomášek | skóre: 39
| blog: Vejšplechty
27.3.2015 11:33
|🇵🇸 | skóre: 94
| blog:
27.3.2015 16:19
|🇵🇸 | skóre: 94
| blog:
27.3.2015 19:01
|🇵🇸 | skóre: 94
| blog:
o tech 22 prekladech co cetlo celkem 68774 uzivatelu ? tak nejspis je zrusit/zakazat kdyz jsou tak spatne ? nebo, vlastne nechat a nadavat ??
Pleteš si uživatele a zobrazení. Navíc to nic neříká o kvalitě těch článků – na lŽivě nebo PCT taky občas otevřu článek, ale neznamená to, že je dobrý.
Ostatně, ty Fricovy překlady nejspíš někdy (i opakovaně) viděl každý uživatel české lokalizace linuxového desktopu nebo souvisejících aplikací (včetně Qt Creatoru).
nenabidne ze bude pomahat s korekci
Já to udělal. Odpověď jsem už ale nedostal. Netuším, kde ty moje e-maily skončily. Možná v /dev/null, možná ve spamu, možná prostě není zájem.
24.3.2015 16:29
Petr Tomášek | skóre: 39
| blog: Vejšplechty
25.3.2015 21:26
|🇵🇸 | skóre: 94
| blog:
.
24.3.2015 11:31
Petr Tomášek | skóre: 39
| blog: Vejšplechty
.
24.3.2015 22:21
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
Univerzální benchmark by se mi líbil, nejlíp ve dvou provedeních:
- předkompilovaný - výsledky by se daly přímo porovnávat. Nejlíp jako LiveCD s pevnou verzí benchmarku, kernelu,..
- s možností kompilace u uživatele. To by dalo uživateli skvělou možnost zkompilovat benchmark s parametry podle distribučních balíčků, potom s parametry na míru jeho procesoru a porovnat rychlost výpočtů. Konkrétně třeba AMD Bulldozer, údajně na tom nebyl výkonově vůbec špatně, ale tehdejší benchmarky jeho výkonu nedokázaly využít (někde byl článek o gcc a kompilaci pro bulldozer, kde to autor vysvětloval).
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
/proc/cpuinfo a nepočítají s tím, že by tam ten řádek najednou nemusel být. Na druhou stranu ale nemá smysl se nějak moc snažit, aby co nelépe vystihovala "rychlost procesoru", protože tuhle úlohu neplnila moc dobře nikdy (a ani to nikdy nebylo účelem) a už hodně douho ji neplní vůbec. To je to, co (někteří) vývojáři ARM architektury nepochopili, takže to nakonec vedlo k uraženým reakcím typu "tak já to prostě udělám tak, že to vždycky ukáže jedničku, a bude vymalováno".
tak já to prostě udělám tak, že to vždycky ukáže jedničku, a bude vymalovánoMě to přijde jako rozumné řešení. To číslo přeci (už) nemá smysl, takže jestli tam je jednička nebo jakákoliv jiná hodnota je téměř jedno.
7.4.2015 16:37
Otto Šabart | skóre: 13
| blog: KatiePC blog