Projekt openSUSE dnes, 3. listopadu 2026, oficiálně vydal openSUSE Leap 16.1, novou verzi své stabilní linuxové distribuce. Novinkou je také Immutable Mode, který nahrazuje dosavadní samostatnou distribuci openSUSE Leap Micro. Podrobnosti o novém vydání najdete v oficiálním oznámení nebo v českém překladu oznámení. Instalační obrazy jsou již dostupné na get.opensuse.org. Vydání společně oslavíme v pátek ve virtuálním baru a na … více »
Bylo oznámeno vydání Fedora Linuxu 45. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora Cloud pro cloudové nasazení, Fedora CoreOS pro ty, kteří preferují neměnné systémy a Fedora IoT pro internet věcí. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách
… více »Vědci z MIT CSAIL představili koncept 'weight-space programming' a názorně předvedli, že pokročilé jazykové modely SI dokážou přímo číst a upravovat váhy neuronových sítí. Studie ukazuje, že modely nejen dokážou identifikovat účel sítí z pouhého nahlédnutí do jejich číselných vah, ale mohou i cíleně opravovat chyby a nedostatky, například GPT-6 Astra se změnou pouhých 0,016% vah open-weight modelu Qwen3.5-0.8B podařilo odstranit
… více »Organizátoři komunitního setkání nejen českých a slovenských správců sítí CSNOG 2027, které se uskuteční 20. a 21. ledna na půdě zlínské univerzity Tomáše Bati, oznámili prodloužení termínu pro zasílání abstraktů do programu akce. Zájemci se mohou hlásit prostřednictvím webu setkání do úterý 10. listopadu. Programová komise uvítá příspěvky věnované nejen správě sítí, ale také legislativě a regulaci nebo síťařským aktivitám studentů a pedagogů.
Bylo spuštěno předobjednávání zařízení Flipper One s Linuxem. Za 20 dolarů si lze koupit kupón a zajistit si tím speciální cenu 379 dolarů po spuštění kampaně na Kickstarteru.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 16.0. Postaven je na Firefoxu ESR 153. Vydána byla také nová verze 7.16 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. S Tor Browserem 16.0.
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.
Velkým problémem našeho oboru je neustále rostoucí komplexita softwaru. Tomuto tématu se věnuje seriál tří článků na blogu Frantovo.cz. První díl vysvětluje, co to komplexita je a proč představuje problém. Druhý se zabývá příčinami jejího vzniku. Třetí díl je věnován možným řešením komplexity softwaru a prevenci.
Tiskni
Sdílej:
Generické programování je podporované v řadě jazyků. Může být implementováno různými způsoby – např. v Javě nebo Rustu jsou to generika zatímco v C++ nebo D jsou to šablony. Na první pohled vypadají stejně a je tam dost velký překryv (základní využití v kolekcích). Ale oba přístupy mají svoje specifika a umí něco, co ten druhý přístup neumožňuje. V případě šablon se v podstatě kód v době kompilace rozkopíruje do tolika variant, s kolika typy jsme danou šablonu použili jinde v kódu. Kdežto u generik jde spíš o typovou kontrolu v době kompilace + přetypování v době běhu (kód je stále tentýž a pracuje s obecnými objekty). V obou případech se ale jedná o velice hodnotnou vlastnost programovacího jazyka.Tohle není úplně pravda... IMO není dobrý to pojmenovávat generika versus šablony, spíš mluvíš o rozlišení type-erasure versus monomorphisation. Generika v Javě jsou implementována tím prvním způsobem, kdežto v C++, Rustu a (AFAIK) D tím druhým. Generika v Rustu nefungují jako v Javě, ten overhead boxingu generických věcí by byl nepřijatelný. Od C++ se neliší tím, že by kompilátor nedělal kopie, ale tím, že jsou silně typovaný, tj. liší se to jen ve fázi kontroly. Nicméně po tom, co kompilátor vyhodnotí, že kód je korektní (ať už jakýmkoli způsobem), tak v obou případech nastane ta monomorfizace, tj. rozkopírování kódu. Pak tam jsou ještě nějaké další rozdíly, jako např. že v Rustu se generické definice serializují do metadat knihoven (ve formě intermediate reprezentace kódu), takže je možný je z knihovny importovat bez použití hlavičkových souborů. (A to samé platí i o makrech, btw.) Zajímavý je v tomhle ohledu IIRC C#, kde kompilátor monomorfizuje generika nad hodnotovými typy. (Ale jenom jsem to někde četl, nemam k tomu zdroj a C# nerozumim do hloubky.)
Generika v Rustu nefungují jako v Javě, ten overhead boxingu generických věcí by byl nepřijatelný.Boxování se v Javě týká jen primitivních typů a s generiky to v podstatě nijak nesouvisí. Ten problém není exkluzivní pro generika, a naopak se u generik projevit nemusí vůbec, pokud nepoužíváš primitivní typy. Obecně je overhead generik v Javě daný jen nutností dělat přetypování (resp. kontrolovat, že z generika vylezl správný typ).
Boxování se v Javě týká jen primitivních typů a s generiky to v podstatě nijak nesouvisí.Týká se všechn typů, primitivní typy se liší pouze tím, že jsou to hodnotové typy a je potřeba je zboxovat "navíc" oproti normálu. Ostatní typy jsou boxované by default. S generiky to souvisí poměrně zásadně. Důvod, proč jazyky jako C++ a Rust používají monomorfizaci je ten, že každá instance generické funkce nebo typu počítá s konkrétními vlastnostmi těch dosazenýh typů. Pokud má položka struktury generický typ, tak různé instanciace té struktury budou mít různou velikost, vevnitř různé zarovnání/padding a budou v metodách na tom typu volat různé implementace funkcí/operátorů. Což umožňuje aby hodnotové typy zůstaly v generickém kódu hodnotovými typy. S type-erasure to nejde dohromady - nemůžeš jedné funkci předat jako argument ukazetel/referenci na struktury s různým layoutem. Aby type-erasure-based generickej kód fungoval, musí být generický věci boxovaný (aby byla vždy stejná velikost a zarovnání typu) a jejich funkce/operátory se musí volat přes vtable. Odtud ten overhead. (S tím, že Java VM bude nejspíš umět ten overhead do nějaký míry zredukovat, např. inlinovat virtuální volání apod., ale úplně odstranit ho AFAIK nemůže.)
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
18.5.2020 19:32
java.lang.Object, virtuálních volání apod.
Kdyby jazyk, který tu režii jinde neplatí, chtěl generika implementovat stejně, zaplatil by tam tu režii celou najednou, čemuž se patrně bude chtít vyhnout.
a v nutnosti kontrolovat, že z generik lezou správné typy.Tohle zase trochu matě mě. Čekal bych, že když už je ten kód type-checkován kompilátorem, že už nebude potřeba správnost typu kontrolovat v runtime (samozřejmě pokud člověk udělá downcasting, tak jo). Nebo je možný třeba do kolekce v Javě nějak procpat špatný typ?
List<Integer> list = new ArrayList<>();
((List) list).add("mhm");
System.out.println(list.get(0));
Ale ono je to jedno. I kdyby tam nebyla ta instrukce checkcast v bajtkódu, JVM si stejně nakonec musí nějak pohlídat, jestli manipuluje se správným typem, aby jí nepřetekl nějaký pointer nebo whatever (jinak by to byla bezpečnostní díra jako blázen).
Takže v praxi je to tak, že nějaké checky dělá kompilátor (a občas ti dovolí takovuto šílenost), nějaké další checky nacpe do vygenerovaného bajtkódu a pak nějaké checky dělá ještě JVMko. Nakonec si to HotSpot určitě nějak vyoptimalizuje a věci, které jsou tam zbytečně, vyhází.
Čekal bych, že když už je ten kód type-checkován kompilátorem, že už nebude potřeba správnost typu kontrolovat v runtime (samozřejmě pokud člověk udělá downcasting, tak jo)To muzes predpokladat pouze u jazyku, ktere jsou kompilovany do strojoveho kodu. Z principu runtime nemuze predpokladat, ze kod byl zkompilovan spravnym prekladacem a je spravny (to by vedlo k brutalnim bezpecnostnim diram), javovsky runtime umoznuje nacitat tridy dynamicky (to by vedlo na dalsi kategorii problemu, pokud by se neprovadely kontroly i na urovni runtimu).
Skutečně je java runtime schopen zajistit bezpečnost třeba při načtení třídy z neznámého zdroje?No, to je trošku záludná otázka, ale řekněme to takhle: ano, měl by. Co jsem se kdysi díval, v čem byl bezpečnostní problém u slavných Java appletů, tak primárně nešlo o díry přímo v JVMku, ale třeba v nesprávném použití SecurityManageru ve standardní knihovně.
To by vyžadovalo nějaký sandboxing, ne? (Ve kterém by třeba naopak segfault už "nevadil"...).Proč?
Pokud není požadavkem načítat třídy z neznámých zdrojů, tak by mohly stačit nějaký metadata o verzi kompilátoru etc., ne?JVM je interpreter a měl by se chovat korektně. Mj. by nebylo dobré, aby došlo ke crashi JVM třeba kvůli zbabrané instrumentaci (modifikaci bajtkódu před načtením třídy) atd.
Proč?No, tak protože bez toho může ten importovanej kód dělat arbitrary věci, ne? Mohl by např. použít
sun.misc.Unsafe nebo nějaké JNI pro rozbití JVM. Ale i po blacklistování těhle dvou by mohl třeba házet libovolné výjimky, dělat libovolné I/O, alokovat kvanta paměti, těžit bitcoiny... Zkrátka, moc si to bez sandboxu neumim představit...
Spotřebu paměti omezíš parametrem při spouštění JVMka.Jo, ale tim ji omezíš celýmu tomu kódu..
a třeba JavaScriptový engine v prohlížeči to taky neumí.Do jistý míry jo.
Kdybych dnes potřeboval spustit nedůvěryhodný kód, izoloval bych raději asi celé JVMkoSouhlas.
Jo, ale tim ji omezíš celýmu tomu kódu..Z hlediska omezení např. spotřeby paměti je jedno, jestli sandboxuješ interpreter a věříš systému, nebo sandboxuješ program a věříš interpreteru. Ale ono jsme teď sklouzli trochu jiným směrem než byla původní debata. Původně byla řeč o té kontrole typů, co lezou z generik. Myslím si, že užitečnost těch případných chybových hlášek, když se něco podělá, za těch pár podmínek stojí. No a teprve druhá věc je, že historicky JVM byla stavěná i na spouštění nedůvěryhodného kódu a ty kontroly tam být musely i z bezpečnostních důvodů.
Do jistý míry jo.Jak? Ono jde zpomalit těžbu Bitcoinů, ale ne všechno ostatní? Možná zpomalit jen určité operace s tím, že sice je lze emulovat, ale těžba už nebude tak efektivní a vyfrknou se na to?
"Referencované typy" by bylo blíž a určitě to blíž javovské terminologii, ale není to úplně přesný, protože obecně třeba v C++ jeden typ se dá použít jako hodnotový i jako "boxovaný".Pojem referencni objektovy model se pouzival minimalne jiz v devadesatych letech a oznacuje situace, kdy se objekt chova jako skutecny objekt (ma svou identitu) a ne jako hodnota. Boxing je v jave opravdu jen zabaleni hodnoty primitivniho datoveho typu do tridy, aby se to chovalo jako skutecny objekt.
Generika v Rustu nefungují jako v Javě, ten overhead boxingu generických věcí by byl nepřijatelný.
Aby type-erasure-based generickej kód fungoval, musí být generický věci boxovaný (aby byla vždy stejná velikost a zarovnání typu) a jejich funkce/operátory se musí volat přes vtable.Co použít místo třeba "overhead boxingu"? Když řeknu "overhead referencování" tak to není to, co mam na mysli - referencování (indirekce) je jen část problému, druhá část je ta alokace toho místa, které se referencuje, a přesunutí té hodnoty do toho místa, ie. "boxing".
Dříve jsem používal slovník cizích slov velmi rád, protože mi dokázal krátce, rychle a stručně odpovědět na moje dotazy. Díky sáhodlouhým encyklopedickým příspěvkům prof. PhDr. Rudolfa Kohoutka, CSc., se však ze slovníku stal nepřehledný bordel, jehož použití je pro mě zcela strašné. Kdybych chtěl vědět víc o daných heslech, použiju jiný zdroj. Rád bych tímto inicioval omezení počtu znaků a vrátil tak slovníku původní smysl.
Proti tomuto je i ta nejvetsi prasarna v jave prochazkou po rozkvetlem paloucku.
Komplexita sestává z reality a imaginarity. Imaginaritu je třeba buď odstranit, nebo transformovat v realitu.
18.5.2020 22:56
19.5.2020 18:53
