Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
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.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Aktuální vývojová verze jádra je 3.13-rc1 vydaná 22. listopadu. Nakonec bylo během tohoto začleňovacího okna přetaženo 10 518 neslučovacích změn. Nyní začíná fáze stabilizace, přičemž konečná verze 3.13 by měla vyjít ke konci roku.
Stabilní aktualizace: za poslední týden žádné nevyšly. Verze 3.12.2, 3.11.10, 3.10.21 a 3.4.71 se aktuálně revidují; jejich vydání můžeme očekávat 28. listopadu nebo později. Pozor na to, že 3.11.10 bude poslední aktualizací v řadě 3.11.
U futexů víra nestačí. Buď jim zcela rozumíte, nebo je zkrátka necháte na pokoji.
Z vašeho popisu to vypadá, že se SPECTRE vlastně snaží operačním systémům práci trochu ušetřit, a to definicí standardní hardwarové platformy. Pokud toto opravdu vyjde a lidé od hardwaru to moc nezkazí, pak se nemusí nad podporou tohoto hardwaru váhat a nevidím zásadní problém s přidáváním podpory ACPI pro něj. [...]
Bohužel není v této fázi možné vědět, jaká práce je pro SPECTRE doopravdy relevantní a jaká ne, a proto nemůžeme pro ARM64+ACPI začleňovat cokoliv konkrétního, dokud nebudeme mít přístup ke skutečným specifikacím nebo dokud nedostaneme video od někoho s monoklem a kočkou v klíně, který by nám požadavky osvětlil.
Po letech práce je konečně dostupná verze 1.0 nástroje pro checkpoint/restore (kontrolní bod/obnovu). Jde převážně o nástroj postavený nad uživatelským prostorem, který dokáže uložit stav sady procesů do stálého úložiště a někdy v budoucnu jej obnovit, možná i na jiném systému. Více o aktuálním stavu této funkčnosti se dozvíte v tomto článku.
Dva vývojáři Btrfs – Chris Mason a Josef Bacik – současně oznámili svůj přechod z Fusion IO do Facebooku. Chris k tomu říká: Z pohledu Btrfs se toho moc nemění. Všechny mé příspěvky do Btrfs zůstanou otevřené a nadále budu svou práci dělat v upstreamu. Josef k tomu dodává: Facebook usiluje o úspěch Btrfs, takže z pohledu mého zapojení v projektu se toho moc nezmění, nadále budu spravovat btrfs-next a pracovat na stabilitě.
Dne 22. listopadu Linus vydal Linux 3.13-rc1 a uzavřel začleňovací okno 3.13, možná že o několik dnů dříve, než vývojáři čekali. Včetně několika opožděných commitů po -rc1 bylo v tomto vývojovém cyklu zařazeno nějakých 10 600 neslučovacích sad změn; to je přibližně 700 od souhrnu z minulého týdne.
Mezi nimi je jen několik významných změn viditelných uživatelům:
Mezi změny viditelné vývojářům patří:
Nyní může započnout stabilizace.
ACPI nebylo v době prvního začlenění do jádra zjevnou předností. Standard byl nový, implementace nebyly spolehlivé a jeho podpora znamenala přidání velkého virtuálního stroje do jádra. Po celé roky bylo bootování s vypnutým ACPI první odpovědí na spoustu problémů; doteď se dá najít řada stránek, které toto čtenářům doporučují. ACPI si ale povětšinou získalo postavení povinné části standardu PC platformy. Teď to ale vypadá, že se podobný příběh odehraje ve světě ARM.
Už několik let se šušká o tom, že by se ACPI mělo na ARM objevit, hlavně pak na serverových systémech. Nedávno se objevil jistý kód, který by takové systémy měl podporovat; Olof Johansson, jeden ze správců stromu arm-soc, se na kód podíval a nelíbil se mu:
Čím více vidím raného kódu pro UEFI/ACPI, tím jistější si jsem, že tyhle sračky v jádře nechceme. Věci jsou kvůli tomu znatelně zmatenější a zatímco se snažíme vše převést na DT – tak tuto snahu budeme přerušovat jen kvůli tomu, abychom přidali ještě více šablonovitého [boilerplate] kódu a celkovému postupu tak ublížíme.
V této a několika následujících zprávách Olof ujasnil, co se tím snažil říci. Svět ARM už má mechanismus pro popis hardwaru – stromy zařízení – a ten se teprve teď dostává na výsluní. Přidání podpory pro strom zařízení si vyžádalo změny ve spoustě ovladačů a kódu platforem; podpora ACPI by znamenala dvojnásob práce a druhou cestu v kódu pro konfiguraci v systému, která by musela být navždy udržována. Ještě horší pak je to, že pro ACPI v provedení ARM nejsou žádné zavedené standardy a nikdo neví, jak má co fungovat a to, co se objevuje v počátcích, není moc povzbuzující. Přidání podpory pro ARM ACPI by znamenalo zavázat se k podpoře pohybujícího se cíle donekonečna.
Olof pak navrhl, že by možná bylo nejlepší počkat, než ostatní přijdou na to, jak má ACPI na ARMu fungovat:
Ale moment, lidi, co tohle dělají už celá léta, tu vlastně máme. Microsoft. Oni by se za to měli postavit a vytrpět si to. Jakmile bude platforma připravená pro jejich potřeby, tak si to u sebe pořešíme. Konec konců, tohle na x86 zafungovalo docela dobře.
Dodal, že dokud se neobjeví systémy s ACPI a Windows a nebudou fungovat dobře, pak by se měla linuxová komunita držet od ACPI na ARMu daleko. Pokud by se systémy s ACPI opravdu dostaly na trh, pak by podle něj bylo možné je podporovat s vrstvou, která by před bootem přeložila systémové tabulky ACPI do formátu stromu zařízení.
Nesouhlas s tímto postojem se objevil v několika podobách. Několik lidí poukázalo na to, že standardy vyvinuté Microsoftem nemusí linuxové komunitě vyhovovat tak, jak bychom byli rádi. Takto to vyjádřil Mark Rutland (správce vazeb stromu zařízení):
Nejsem si jistý, že je úplně rozumné předpokládat, že se do toho vloží Microsoft a vyvine standardy, které pro nás budou užitečné nebo třeba jen použitelné na většině systémů, které mohou existovat. Pokud se do toho vloží, pak my (na základě předpokladu, že Linux by měl běžet všude tam, kde může běžet jiný OS) budeme muset podporovat všechny standardy, co vytvoří.
Russell Kind přidal další připomínku, kterou mnoho lidí opakovalo: odmítnout podporu ACPI by komunitu připravilo o možnost ovládat (nebo dokonce řídit) rozvoj standardu. Jeho slovy:
Máme možnost definovat, jak chceme, aby ACPI vypadalo: máme možnost mít vlastnosti (properties) v ACPI, které budou používat stejné názvy, jako máme v DT (stromu zařízení).
Postavit se k ACPI zády by podle Russella bylo rozhodnutím, kterého by komunita z dlouhodobého hlediska litovala.
K diskuzi se připojil Jon Masters a prohlásil, že servery na bázi ARM půjdou cestou ACPI, slovy všichni velcí hráči budou ACPI používat, ať se vám to líbí, nebo ne. Řekl, že oblast serverů potřebuje standardizovaný a pevný standard, a podle něj je abstrakce ve stromu zařízení příliš nestabilní, aby byla použitelná (což je tvrzení, proti kterému se Grant Likely silně ohradil). Red Hat podle Jona plně stojí za ACPI na serverech ARM ve všech produktech, o kterých nikdy neřeklo, že je bude kdy nabízet. Jonovo vyjádření, které napovídá, že vše už bylo v konferenčkách pod zámkem NDA rozhodnuto, mu na jeho stranu nezískalo mnoho fanoušků, ale jeho postoj zůstává stejný: systémy s ACPI se na trhu objeví a Linux se s nimi musí nějak poprat.
To ale pořád neodpovídá na otázku, jak se s nimi poprat. Arnd Bergman naznačil, že ACPI nemusí pro komunitu ARM představovat dlouhodobý problém:
Myslím si, že stále můžeme ACPI na ARM64 považovat za začátečnickou chybu a pro několik systémů, které se s tím budou dodávat, můžeme poskytnout ručně napsané bloby s DT. Hlavním důvodem to tak udělat bylo očekávané množství serverů s Windows RT, ale WinRT se teď moc dobře nedaří, takže není úplně mimo očekávat, že to dopadne jako tablety s WinRT.
Mnoho lidí si ale myslí, že ACPI by nevymizelo, takže komunita bude muset přijít na způsob, jak se s ním vypořádat.
Jednou možností by mohl být Olofův nápad překládat tabulky ACPI do stromu zařízení, ale tento postup si nezískal příznivce. Mnoho lidí jej považuje za řešení problůmu, které povede k nekončícím problémům; je tu také problém s během kódu v ACPI Machine Language (AML), který se nachází ve firmwaru ACPI. AML může být nezbytné pro inicializaci hardwaru a správu výkonu, ale nemá obdobu ve stromech zařízení. Obecně byla nálada taková, že pokud má být ACPI na systémech ARM podporováno, pak by mělo být podporováno řádně a ne za nějakou překladovou vrstvou.
Z krátkodobého hlediska ale nějaký překlad do stromu zařízení – buď při bootu nebo ručně – bude asi výsledkem. Přidání kódu pro podporu systémů s ACPI, co se mohou v blízké době objevit, může řadě lidí připadat jako dlouhotrvající břemeno kvůli krátkodobě existujícím systémům. Věci by mohly změnit systémy, které podle popisu Arnda jsou PC bez CPU s x86 a s čipem ARM místo něj; přidání podpory ACPI pro takové stroje by podle jeho slov bylo dostatečně neškodné. Vypadá to ale, že Arnd je silně proti přidání podpory ACPI pro komplikované systémy ve stylu ARM.
Z dlouhodobějšího hlediska je pravděpodobné, že komunita bude sledovat situaci a vyčkávat. Bude probíhat úsilí o řízení rozvoje ACPI pro systémy ARM; zejména Linaro pak má vývojáře, jež jsou do tohoto procesu zapojeni. A i Olof je otevřen přidání podpory pro ACPI někdy v budoucnu, jakmile jeho příznivci se na tom už nějak shodli, vyřešili své vrtochy a dali dohromady použitelnou stabilní platformu. To ale podle něj může trvat roky.
Microsoft díky své dominanci na trohu softwaru pro systémy typu PC mohl protlačit hardwarové standardy, jakkoliv se mu zlíbilo. Ve světě ARMu má Linux stejně silné postavení, takže by bylo trochu překvapivé být v postavení toho, kdo někoho dohání. Částí problému je ovšem to, že za Linuxem nestojí jediný silný hlas, který by jej zastupoval u stolu, kde se plánují standardy; firmy jako Linaro a Red Hat tento problém řeší, ale určitě nezastupují nebo ani zdánlivě nemluví na toto téma se zbytkem komunity. Skutečnost, že tato práce probíhá pod dohodou o mlčenlivosti (NDA), tomu moc nepomáhá; NDA nejde moc dohromady s tím, jak komunitní vývoj probíhá.
Nakonec se to ale jistě vyřeší; je obtížné si představit úspěch jakéhokoliv hardwaru na bázi ARM bez řádné podpory v Linuxu. Je to hlavně otázkou, jak mnoho kráto a dlouhodobých obtíží bude potřeba snést, aby přišla podpora na svět. Po porodních bolestech se ACPI ve světě x86 povětšinou vyřešilo; možná se mu dostane užitečného postavení i na trhu s ARM.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
„few“ znamená „řada“, „spusta“ORLY?