Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Alyssa Anne Rosenzweig v příspěvku na svém blogu oznámila, že opustila Asahi Linux a nastoupila do Intelu. Místo Apple M1 a M2 se bude věnovat architektuře Intel Xe-HPG.
EU chce (pořád) skenovat soukromé zprávy a fotografie. Návrh "Chat Control" by nařídil skenování všech soukromých digitálních komunikací, včetně šifrovaných zpráv a fotografií.
Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
Společnost xAI a sociální síť X amerického miliardáře Elona Muska zažalovaly firmy Apple a OpenAI. Viní je z nezákonné konspirace s cílem potlačit konkurenci v oblasti umělé inteligence (AI).
Byla vydána nová verze 9.16 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Americká vláda se po převzetí zhruba desetiprocentního podílu ve výrobci čipů Intel chystá na další investice do vybraných firem. Na sociální síti Truth Social to napsal prezident Donald Trump. Jeho ekonomický poradce Kevin Hassett v rozhovoru v televizi CNBC řekl, že nemusí jít pouze o firmy z technologického sektoru, ale i z jiných odvětví.
Tak se mi konečně podařilo provést upgrade na nový Subversion server.
Protože vývoj v naší firmě probíhá centralizovaně, bylo před pár lety rozhodnuto přejít ze všech lokálních SCM na jedno společné, a tím se stalo Subversion. Sice v tom bylo dost politiky, na druhou stranu musím uznat, že ze všech navrhovaných řešení bylo vzheldem k sesbíraným požadavkům nejvhodnější.
Tak někdo zbastlil virtuální server, nalil tam Collabnet 1.5 a nějak to jelo (=na hovno). Pak jsem dostal Subversion na starosti já. Postavil se nový server na RHEL5, nasadil se vyladěný Apache s mod_svn. S přibývajícími daty začala rychlost klesat (ne moc, ale uzeři si všimli) a já začal uvařovat o proxy cache, např. ngix, popř. přejít na DSCM, jenže...
Při sledování změn na poli SCM mě potěšila jedna věc - vývojáři SVN neusnuli na vavřínech, ale kouknuli k sousedům (Git) a tak má Subversion ve verzi 1.7 rychlejší protokol a Working Copy nemá .svn balast v každém adresáři, alle pouze na nejvyšší úrovni jako Git. Rychlost práce je někde jinde (porovnávám se SVN <=1.6).
A navíc vzhledem k centralizované povaze vývoje a úspěchu v tom, že vývojáři plus mínus pochopili alespoň Subversion, jsem myšlenku přechodu na DSCM zahodil.
Takže nadešel čas pro nový server. Na základě pozorování má nové virtuální železo 4 vCPU (rozložení zátěže při ranní a odpolední špičce) a 16GB RAM (mod_svn 1.7 podporuje cachování obsahu). Operační systém je RHEL6.3 64-bit. Přesun proběhl bez vážnějších komplikací (menší zádrhel na FW a jeden hook). První komentáře pozitivní, server se fláká i při největší zátěži (ale lepší, než se zase za dva roky dohadovat, že je potřeba víc RAM).
Jediný problém se vyskytl ve CM skriptech, které přes svn diff --summarize porovnávají změny v repositářích - u klienta došlo ke změně kódování URI (tj. chová se jako webový prohlížeč), takže oblíbené # překódovává na %23 apod. Ale to je jen maličkost...
Vzhledem k novinkám, co mají přijít v1.8 si osobně myslím, že Subversion překonalo vlastní smrt a že má nezastupitelnou roli tam, kde je DSCM zbytečný overkill...
Tiskni
Sdílej:
git svn clone
“.
Ja jsem teda placen i za to ze umim s gitem a radu dalsich veci . V dost nabidkach programtorske prace dneska vidis git explicitne zminen. Pokud ma programator problem pochopit git, tak nejspis nebude za moc stat ani jako programator.
Pokud ma programator problem pochopit git, tak nejspis nebude za moc stat ani jako programator.Tak pod to bych se podepsal. Zvlášť vzhledem k tomu, jak je Git navržen.
základní množina příkazů je velmi podobná SubversionTo je i v Gitu. A ve většině ostatních. Kvůli decentralizaci je Mercurial v základu podobnější Gitu než Subversion. Jo, pokud někomu přijde nestravitelné, že Git umí rychle a dobře pracovat s větvemi, tak to je potom těžké. Ale možná by stálo za to napsat vývojářům Gitu, jestli by ho nemohli zase trochu zkriplit, aby byl stravitelnější :).
To je i v Gitu. A ve většině ostatních.Ne tak úplně, jsou tu věci jako staging area apod, které u gitu člověk musí znát předtím, než s ním může začít fungovat.
Kvůli decentralizaci je Mercurial v základu podobnější Gitu než Subversion.V tomhle ohledu samozřejmě ano, ale z pohledu, jestli je Subversion podobnější Git nebo Mercurial, tak je to rozhodně Mercurial.
Jo, pokud někomu přijde nestravitelné, že Git umí rychle a dobře pracovat s větvemi, tak to je potom těžké. Ale možná by stálo za to napsat vývojářům Gitu, jestli by ho nemohli zase trochu zkriplit, aby byl stravitelnější :).O větve nejde – ty mají Mercurial i Git prakticky identické, navíc po přechodu na některý z DVCS si dost lidí ze všeho nejvíce pochvaluje právě větve.
Ne tak úplně, jsou tu věci jako staging area apod, které u gitu člověk musí znát předtím, než s ním může začít fungovat.Ze začátku vůbec nemusí. Nicméně později se to stane natolik podstatnou výhodou, že se snažím lidem opravdu index představit hned na začátku.
O větve nejde – ty mají Mercurial i Git prakticky identickéTo jsem si právě myslel.
navíc po přechodu na některý z DVCS si dost lidí ze všeho nejvíce pochvaluje právě větve.To co já teďka dělám s Gitem... rychlý vývoj bez ladu a skladu, následný několikanásobný přepis historie, následné rozeskládání patchů do několika větví, vyřazování patchů, které už jsou vyzkoušené... :).
git bisect
ušetřil několikahodinové hledání chyby. To by se těm vývojářům muselo šikovně předkousat a přechod udělat tak bezbolestný, jak to jen jde.
Git je super, ale nedá sa na neho prejsť len tak, že si proste poviem "teraz mám pol hodiny čas, tak idem prejsť na Git".To máš naprostou pravdu, já k tomu potřeboval nejmíň půl dne.