Linux může běžet nativně na ESP32-S3 – bez emulace a rovnou s 9,7″ e-paperem.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 7.0.0. Pro sandboxing se na Linuxu nově používá Landlock místo Bubblewrap. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Správce fotografií Shotwell byl vydán ve verzi 33.0 (GitLab). Hlavní novinkou v tomto vydání po dvou letech je přechod na GTK4.
Na YouTube byly publikovány videozáznamy přednášek a na Flickru fotografie z konference EuroPython 2026.
Byl vydán Debian 13.7, tj. sedmá opravná verze Debianu 13 s kódovým názvem Trixie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Jiří Eischmann se v příspěvku Fiasko jménem W Social na svém blogu věnuje evropské sociální síti W: "W Social je příkladem toho, že se problémy sociální sítí nedají řešit od exekutivního stolu. Když na začátku tohoto roku v Davosu oznámili vznik nové sociální sítě W Social, politici se mohli přetrhnout ve chvalozpěvech. Konečně evropská sociální síť a ještě s ověřením identity. … Jak se ukázalo, když v Davosu W Social oznamovali, neměli kromě
… více »Výrobce hardwarových kryptoměnových peněženek Trezor upozorňuje na bezpečnostní incident u společnosti Brevo, kterou využívá k odesílání newsletterů. Útočník na e-mailové adresy odeslal phishingový e-mail.
Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za srpen 2026. Aplikace XApp mají vlastní webovou stránku xapp-project.org. Představena byl čtečka EPUB s názvem Xepub a kalendář Clockenstein.
Byla vydána nová verze 3.2.6 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Bylo vydáno Ubuntu 24.04.5 LTS, tj. páté opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na poznámkách k vydání.
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: