FreeTube, desktopový klient pro YouTube využívající lokální API, byl vydán ve verzi 0.26.0. Toto velké opravné vydání mj. vrací částečnou podporu živých přenosů nebo přepracovává zobrazování titulků a obecně nastavení videa v přehrávači – FreeTube umožňuje např. přehrávat video s větším zrychlením.
Další vlna kyberútoků zasáhla chladicí zařízení supermarketů v sedmi evropských zemích, Belgii, Lucembursku, Švédsku, Nizozemsku, Irsku, Estonsku a Finsku. Mrazáky se v některých prodejnách opět 'proměnily v trouby' a zahřály až na 50°C, což pochopitelně vedlo ke znehodnocení uskladněných potravin. Útoky navazují na podobný incident ve Francii z první poloviny října letošního roku, pachatel stále není znám.
Zranitelnost v aktualizačním mechanismu WordPress umožňuje útočníkovi zasáhnout do dočasného instalačního adresáře během aktualizace jádra systému. Před aktualizací veřejně dostupného WordPressu dočasně zablokovat HTTP přístup k wp-content/upgrade/, následně aktualizovat a zkontrolovat logy. Postižené verze: WordPress 4.7 až 7.1.3.
Alpine Linux zveřejnil podrobnosti o útoku na svůj GitLab a 30. října oznámil obnovení provozu. Útočník se 20.–21. října pokusil zneužít chybu v regulárních výrazech. Exploit způsobil opakované pády workerů a několikrát se dostal do pokročilé fáze. Úspěšné spuštění kódu však nebylo potvrzeno. Fix: Opravený GitLab a současně Ruby 3.3.13, 3.4.12 nebo 4.0.9+, pokud jde o vlastní sestavení či kontejner.
Konference OpenAlt 2026 proběhne tento víkend 7. a 8. listopadu na FIT VUT v Brně. Jedná se již o 21. ročník této konference, která propojuje otevřené technologie, svobodný software, hardware a lidi, kteří chtějí věci nejen používat, ale také jim rozumět a měnit je k lepšímu. Více o konferenci v příspěvku OpenAlt 2026: technologie, které dávají svobodu na blogu spolku OpenAlt.
Eben Upton oznámil další zdražení jednodeskových počítačů Raspberry Pi. Tentokrát 16 GB varianty Raspberry Pi o 80 dolarů a 16 GB varianty Raspberry Pi Compute Module 5 o 40 dolarů. Cena Raspberry Pi 500+ se nemění.
Francouzské Národní shromáždění přijalo 30. října 2026 poměrem 11 hlasů pro, 10 proti a 14 abstencí pozměňovací návrh I-1358 ke státnímu rozpočtu na rok 2027, který zavádí daň z objemu dat doručovaných uživatelům internetu. Návrh socialistického poslance Laurenta Lhardita stanovuje sazbu 0,055 eura za gigabajt, tedy 55 eur za terabajt. Zatím nejde o platný zákon, ale o dílčí hlasování během prvního čtení rozpočtu. Daň by měli platit
… více »Nizozemská vláda ve snaze šetřit a zvyšovat efektivitu s využitím umělé inteligence (AI) hodlá zrušit asi 25.000 pracovních míst ve státní správě. Cílem je postupně dosáhnout ročních úspor až 3,5 miliardy eur (85,2 miliardy Kč). Na konci loňského roku ve státní správě pracovalo rekordních 160.000 lidí. „Nemůžeme pokračovat v tom, co jsme dělali dosud,“ uvedl státní tajemník pro efektivní fungování vlády Eric van den Burg. „Proto
… více »Google Chrome 154 byl prohlášen za stabilní. Nejnovější stabilní verze 154.0.8037.57 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Opraveno bylo 108 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Tiskni
Sdílej:
Je to prostě chromé. Co bys od toho taky čekal 8-P
Koľko kódu sa odstránilo pri prechode z MK68 na PPC, koľko počas následovného prechodu na Intel, a koľko počas prechodu na ARM? A koľko chýb to prinieslo? A koľko z toho je stále neopravených?
Tuhle konverzaci vygenerovala funkce Duck.ai (https://duck.ai) pomocí modelu GPT-5.6 Luna od společnosti OpenAI. Chaty s umělou inteligencí můžou zobrazovat nepřesné nebo urážlivé informace. Další informace najdeš tady: https://duckduckgo.com/duckai/privacy-terms.
====================
1. z 1 pokynů uživatele - 26. 9. 2026 12:07:47:
Koľko kódu sa odstránilo pri prechode z MK68 na PPC, koľko počas následovného prechodu na Intel, a koľko počas prechodu na ARM? A koľko chýb to prinieslo? A koľko z toho je stále neopravených?
GPT-5.6 Luna:
<!-- **Clarifying Apple's transitions**
I want to clarify the significant transitions Apple made, like from 68k to PPC, then Intel, and finally ARM. It seems like understanding these changes is essential for a thorough answer. I’ll need to do some research to gather the right information and ensure everything is accurate. So, I'll search the web for details about these transitions. Let's figure this out together! -->
<!-- -->
Ak myslíš **Apple a prechody architektúry Macov — 68k → PowerPC → Intel → Apple Silicon/ARM**, tak na tieto otázky neexistujú verejne doložené súhrnné čísla.
Apple nezverejnila:
- koľko riadkov kódu sa pri jednotlivých prechodoch odstránilo,
- koľko riadkov sa prepísalo alebo iba prekompilovalo,
- koľko chýb bolo spôsobených konkrétnou migráciou,
- ani koľko z týchto chýb zostalo dodnes neopravených.
Prehľad teda vyzerá takto:
| Prechod | Verejne známe odstránené riadky | Verejne známe chyby spôsobené prechodom | Stále neopravené |
|---|---:|---:|---:|
| 68k → PowerPC, 1994 | neznáme | neznáme | neznáme |
| PowerPC → Intel, 2005–2006 | neznáme | neznáme | neznáme |
| Intel → Apple Silicon/ARM, od 2020 | neznáme | neznáme | neznáme |
Dôvod je aj metodologický: nejde o jeden projekt s jasnou hranicou. Pri každom prechode sa menili naraz operačný systém, ovládače, frameworky, kompilátory, aplikácie a vývojárske nástroje. „Odstránený kód“ môže znamenať odstránený assembler, odstránené vetvy pre starú architektúru, celý emulačný subsystém alebo jednoducho kód, ktorý sa nahradil spoločnou implementáciou. Bez interného repozitára a histórie zmien sa to nedá spoľahlivo spočítať.
Čo sa dá potvrdiť:
- Pri prechode **68k → PowerPC** PowerPC Macy naďalej spúšťali 68k programy pomocou emulácie; kód oboch architektúr sa dokonca mohol nachádzať v jednom binárnom súbore.
- Pri prechode **PowerPC → Intel** Apple použila Rosettu a univerzálne binárky. Prvé Intel Macy sa objavili v januári 2006 a prechod bol dokončený približne za 210 dní. [1]
- Pri prechode **Intel → ARM64** Apple použila Rosettu 2 a univerzálne binárky. Rosetta 2 prekladá x86-64 kód pri prvom spustení alebo počas behu podľa typu kódu. [2]
- Samotný prechod preto nevyžadoval prepísanie všetkých aplikácií: veľká časť kódu sa jednoducho znovu skompilovala pre novú architektúru, zatiaľ čo staršie binárky sa dočasne spúšťali cez emuláciu alebo preklad. Pri prechode na Apple Silicon bola veľká časť práce na jednotlivých vývojároch, nie iba na Apple. [3,4]
Aj počet „chýb“ je nedefinovateľný. Dá sa počítať počet bug reportov označených ako architektúrne, počet regresií, pády aplikácií, problémy s ovládačmi alebo všetky hlásenia používateľov počas prechodného obdobia — každá definícia dá iné číslo. Navyše staré chyby, ktoré sa nikdy neodstránili, sa nedajú spätne spoľahlivo priradiť ku konkrétnemu prechodu.
Najpresnejšia odpoveď je preto: **Apple tieto údaje nezverejnila a z verejných zdrojov sa nedajú poctivo vypočítať. Ak niekde existuje konkrétne číslo, pravdepodobne ide o odhad pre určitú časť systému, nie o celkový účet za celý Mac ekosystém.**
Další čtení
[1] Mac transition to Intel processors — https://en.wikipedia.org/wiki/Mac_transition_to_Intel_processors
[2] Rendering on the Apple M1 Max Chip - Code & Visuals — https://blog.yiningkarlli.com/page6/
[3] Support Apple's transitioning of Macs to new ARM CPU & ... — https://github.com/BOINC/boinc/issues/3827
[4] Apple nailed the transition to M1 Apple Silicon. Why are so many ... — https://forums.appleinsider.com/discussion/220691/apple-nailed-the-transition-to-m1-apple-silicon-why-are-so-many-mac-developers-blowing-it
Áno, ako hrubá intuícia to pravdepodobne sedí: za celé desaťročia vývoja macOS sa odstránilo a prepísalo omnoho viac kódu, než by zodpovedalo iba bežnému týždennému vydávaniu s pomerom „90 % opravy, 10 % mazanie“.
Nedá sa však z toho odvodiť presné porovnanie, pretože:
nová verzia každý týždeň môže obsahovať veľa nového kódu, nielen opravy,
mazanie starého kódu často sprevádza jeho úplné prepísanie,
architektonický prechod mení aj build systém, ABI, ovládače, knižnice a testy,
chyby po prechode nemusia byť nové chyby; niektoré sú iba odhalené staré predpoklady,
„neopravený bug“ sa nedá spoľahlivo priradiť ku konkrétnemu prechodu.
Takže rozumné zhrnutie by bolo:
Architektonické prechody pravdepodobne odstránili alebo prepísali veľké objemy kódu, pričom väčšina zmien nebola viditeľná ako samostatné používateľské bugfixy. Neexistujú však dáta, ktoré by dovolili tvrdiť konkrétny pomer, napríklad 90:10.
A ešte jedna dôležitá vec: prechod na novú architektúru zvyčajne neprináša iba viac chýb. Zároveň odstráni celé triedy starých chýb a neudržiavateľného kódu. Používateľ však najviac vidí regresie, takže subjektívne to môže pôsobiť ako „nové problémy namiesto opravených“.