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.
Samsung představil headset Galaxy XR se 4K Micro-OLED displeji, procesorem Snapdragon XR2+ Gen 2, 16 GB RAM, 256 GB úložištěm, operačním systémem Android XR a Gemini AI.
), tak mi zatím stačila Quanta s otevřeným adresářem vzdáleného serveru. V poslední době se však potýkám s tím, že díky tomu, že jsou projekty vyvíjeny nerovnoměrně (například implementuji nějakou funkcionalitu v projektu 1, zjistím, že změny vedou hlouběji do jádra aplikace a tak musím upravit i projekty 2, 3 a 4 abych zachoval konzistenci) mám velký problém sledovat a udržovat všude stejnou verzi jádra aplikace.
To by nebylo až nic tak zásadního pokud bych nemusel udržovat i stejnou strukturu databázových tabulek a konfiguračních souborů (které se pochopitelně pro každý projekt liší). Stejně tak se v drobnostech liší jádro aplikace projektů (což je ale spíše důsledek bordelu v revizích než zamýšlená feature).
Nemám v podstatě žádné zkušenosti s použitím CVS, SVN či Gitu ale tak nějak tuším, že v podobném nástroji by se mohl skrývat klíč k vyřešení mých problémů
Vyžaduji co nejjednodušší aplikování změn napříč projekty (s možností zachovat některé rozdílné sekce v některých souborech) a dobrý přehled o tom, jaké jsou rozdílnosti mezi projekty a verzemi projektů. Ideální možnost by bylo něco jako kombinace "libjádro + aplikace", kdy by se jádro jen "linkovalo" k aplikaci a bylo vyvíjené zvlášť.
Úplně spokojený bych byl, kdyby bylo možné aplikaci mít spuštěnou z úložiště takového systému, abych nemusel věčně získávat aktuální revizi, tu kopírovat do WWW rootu a starat se o to, aby se vše správně sesynchronizovalo.
V současnosti mám na jedné ploše okno Quanty s otevřeným SSH spojením do testovacího adresáře serveru. Na druhé ploše v terminálu běží testovací server Catalystu (kdo neznáte, jde o malý HTTP server který poskytuje výborný debugovací výstup z tohoto frameworku) obvykle s oknem prohlížeče, na kterém to celé zkouším. A aby to nebylo tak jednoduché, stabilní revize projektů mi běží na vlastním Apači.
Otázka tedy zní: Jaké nástroje využít pro co nejjednodušší (abych se o ty nástroje nemusel moc starat a snadno se obsluhovaly) a nejpohodlější správu kódu více projektů a jejich verzí spolu se synchronizací s produkčním prostředím?
Řešení dotazu:
Git je dobrý, ale strašně překomplikovaný (+ nemám rád jeho značení revizí).Čo je zlé na spôsobe, akým značí revízie git?
Všechno. Ba ne, dělám si sranduGit je dobrý, ale strašně překomplikovaný (+ nemám rád jeho značení revizí).Čo je zlé na spôsobe, akým značí revízie git?
. Neříkám, že je to děláno špatně, ale já dávám přednost tomu mít srozumitelná čísla revizí, což jak Mercurial tak Bazaar splňují (i když čísla jsou platná jen pro konkrétní repozitář). Člověk si revize nesrovnatelně lépe zapamatuje (nebo i poznamená).
Jsem už tak napůl rozhodnutý pro Bazaar (kvůli hezkému a schopnému klikátu, ze začátku se bude hodit), ten Git si však ještě prohlédnu.
Jo, už jsem si taky všiml. To bazaarovský se mi ale líbilo nejvíc 
Mimochodem, nakonec to tedy vyřeším následovně:
use lib 'něco' díky čemuž ho můžu sdílet napříč projekty a není to třeba rozkopírovávatNějaké nápady na vylepšení? 
Budeš potřebovat i nějaký způsob, jak databázi upgradovat a kontrolovat shodu s předlohou. Jakmile máš víc instalací, každou v jiné verzi a ... no je v tom bordel
- databáze prozatím oddělené na vývoj a produkci, ke každému releasu budu vytvářet CREATE SQL skript
Pokud jde jenom o mergování dvou branches, tak to svn zvládá prakticky stejně dobře jako proklamované DVCS.Dovolim si nesuhlasit. Na jednom projekte som to bol nuteny robit, a skutocne to nechcem viac zazit. Stacili dve spravne premenovania suborov v sekvencii par stovak komitov do jednej vetvy a SVN nezvladol tu vetvu mergnut naspat do trunku, v ktorom po oddeleni zmienenej vetvy nedslo k ziadnej zmene. Ja mam Subversion rad a pouzivam ho spokojne uz cca 7 rokov. Ale subversion a merge, to je pre masochistov.
Ale pokud jde o mergování jen několika konkrétních změn tak je to na prdel.A to se v takovýchto projektech dělá docela často. Někde něco opravíš nebo uděláš nějakou fićurku a chceš jí dostat do hlavní větve. A merge nestačí, protože chceš přenést jen tu jednu změnu a ne všechny změny... Backportování oprav do starších instalací, které nechceš z jakéhokoliv důvodu upgradovat je další častý případ.
Jo,... potřebuješ git cherry-pick a možná i ten rebase
Pokud potřebuješ hlídat více velmi podobných projektů, tak se zcela jednoznačně vyhni velkým obloukem SVN. Místo toho použij Git nebo něco jiného, co umí merge.Proč podle Vás neumí SVN merge?
V SVN je merge coby funkce na řešení výjimečných situacíA proto je jí věnována celá kapitola v návodu? http://svnbook.red-bean.com/en/1.0/ch04.html Já žiju v domnění, že se v SVN dá merge použít (a taky jej tak používám) stejně jako v Gitu, možná s nějakým rozdílem v rychlosti. Pokud víte o něčem specifickém, kde SVN pokulhává tak sem s tím.
Tiskni
Sdílej: