Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
rsync
. Odkazováním na Dropbox a ownCloud jste požadavky moc neupřesnil, protože to jsou dvě dost velmi odlišné věci (už jen proto, že jedno je služba a druhé aplikace), které mají společné snad jenom to, že se tam dají ukládat soubory a má to webové rozhraní.
Chtel bych zalohovat a verzovat treba i zdrojaky a nechci se zatim ucit GIT.Chyba. Zálohování není důvod nepoužívat VCS.
Já si právě s GITem hrál a přišlo mi to šíleně složité.Ani náhodou to není složité. Oproti běžným programátorským problémům je uživatelská stránka Gitu triviální záležitost. Osobně ho preferuju, ale třeba Franta Kučera zde propaguje Mercurial jakožto alternativu s jednodušším a pochopitelnějším rozhraním. Číslování adresářů je relativně nepohodlné a jak člověk jednou vyzkouší spravovat lokální kód pomocí commitů, tagů a větví, už se nikdy nechce vrátit. Narozdíl od šíleností jako CVS nebo Subversion je právě Git (nebo Mercurial a další) ideální pro one man show.
git initMám repozitář.
git add .Mám všechny soubory zazálohované pro případ, že udělám nějakou nesmyslnou změnu.
git rm -f xyzVyhodil jsem trvale soubor, který do projektu nepatří.
git commit -m "initial commit"Mám uložený počáteční stav projektu.
git tag -a v0.0.1 -m "Version 0.0.1"Mám zafixovanou verzi 0.0.1. Až na pár detailů uživatelského rozhraní, vážně nevím, co by mohlo být jednodušší. Od té doby, co jsem začal jsem používat Git na všechny projekty namísto Subversion nebo verzovaných kopií, mám život daleko jednodušší. Navíc se s Gitem dá víceméně pracovat i jako s těmi verzovanými adresáři, přepínání větví, commitů a souborů je bleskové a v přípaďě potřeby lze používat víc pracovních adresářů s různými verzemi. Už i ta nejzákladnější funkcionalita mi šetří obrovské množství času při jakékoli chybě nebo neopatrnosti. Ovšem každý svého štěstí strůjcem a pokud se chceš patlat s adresáři, enjoy...
Ten GIT syncujes nekam na server, nebo to provozujes takhle normalne lokalne?Naprosto libovolně. Jakmile začínám něco dělat, co má povahu projektu, tak minimálně nahodím
git init
a git add
jako obranu proti chybám. Pak už se to větví podle povahy projektu. Většina věcí, co dělám je open source a jde do veřejného repozitáře. Pár jsou věci, které selektivně sdílím pomocí URL, ty jdou do repozitáře na serveru s deployment hoky. Výjimečně jde něco do private repozitáře.
Každopádně pokud máš daný projekt zálohovaný a nepotřebuješ ho sdílet ani deployovat, není problém ho nechat čistě lokálně.
Mne desi to, ze se to nijak neintegruje treba do IDE. Kdybych vyvijel v konzoli, chapu to.Pracuju v konzoli, s integrací neporadím, ale určitě najdeš dost lidí, kteří nějakou používají.
Proste mi pripada, ze pokud nepouzivam serverove funkce a sync treba do githubu, je pro mne mnohem snazsi, kdyz zakladam projekt, vyrobit adresar PROJEKT-POKUS a v nem v1.0 a do nej vytvorit projekt z netbeans. Kdyz jdu neco predelat, vytvorim adresar v.1.1 a ulozim projekt do nej. Tam provadim zmeny.Moje zkušenost je přesně opačná. Nejdřív jsem začal používat Git výhradně lokálně. GitHub tou dobou ani neexistoval. Adresáře mi nevyhovují granularitou. S VCS si ji určuju sám podle aktuálních potřeb.
Jasne, pokud zmenim neco, aniz bych si vytvoril novou verzi a neco se posere, tak se nemam jak vratit zpet.To by mi právě vadilo, VCS mi umožňuje nepřemýšlet dopředu a soustředit se jenom na to, co chci udělat. Dává mi to svobodu dělat naprosté vylomeniny aniž bych se v jejich výsledcích ztratil.
Ale pokud si to ohlidam, dava mi GIT neco navic?Je to jenom nástroj, navíc takový, který je od základu postavený tak, aby pomáhal a nepřekážel. Já osobně vycházím z toho, že si to neohlídám a hlídat si to ani nechci. Architektura Gitu funguje v zásadě na principu těch adresářů a jejich kopií, jenom je to schované do repozitáře a člověk k tomu přistupuje přes ten toolset. A já velkou část toho toolsetu na ty gitovské verzované adresářové stromy skutečně používám.
git init
a git commit
, ale nikdy git push
, tak budeš mít kompletní historii v místním adresáři ./.git
a nikde jinde. Pokud nepotřebuješ program vystavit světu, tak to tak klidně může zůstat. Server není potřeba ani nemá po technické stránce žádnou zvláštní roli. S Gitem se centrální server používá jen z organizačních důvodů, nikoliv z technických (když nepočítám obtížné připojování se na vypnutý notebook kolegy).
Workflow s Gitem při běžném programování vypadá tak, že uděláš nějakou funkci (feature) nebo něco opravíš a commitneš. Pak něco dalšího a zas commitneš. Tedy hodně relativně malých commitů. Když později zjistíš, že jsi něco rozbil, tak ti git bisect
poví, který commit to byl. Na běžné commity můžeš mít čudlík v GUI. Já mám trvale otevřený terminál a nijak mne to nebrzdí.
Tiskni Sdílej: