Microsoft představil Azure Linux 4.0 a Azure Container Linux. Na konferenci Open Source Summit North America 2026 organizované konsorciem Linux Foundation a sponzorované také Microsoftem. Azure Linux 4.0 vychází z Fedora Linuxu. Azure Container Linux je založen na projektu Flatcar. Azure Linux (GitHub, Wikipedie) byl původně znám jako CBL-Mariner.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 165 (pdf).
Byla vydána verze 9.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 informačním videu.
Firefox 151 podporuje Web Serial API. Pro komunikaci s různými mikrokontroléry připojenými přes USB nebo sériové porty už není nutné spouštět Chrome nebo na Chromiu postavené webové prohlížeče.
Byla vydána nová stabilní verze 8.0 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 148. Přehled novinek i s náhledy v příspěvku na blogu.
Ve FreeBSD byla nalezena a opravena zranitelnost FatGid aneb CVE-2026-45250. Jedná se o lokální eskalaci práv. Neprivilegovaný uživatel se může stát rootem.
Společnost Flipper Devices oznámila Flipper One. Zcela nový Flipper postavený od nuly. Jedná se o open-source linuxovou platformu založenou na čipu Rockchip RK3576. Hledají se dobrovolníci pro pomoc s dokončením vývoje (ovladače, testování, tvorba modulů).
Vývojáři Wine oznámili vydání verze 2.0 knihovny vkd3d pro překlad volání Direct3D na Vulkan. Přehled novinek na GitLabu.
Společnost Red Hat oznámila vydání Red Hat Enterprise Linuxu (RHEL) 10.2 a 9.8. Vedle nových vlastností a oprav chyb přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Vypíchnout lze CLI AI asistenta goose. Podrobnosti v poznámkách k vydání (10.2 a 9.8).
Organizace Apache Software Foundation (ASF) vydala verzi 30 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
chmod -R a+w) pro všechny všude vůbec žádný problém.
Především, pokud je systém používán skutečně jako verzovací, nejhorší, co developer může spáchat, je, že si udělá ostudu, protože všechny aktivity jsou trackovatelné a lze se kdykoliv "vrátit" ke stavu před zásahem, tj není problém zjistit, kdy a kdo ten soubor/adresář/projekt smazal, dojít ho vytahat za uši a nechat si od něj přinést tatranku nebo pivo za to, že to "SCM magií" uvedu "do pořádku".
Navíc mají stejně všichni svých starostí dost, než aby se vrtali v "cizích" projektech, a pokud už to dělají, mají pro to obvykle dobrý důvod (třeba na něm pře pár lety dělali a chtějí se inspirovat).
Naproti tomu je zcela kritické mít pečlivě ošetřený "administrátorský" přístup, tedy cokoliv, co může "změnit historii". Jednak lidi jsou hračičkové a developeři obzvláště, druhak už jsem párkrát viděl skript, kde bylo (z čisté blbosti pochopitelně) něco jako rm -rf $IAMNOTDEFINED/, a obnovování ze zálohy nepatří, myslím, mezi oblíbené hobby většiny z nás.
Samotné oddělení projektů v rámci SCM systému je možné řešit X různými způsoby od metody jeden projekt na repozitář až po co projekt to podadresář -- žádný obecný návod neexistuje a záleží na tom, co po tom vlastně člověk chce. (stejně se vždycky nakonec zjistí, že se to mělo dělat úplně jinak...)
Tak nebo onak, Markova poznámka o branchích byla dost na místě, i když ne co se týče přístupových práv. Jeden ze stěžijních požadavků SCM je, lidsky řečeno "umět určit, co patří k sobě", a dobře navržené a důsledně dodržované branchování je pro to nedocenitelné. Ale s právy to příliš nesouvisí ;)
A čo vy si Kefalín predstavujete pod takým slovom "efektivně spravovat"? :)Stav, kdy užitek přesáhne náklady nebo vydanou energii.
A bavíme se o "komerční potřebě" v rámci jedné firmy, nebo o situaci, kdy jde o projekty na sobě nezávisejících entit ("SCM hosting" typu sourceforge)?V rámci jedné firmy.
, takže bych se nebál, že to nepůjde, a neporadím nic hnusnějšího, než po zvolení vývojáři toho jediného správného SCM podrobně konzultovat dokumentaci tohoto SCM a vyrobit oprávnění podle ní. SVN je popsáno dost hezky v SVN Book, CVS bohužel z tohoto hlediska neznám. Největším problémem je asi již zmíněná volba "vše v jednom repozitáři" nebo "pro každý projekt jiný repozitář"; např. SVN umí AFAIK různá oprávnění v obou situacích.
Je efektivní (nejefektivnější) to řešit už na úrovni souborového systému (i když s omezeními, která z toho plynou)?Na úrovni souborového systému, tj. dát těm stovkám lidí SSH účet, rozstrkat je do patřičných skupin a nechat je sahat přímo do datových struktur SCM systému, bych to nedělal. SCM systémy obvykle obsahují nástroje pro spuštění serveru (démona), které zpřístupní repozitář nějakým protokolem a součástí toho bývá i autentizace a kontrola oprávnění.
Tiskni
Sdílej: