Mozilla představuje Firefox Enterprise určený jako podnikový prohlížeč pro organizace s přísnými požadavky na bezpečnost, správu a dodržování předpisů. S profesionální podporou. Dostupný je zatím ve Francii, Německu, Rakousku a Švýcarsku.
Kybernetický útok zasáhl nejméně 150 supermarketů Intermarché a několik prodejen řetězců Leclerc a Coopérative U. Chladicí jednotky napadených obchodních domů byly nastaveny na nepřetržité odmrazování a teplota v nich mnohdy vystouala až nad 50°C. Škody napáchané na chlazeném a mraženém zboží budou patrně dosahovat miliónů eur.
… více »Stát Kalifornie zažaloval výrobce 3D tiskových filamentů Polymaker. Vrchní soud San Diego County tvrdí, že firma propagací svých výrobků mezi příznivci 3D tištěných zbraní podporovala výrobu takzvaných 'ghost guns' (DIY zbraní) a že její PLA filament pro 3D tiskárny lze za těchto okolností považovat za součást určenou k výrobě střelné zbraně. Žaloba požaduje mimo jiné finanční sankce a soudní zákaz činnosti, Polymaker se hájí tím, že filament je běžný a sám o sobě legální produkt. Celý text žaloby (PDF na Google Drive).
V červnu byla představena aplikace Myna pro převod řeči na text v prostředí desktopu Ubuntu. Včera byla Myna zpřístupněna širší komunitě Ubuntu formou technologické ukázky dostupné v Ubuntu 24.04 LTS, Ubuntu 26.04 LTS a Ubuntu 26.10 s GNOME na Waylandu.
Ubuntu 27.04 bude Tenacious T-Rex.
Byla vydána nová verze 2026.4.0 "Never-slop" svobodného softwaru ScummVM (Wikipedie) umožňujícího bezproblémový běh mnoha klasických adventur na zařízeních, pro které nebyly nikdy určeny. Přehled novinek v poznámkách k vydání a na GitHubu. ScummVM oslavil 25 let. Verze 0.0.1 vyšla 8. října 2001.
Kanadský vývojář Anthony Sistilli vytvořil ironický DIY projekt parodující kamerové systémy Flock, s cílem názorně demonstrovat rizika masového sledování jaké provozují tyto komerční ALPR systémy. Z levné IP kamery a vlastního ML softwaru (napsaného s pomocí SI circa za 20 minut, kód se mi bohužel nepodařilo dohledat) běžícího v laptopu sestavil jednoduchý systém, který detekuje výhradně policejní vozidla, zaznamenává jejich SPZ a
… více »Část údajů uživatelů internetového supermarketu Rohlík byla odcizena. Kyberútočníci napadli nástroj zákaznické podpory Rohlíku, odcizili tak jména, e-mailové adresy, v některých případech také telefonní čísla nebo přepisy komunikace mezi klienty a zákaznickou podporou. Rohlík incident nahlásil příslušným orgánům a přijal příslušné opatření, aby zamezil podobným případům v budoucnosti, uvedla firma.
Aplikace eDoklady fungovala v obou volebních dnech stabilně a prakticky bez front. Digitální a informační agentura (DIA) odhaduje, že se digitálním dokladem prokázalo více než 100.000 voličů. Aplikaci si před volbami či během nich aktualizovalo 247.517 uživatelů. Nových registrací bylo 19.431 a do aplikace se přihlásilo 357.879 lidí. Největší nápor přišel bezprostředně po otevření volebních místností mezi 14. a 16. hodinou, kdy si
… více »Začal semestr, začal i podzim a kromě hub rostou jako po dešti i veřejné dílny v Praze. Nedávno strahováci referovali o hackerspacu Bordel, nyní se otevřela dílna Dejvice Lab jen kousek od ČVUT. Na blížící Virtuální Bastlírně tak uslyšíte nejen report z návštěvy dílny HWLab, ale i řadu novinek, událostí a úsměvných momentů, které se za poslední měsíc ve světě techniky, ale i vědy udály. Připojte se tedy již v úterý 13.10. od 20:00 a zapojte se do
… více »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“.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz