Iniciativa Open Device Partnership (ODP) nedávno představila projekt Patina. Jedná se o implementaci UEFI firmwaru v Rustu. Vývoj probíhá na GitHubu. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0. Nejnovější verze Patiny je 13.0.0.
Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.
Typst byl vydán ve verzi 0.14. Jedná se o rozšiřitelný značkovací jazyk a překladač pro vytváření dokumentů včetně odborných textů s matematickými vzorci, diagramy či bibliografií.
Specialisté společnosti ESET zaznamenali útočnou kampaň, která cílí na uživatele a uživatelky v Česku a na Slovensku. Útočníci po telefonu zmanipulují oběť ke stažení falešné aplikace údajně od České národní banky (ČNB) nebo Národní banky Slovenska (NBS), přiložení platební karty k telefonu a zadání PINu. Malware poté v reálném čase přenese data z karty útočníkovi, který je bezkontaktně zneužije u bankomatu nebo na platebním terminálu.
V Ubuntu 25.10 byl balíček základních nástrojů gnu-coreutils nahrazen balíčkem rust-coreutils se základními nástroji přepsanými do Rustu. Ukázalo se, že nový "date" znefunkčnil automatickou aktualizaci. Pro obnovu je nutno balíček rust-coreutils manuálně aktualizovat.
VST 3 je nově pod licencí MIT. S verzí 3.8.0 proběhlo přelicencování zdrojových kódů z licencí "Proprietary Steinberg VST3 License" a "General Public License (GPL) Version 3". VST (Virtual Studio Technology, Wikipedie) je softwarové rozhraní pro komunikaci mezi hostitelským programem a zásuvnými moduly (pluginy), kde tyto moduly slouží ke generování a úpravě digitálního audio signálu.
Open source 3D herní a simulační engine Open 3D Engine (O3DE) byl vydán v nové verzi 25.10. Podrobný přehled novinek v poznámkách k vydání.
V Londýně probíhá dvoudenní Ubuntu Summit 25.10. Na programu je řada zajímavých přednášek. Zhlédnout je lze také na YouTube (23. 10. a 24. 10.).
Gemini CLI umožňuje používání AI Gemini přímo v terminálu. Vydána byla verze 0.10.0.
Konference OpenAlt 2025 proběhne již příští víkend 1. a 2. listopadu v Brně. Nabídne přibližně 80 přednášek a workshopů rozdělených do 7 tematických tracků. Program se může ještě mírně měnit až do samotné konference, a to s ohledem na opožděné úpravy abstraktů i případné podzimní virózy. Díky partnerům je vstup na konferenci zdarma. Registrace není nutná. Vyplnění formuláře však pomůže s lepším plánováním dalších ročníků konference.
Já odpovídám: k ničemu!
Doufám, že to tady nikdo nebude brát moc vážně, možná jsem to do toho zápisku měl napsat. Vyrobil jsem Mašinku jen tak pro zábavu a pro odreagování a podělil jsem se s ní proto, protože jsem měl dojem, že by někoho mohla možná taky zajímat.
), tak už se to tady i celkem dá. :-P
Hlavně se teď proboha nic neuč, nic nedělej, flákej se, chlastej a užívej si života, dokud ti nezačne semestr, dobře ti radím (a tuhle ufolog amigapower se mnou určitě bude souhlasit ). V semestru tohle všechno sice můžeš taky, ale už to prostě není vončo.
já se ten Python chtěl naučit a vždycky upřednostňuju učení se tím, že si rovnou zašpiním rucetaky jsem se vzdycky chtel naucit python... do te doby nez jsem v nem musel naprogramovat par veci... a teda abych pravdu rekl, radsi se bez nej obejdu.
) díky Schemikovi, tak se ptám: co pro tyhle účely používáš ty? Píšeš všechny tyhle věci ve Scheme?
Nerad bych se tu pouštěl do dalšího nekonečného flamu o Pythonu, jako odpověď mi bude stačit jméno jazyka.
co pro tyhle účely používáš ty?velice casto na takove to domaci programovani pouzivam Bash... protoze to casto zacne jako jeden nevinny prikaz treba v sedu, ktery casem nabobtna o par rour a nejaky ten for cyklus az je z toho program. ;-] jako to se musi shellu nechat moznosti kompozice funkci jsou fakt slusne... horsi je to s vykonem... to pak nekdy sahnu i po tom pythonu... ale v posledni dobe hlavne po schemiku ;-] no a pokud potrebuju vykon, tak pouzivam spis SBCL nebo stare dobre Cecko... a priznam se bez muceni, ze obcas neco narychlo sbastlim i v PHP nebo Jave... imho, kazdy z jmenovanych jazyku se hodi na neco jineho a u kazdeho jsem narazil na nejaky problem, ktery me dokaze vytocit do bela... tak taky doufam, ze se to nezvrhne do flamu... ale porad lepsi flame o programovacich jazycich, nez politice...
Škoda, že do téhle problematiky moc nevidím....to obcas nemusi byt na skodu. ono neni nad to, kdyz clovek zjisti sam, jak se veci ve skutecnosti maji. treba ty vecne spory o tom jestli ma byt procesor zasobnikovy nebo registrovy...
Mimochodem, vybičovat mou zlenivělou vysokoúrovňovou mysl k napsání a odladění toho trapného faktoriálu v assembleru o kus výše mě stálo skoro stejně mnoho intelektuálního úsilí, jako napsat celou Mašinku dohromady v Pythonu. Člověku, který je zvyklý psát v "normálních" jazycích, se to skoro ani nezdá. Ty kompilátory a všelijaké další černé skříňky oddřou fakt hodně práce. A co teprv lidi, kteří je tvoří. Klobouk dolů.
Asi proto, že je to nesmysl.
Python nemá assembler žádný, je to čirý interpretr – tedy pokud hovoříme o defaultním C Pythonu
JVM, stejně tak .NET VM (IL) mají zásobníkový automat – jejich asm je tak jednoduchý, že snadno pochopíte z pohledu, o co se jedná.
virtuální assemblery Javy a .NETu mají navíc metadata, bez kterých to nejde – tedy řadu dalších přídavných dat, názvů, proměnných, objektů atd., které musí vurtuální mašina dostat, jinak to nefachá. a metadata jsou dost vysokoúrovňává data. navíc samotný asm má některé vysokoúrovňové instrukce zejména z řad práce s třídami. plus garbage collector – asm ví, co má kde za data, jakého typu, jakých názvů, zná třídy, metody, parametry, atd..
i386 je naproti tomu čistý asm – prostě sekvenčně vykonává instrukce. nepotřebuje žádná metadata, ani znát datové high level typy toho co vykonává.
jak vidíte, porovnávat se to rozumně nedá
Python má bytekód, tedy zparsovaný kód Pythonu. Nazývat to assemblerem je poněkud hodně moc silné kafe. Ale opravdu silné kafe.
Python nemá assembler žádný, je to čirý interpretr – tedy pokud hovoříme o defaultním C Pythonu.No, pokud si mám vybrat mezi panem Ponkrácem a dokumentací modulu disassembleru (C)Pythonu, hádejte, komu budu věřit
Takže pro původního tazatele - Python má svůj bytecode i virtuální stroj, který je uložený v těch 
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz.pyc a .pyo souborech (ty druhé by měly být optimalizované, ale prakticky jsou jenom stripnuté). Jedná se o zásobníkově orientovaný assebler/bytecode*, který má hromadu vysokoúrovňových operací - prakticky jakákoli vlastnost Pythonu má svoji instrukci.
* pro virtuální stroje je lepší používat termín bytecode, ale vzhledem k tomu, že ten javový umí některé ARM mašinky provádět nativně, asi je tohle rozdělení spíše akademické.
Jen v té dokumentaci Pythonu je psáno: „Since there is no Python assembler, this module defines the Python assembly language.“ (Ačkoli neexistuje žádný Python assembler, … atd.) ale pan Vyskočil je chytřejší.
Python má bytekód, tedy zparsovaný zdroják Pythonu. Dokonce opravdu jenom zparsovaný, nemá fakticky ani žádnou optimalizaci. Marketinkoví, P.R. a jiní mlžící a lži vydávající odborníci by to nazvali „vysokoúrovňovým assembler“, nebo „assemblerem s vysokoúrovňovými operacemi“, ale fakticky je to jenom mírně přechroustaný zdroják. To také mohu říci, že „Linux je jen jinak koncipované Windows“, nebo „linuxová komunita je komunita příznivců Microsoftu s menší loajalitou k Microsoftu“ a budou to stejně pravdivé věty se stejně překroucenými political corectness výrazu jako mluvit o Pythonovském (velmi neforemném a hrubém, neoptimalizaovaném parsingu zdrojáku) jako o „assembleru“.
Jen v té dokumentaci Pythonu je psáno: „Since there is no Python assembler, this module defines the Python assembly language.“ (Ačkoli neexistuje žádný Python assembler, … atd.) ale pan Vyskočil je chytřejší.pan ponkrac by v diskuzi mohl laskave zacit rozlisovat terminy -- assembly language a assembler, do cestiny se to preklada tusim jako, jazyk symbolicky adres a assembler (se nepreklada).
Python má bytekód, tedy zparsovaný zdroják Pythonu.doporucuji dostudovat pojem bytecode, abyste zjistil, ze bytecode != zparsovany zdrojak.
pan ponkrac by v diskuzi mohl laskave zacit rozlisovat terminy -- assembly language a assembler, do cestiny se to preklada tusim jako, jazyk symbolicky adres a assembler (se nepreklada).
Mohl byste si laskavě ještě jednou přečíst co píšu?
doporucuji dostudovat pojem bytecode, abyste zjistil, ze bytecode != zparsovany zdrojak
V případě Pythonu fakticky jde o rovnost. Píšeme tu v kontextu Pythonu.
Já jsem nikde netvrdil, že bytekódu je zparsovaný zdroják, ale tvrdil jsem, že v případě Pythonu jde o fakticky zparsovaný zdroják.
,,Since there is no Python assembler, this module defines the Python assembly language..'' (Ačkoli neexistuje žádný Python assembler, … atd.)to ze neexistuje ,,assembler'' neznamena, ze neexistuje ,,assembly language'', ktery tento modul definuje.... i.e., tento ,,assembly langauge'' je izomorfni vzhledem k bytecodu, stejne tak jak je izomorfni jazyk symbolickych adres vuci jazyku stroje.
Já jsem nikde netvrdil, že bytekódu je zparsovaný zdroják, ale tvrdil jsem, že v případě Pythonu jde o fakticky zparsovaný zdroják.ale tvrdil: Python má bytekód, tedy zparsovaný kód Pythonu.
Jestli chcete, já Vám nadefinuje deset různých assemblerů pro Python. Teoreticky. Akorát nebudou v základním interpreteru.
Jakákoli snaha o to udělat z byte kódu něco jiného, než přechroustaný zdroják narazí z druhé strany na to, že Python nehodlá nic stabilizovat. Ba dokonce nějaká snaha neměnit syntaxi, byte kód, či cokoli jiného velmi rychle narazí na odpor samotného autora Pythonu a jeho stejnou myšlenkou nakažených příznivců.
Když do toho budeme šťourat najdeme leccos, akorát je to v praxi k (autocenzura). Python mimo jiné běží i na JVM, stejně tak jako na .NET mašině, kde běží mnohem rychleji právě z toho důvodu, že běží na solidním byte kódu / assembleru, a ne na přechroustaném zdrojáku tak jak to standardní Python předvádí.
ale tvrdil: Python má bytekód, tedy zparsovaný kód Pythonu.
Kontext! Já se fakt moc omlouvám, ale nepíšu právnické texty s paragrafy, citacemi a odkazy na předchozí věty. Pokud se mluví a několik příspěvků jde o Pythonu, mluvím v kontextu Pythonu. Standardní Python (tedy ne žádné zbožné přání nějakého Python modulu) nemá jiný byte kód, než fakticky plus mínus přeparsovanou syntaxi.
Ani nemůže mít nic jiného, protože když autor Pythonu neustále přeorává co se dá, a neustále se píší nové a nové parsery syntaxe a další – pak na optimalizaci, nebo tvorbu nějakého slušného byte kódu nezbývá čas a Python to pak musí dělat jen velmi povrchně.
Dále už odmítám odpovídat na hnidopišské rýpání do slov od lidí, kteří neumí dát do kontextu několik vět a nejsou s to pochopit význam textu, pokud je nutné si dát dohromady sdělení ve dvou následujících větách po sobě.
pro virtuální stroje je lepší používat termín bytecode, ale vzhledem k tomu, že ten javový umí některé ARM mašinky provádět nativně, asi je tohle rozdělení spíše akademické.
Spíše pro JVM se dá použít i výraz assembler, stejně tak jako pro řadu dalších jazyků. Java má stabilní byte kód / aassembler, který je standardizzovaný a relativně neměnný.
Python nic takového nemá, v každé verzi Pythonu je to jinak. Byte kód z verze x.y nepoužijete dost dobře ve verzi x.z (za předpokladu y <> z pro matematické šťouraly).
Python se totálně brání ustálit a standardizovat i syntaxi jazyka, natož teprve svůj byte kód. Python má filozofii „strašně nás baví všechno měnit a často to děláme jen proto, že je to príma, a bavíme se tím“, takže nic stabilního tam fakticky nenajdete. Pokud byste dnes rozlouskli byte kód (tedy pro Ty co to nadneseně nazývají assemblerem), bude to stejně každou chvíli překopáváno.
Tiskni
Sdílej:
