Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Samozrejme, pokud bych v C++ udelal new() na kazdy objekt zvlast, budu mit stejnou spotrebu jako javovsky vector, ale proc bych to delal kdyz mam STL vector?Muzu se zeptat, cemu pripisujete vetsi spotrebu pameti? Je to vetsi rezii datovych objektu nebo tim, ze u Javy lezi v pameti pomerne dost mrtvolek?
Java je ve vyuzivani pameti naprosto neefektivni...Zalezi jak na co. JRE samozrejme uz umi recyklovat objekty a podobne finty. Nekdy se GC muze i hodit a urychluje beh aplikace - zejmena jeji ukonceni. Proste to co jste napsal neplati vzdy. Urcite neni zcela spravne vytvoret hloupe 50 tisic objektu. Jak jste podotknul, neni to vhodne ani pro C++, natoz pro Javu. A uz vubec nechapu, co se snazite resit pomoci kontejneru Vector, ktery je pochopitelne i v Jave. Jestli myslite nejakou linou inicializaci, tak tim se nic neresi. Nerelevantni je tvrzeni, ze se (Java) proste neda srovnavat s aplikacemi, kde se vytvori statisice objektu. Java je objektove orientovany jazyk, proste se v ni vytvari tisice, desetitisice i statisice objektu. To je proste tak. A ze i velike programy jsou dnes napsany v Jave (nejen CAD, hry nebo databaze) je myslim kazdemu jasne. Doporucil bych Vam nejakou knihu o optimalizaci Javy, nez zacnete "srovnavat". Zacit muzete manualovou strankou JRE, protoze staci napriklad jen par parametru (nastavit spravne HEAP) a ejhle -- neswapuje to. A kdyz mate zkusene programatory, kteri vedi, jak programovat (v Jave), muzete se pustit bez starosti i do nejakeho CADu.
Ad: STL Vector versus Java Vector: U STL vectoru vyuziti pameti rovna se velikost objektu * pocet objektu (+-). U Java vectoru kazdy objekt se alokuje zvlast takze je to stejne (jak jsem uz psal) jako kdyby STL udelal pro kazdy objekt new(). V praxi to znamena mnohonasobne vyssi vyuziti pameti.Prominte, ale stale tomu nerozumim. Mohl byste to vysvetlit podrobneji nebo me odkazat na relevantni zdroje? Uplne presne si uz nevybavujju, jak funguje STL Vector, ale z Vaseho prispevku predpokladam, ze pri vzniku instance Vectoru alokuje jiz nejaky prostor a v nem vytvori nekolik (napr 50) instanci pozadoveneho objektu. Ale to znamena, ze jsou objekty ve Vectoru ulozeny hodnotou a to s sebou nese jiste problemy pri pridavani. Druhou moznosti, jak si drzet objekty ve vektoru, je pamatovat si na ne odkazy. To s sebou nese jistou pametovou rezii: tak 2B na odkaz + nejaka mala rezie, ktera bude po rozpocitani na jednotlive prvky vektoru asi tak desetina bitu (nebo min, zalezi na poctu prvku a implementaci). Stale tu ale nevidim souvislost pametove narocnosti s vytvarenim objektu pojednom vs. en bloc. Muzete mi to prosim objasnit? Jinak s Vami souhlasim, ze mit aplikaci s 50 * 10^3 objektu je celkem normalni. V takovych aplikacich je vsak relativne malo typu objektu. V tom pripade je mozne tyto objekty recyklovat misto mazat a znovu vytvaret. Jiste je to prace navic (pokud to jiz nepodporuje VM), a v tom pripade je na zvazeni, zda je pracnejsi obejit se bez vymozenosti Javy nebo muset delat v Jave vlastni recyklaci. Co se tyce poctu programu typu GIS, CAD, ale i office napsanych v jave: myslim, si, ze Java je z pohledu techto programu velmi mlada -- v tom smyslu, ze zacala byt pro tyto ucely pouzitelna teprve pote, co tyto programy meli za sebou jiz nekolik uspesnych komercnich verzich (a jsou tedy napsany napr. v C). Firma, ktera vyrabi takovyto software pak musi nutne zvazit, jestli ji prepsani programu do Javy prinese vic vyhod nez nevyhod. Znamena to totiz, ze se nejakou dobu nebudou pridavat nove funkce, ze je potreba preskolit programatory, kteri pomerne dlouho dobu nebudou mit v Jave takovou vykonnost jako v C, prijmout nove programatory misto tech, co firmu kvuli jave opustili, a zaskolit je ve firemnim know-how. Prepracovat/koupit podpurne a vyvojove nastroje. A co je ze vseho nejhorsi, ze prepisovanim se nutne zavlecou nove chyby, ktere bude nutne odstranit. Osobne se tedy domnivam, ze prevedeni komercne uspesneho a rozsireneho programu z jednoho programovaciho jazyka do druheho se pohybuje na hranici pricetnosti. Proto IMHO mame tak malo programu v Jave.
Tiskni Sdílej: