Byl vydán Debian 13.6, tj. šestá opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.15, tj. poslední patnáctá opravná verze Debianu 12 s kódovým názvem Bookworm, k dispozici je LTS. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
V jádře Linux byla nalezena a v upstreamu již byla opravena kritická zranitelnost GhostLock aneb CVE-2026-43499. Lokálnímu uživateli umožňuje získat práva roota a také obejít kontejnerovou izolaci. Zranitelnost existovala v Linuxu 15 let, tj. od roku 2011, od Linuxu verze 2.6.39.
Evropská komise předběžně shledala, že návykový design aplikací Instagram a Facebook od americké společnosti Meta porušuje unijní nařízení o digitálních službách (DSA). Návykový design zahrnuje například takzvané nekonečné posouvání, automatické přehrávání videí, tzv. push notifikace, kdy aplikace uživatele vybízí k návratu do jejího prostředí, či vysoce personalizovaný algoritmus, který rychle pozná, co uživatele baví a snaží
… více »Byla vydána verze 1.97.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Švýcarská společnost Punkt. má nově v nabídce telefon Punkt. MC03. Telefon byl navržen ve Švýcarsku s důrazem na soukromí a digitální suverenitu a vyroben v Německu. V telefonu běží operační systém AphyOS (Apostrophy OS) založený na AOSP (Android Open Source Project) 15. Cena telefonu je 745 eur.
TypeScript (Wikipedie), tj. JavaScript rozšířený o statické typování a další atributy, byl vydán v nové verzi 7.0. Kompilátor byl kvůli výkonu přepsán z TypeScriptu do Go.
Europarlament podpořil pozměněnou verzi výjimky známé jako „chat control 1.0“ umožňující firmám skenovat soukromou komunikaci na internetu kvůli ochraně dětí před zneužitím. Pozměňovací návrhy přijaté europoslanci však počítají s tím, že z výjimky bude vyřazena šifrovaná komunikace. Výjimka přestala platit začátkem dubna poté, co se Evropský parlament a Rada EU nedokázaly shodnout na jejím prodloužení. Rada následně přijala
… více »Nejnovější X.Org X server 21.1.24 a Xwayland 24.1.13 řeší 2 bezpečnostní chyby.
Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za červen 2026. Vypíchnuta je vylepšená podpora Waylandu. Už není považována za experimentální. V příští verzi Linux Mintu, plánována je na Vánoce, bude běh Cinnamonu plně podporován na X11 i Waylandu. V květnu na vývoj Linux Mintu přispělo 611 dárců celkovou částkou 19 612 dolarů. Dalších 2 326 patronů přispělo na Patreonu celkovou částkou 5 334 dolarů.
V Linuxu v KVM byla nalezena a v upstreamu již byla opravena kritická zranitelnost Januscape aneb CVE-2026-53359. Root na hostovaném počítači (virtuální stroj) může obejít izolaci a získat plnou kontrolu nad hostitelským systémem (DoS útok nebo vzdálené spuštění kódu s právy roota). Na obou hlavních architekturách – Intel i AMD. Zranitelnost v Linuxu existovala téměř 16 let (od srpna 2010 do června 2026).
Tiskni
Sdílej:
(gcc || g77 || ifort | ...) -g) a pak je slinkujes dohromady. Do Monte Carlo jsem moc nefusoval, ale muj skolitel ma na ni udelanou sadu programu v C. Tu ti ale nemuzu bohuzel bez jeho svoleni poskytnout. Jinak jsem delal Molecular Dynamics a pouzival jsem na to program DL_POLY, ktery je psan ve FORTRANu:
@ARTICLE{96SMI/FOR,
author = {Smith, W., and Forester, T.R.},
title = {DL\_ POLY\_ 2.0: A general-purpose parallel molecular dynamics simulation
package},
journal = {J.Mol.Graphics},
year = {1996},
volume = {14},
pages = {136--141},
availability = {reprint av. SIM },
keywords = {SIM DLPOLY},
owner = {milan}
Navíc dneska kdekdo přechází k C, aniž vím proč... Proč?Protože ani C není vhodné pro Pojídače koláčů (programování v C mohou opravdoví programátoři ocenit: žádná kontrola typu, jména mohou mít 7 (10?, 8?) znaků a dodaný užitek datového typu ukazatel není k zahození - podobně jako mít na jednom místě nejlepší části jazyka FORTRAN a assembleru (a to nemluvíme o define))
Zkus se podívat na SciPy, Python sice není Fortran, ale ta knihovna je stejně napsaná v C. Navíc je možné přes modul ctypes kombinovat kód v Pythonu a C, pyfortran umožňuje propojení numpy s fortranem a nějaký f2py pro generování rozhraní z Fortranu do Pythonu ...
. Jinak sem se mrknul do databaze v nasi knihovne a z tech novejsich tam mame jen: Akin, Ed; Object-oriented programming via Fortran 90/95. Online tam zadna neni
.
Odpověďi na tyto otázky by Ti měly pomoci:
Soukromý názor:
Podle mě je dobré být otevřený novým myšlenkám a postupům, ale nepodlehnout módě. Dát na selský rozum. Ověřit si vše v praxi. Dělat věci nástrojem, který je na danou věc nejšikovnější => naučit se skupinu jazyků pomocí, kterých dokážeš vyřešit snadno a efektivně všechny problémy, které se Ti dostanou pod ruku. Navíc zjistíš-li, že existuje mnohem lepší nástroj, tak se ho zkrátka naučíš používat a vyměníš ho za starý. Ovšem je otázka jestli Ti umožní navázat na předchozí práci a nebude Tě nutit příliš mnoho věcí psát znovu, pak starý nástroj stejně budeš muset dále používat na předchozí projekty.
Jinak není žádný problém ve spolupráci C, Fortran, Python. Pro Python můžeš psát rozšiřující moduly v C i Fortranu. Knihovny v C můžeš využívat ve Fortranu a naopak.
Má už kolem 60 let!!! To snad stačí na to, abych ho prohlásil za stařečka, nebo ne?A Lispaři tě umlátí čepicemi
na jiný schopnější kompilovaný jazyk, třeba to C++Čím to, že jsem četl komplikovaný?
C++ a šablony, toť syntaktický humus, ale jinak vcelku užitečná věc (včetně takových věcí jako parciální specializace a podobně). Pokud chce člověk napsat kód, kterému nebude 90% programátorů rozumět, už nemusí používat Lisp (anebo vlastně může)
labmda, map a reduce.
Mě se myšlenka šablon líbí, je to tak trochu ekvivalent maker v Lispu (taky umožňuje udělat mnoho věcí v době překladu), ale ta jejich syntaxe je hnusná a viditelně do jazyka dolepená.
ale zase neni nic rychlejsiho Osobne som prisiel na to, ze pouzivat jedneho molocha na riesenie vsetkych problemov nie je celkom ono. Sam som sa priklonil k nazoru rozdelit jednotlive ulohy na samostatne casti a na kazdu samostatne hladat najlepsie riesenie.
Ovladam C/C++, Javu, dalej Pascal a Fortran (posledne dva len na urovni skolskej vyuky...), samozrejme nejake male skriptikovanie. Ked som si vyberal v com budem pisat, hned som zavrhol pascal a fortran. V pascale nepise skoro nikto a hoci vo fortrane sa pise stale aj u nas velmi vela (KNM na MFF), mne uz jednoducho podobny jazyk nesedi. Okrem toho viem spravit most na volanie fortranovskej kniznice v cecku a cecka z javy, takze mozem pouzit fortranovsku kniznicu v cecku aj v jave.
Nakoniec som zvazoval podla nasl. veci:
Spravil som si nejake benchmarky porovnavajuce rychlost javy a cecka a zistil som ze doby ked bola java radovo pomalsia su davno prec... Z vyvojovych nastrojov su na tom oba jazyky dobre, osobne pouzivam eclipse aj na jeden aj na druhy. Takze zvitazila rychlost vyvoja, osobne v jave pisem rychlejsie (mozno preto, ze neponuka taku bohatost :)
Inak, javu pouzivam prave na konzolove aplikacie (vramci numeriky), na vyzualizacie pouzivam externe programy (nemam ambicie preprogramovat gnuplot...)
Takze momentalne som na tom nasl:
hlavna kostra mojej prace: java
z javy volam jednu ceckovu kniznicu (cez JNI) a okrem toho z nej spustam dalsi program
vypocitane vysledky dalej vizualizujem pomocou gnuplotu a mencodera
Jeto plodná diskuze, všem děkuju. Akorát jsem se zatím nedověděl, jak je to s funkcionálními jazyky ve fyzice.
Jinak co Vám brání použít funkcionální jazyk? Je jen potřeba říci, že pokud je rychlost vaší preferencí, tak to nebude dobrá volba.Ale kuš už rozumbrado. Takovejch nesmyslů co už jsi tu vyplodil se jen tak nevidí. Jdi už s tím svým C++ tam kam slunce nesvítí. Třeba takový GHC Haskelu dýchá C++ dost zdárně na záda a třeba v jednoduchosti paralelizace se funkcionálním jazykům imperativní geronti nedotádnou ani po kotníky a nedejbože aby to bylo objektové C++.
Pokud tam máte na výpočetní jazyk rychlost, pak neseženete nic lepšího, než imperativní kompilovatelný jazyk. C++, Ada, cokoliv. Doporučuji C++, protože se snese téměř s jakýmkoli jiným jazykem, je to jazyk dělaný na max. rychlost už od počátku a jeho možnosti jsou obrovské. Velká komunita uživatelů a podpora v kompilátorech je samozřejmostí. Vhodnost konstrukcí jazyka C++ k matematice a vyjádření abstraktních výpočtů je daná. Nutno říci, že C++ není nejjednodušší jazyk na učení.Nesezene nic lepsiho nez Fortran - v C musi matematicke funkcne nastavovat errno, ma prisnejsi pravidla pro poradi provadeni operaci a tim padem mensi prostor pro optimalizace atp.
Pro ten druhý jazyk bych doporučil hlavně něco, co má snadné GUI - doporučil bych třeba Python. Python byl původně dělán pro matematiky a i pro něj jsou k dispozici slušné matematické knihovny. Python se naučíte velmi velmi rychle, je až ďábelsky snadný a přitom ohromně schopný jazyk. Co bych určitě nedoporučil? Javu - Java jde ve všem příliš vlastní cestou, je to příliš očesaný jazyk, aby byl pro matematiku užitečný.Javu(+Eclipse) bych urcite doporucil - neni to jazyk ocesany, ale genialnim zpusobem oprosteny od veci na kterych si zavili zastanci OOP radi honi saska, ktere ale snadno vedou na scesti. Jednoduchost Javy naopak vede k cistemu a explicitnimu kodu, a umoznuje existenci silneho IDE, ktere najde vsechny syntakticke (a diky vynucene cistote kodu obvykle i semanticke) chyby a nabidne UPLNY seznam moznych reseni, a to v podstate instantne, kdezto kompilatoru C++ muze u slozitejsich konstrukci trvat odhaleni chyby desitky sekund, a prvni chyba navic obvykle "rozhodi" zbytek kodu, ktery pak hlasi falesne chyby. V Pythonu pak toto nejde vubec, nebot syntakticka spravnost muze zaviset na podminkach za behu, jako treba na vstupnich datech.
a = [1, 2] b = [3, 4] c = a + bCo má být v c? [1, 2, 3, 4]? [4, 6]? Něco jiného? Co násobení? Kartézský součin? Vektorový součin? Skalární součin? Když to budete chtít dělat pořádně a jednoznačně, velice rychle zjistíte že nemáte dost přetížitelných operátorů...