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.
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í.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 141 (pdf) a HackSpace 78 (pdf).
Byla vydána verze 2.0.0 programovacího jazyka Kotlin (Wikipedie, GitHub). Oficiálně bude představena ve čtvrtek na konferenci KotlinConf 2024 v Kodani. Livestream bude možné sledovat na YouTube.
Bylo vydáno nové stabilní sestavení verzovacího systému Bazaar. Ten je používán například projekty Debian, GNU, MySQL nebo Inkscape. Nová stabilní verze 2.5.0 přichází s dlouhodobou podporou (ta bude poskytována až do roku 2017) a krom jiného přináší lepší implementaci protokolu bzr nebo větší počet jazykových mutací.
Tiskni
Sdílej:
.
Hm, a v čem je asi napsaný mercurial?Zlaté pravidlo Pythonu říká, že Pythoní kód je pomalý, ale Pythoní aplikace nemusí být.
současný bazaar je (pro mě) naprosto vyhovující co se rychlosti i ostatních věcí týče.Já jsem tehdy nedisponoval rychlým počítačem a nepřišlo mi rozumné kupovat rychlejší počítač jen kvůli bazaaru, takže jsem přešel na Git.
(hlavně práce s větvemi mně zajímá nejvíc)Možná používám git až moc dlouho, ale přijde mi, že práce s větvemi je v něm o dost lepší, než nabízí konkurence. Viz část patch review. Bazaar i Mercurial vytváří větev v extra adresáři, kdežto git přímo v lokální kopii, což je velice rychlé. Navíc git nijak zvlášť nerozlišuje mezi lokálními a vzdálenými větvemi, kdežto hg branch se afaik odkazuje pouze na vzdálenou větev. Prostě z mých pokusů s mercurialem a hg mě vyšlo, že větev je u nich pořád něco speciálního a drahého, kdežto u gitu je
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
12.3.2012 20:52
12.3.2012 19:59
13.3.2012 09:01
git checkout -b nová-větev něco, nad čím není třeba přemýšlet.
Ale rád se nechám poučit, proč třeba ve zmiňovaném PEPu použivají vývojáři hg clone, namísto hg branch && hg merge.
přiznávam bez mučení, že mercurial používáme vcelku jednodušše (protože to stačí: 6-8 fulltime vývojářů, jedna stable větev, nula až dvě předreleasový, trunk, 5 hlavních releasů za rok, nula až tři minor releasy)Tak v Gitu se často používá model, že lokální větve naprosto nesouvisejí se vzdálenými a ani nejsou stejně pojmenované. V Hg jsem to ještě nezkoušel, ale četl jsem, že to není až takový problém. Vážně teď nemám dost informací, abych to porovnal mezi sebou. Detailně umím jen Git. Jde o to, že v Gitu je zcela běžné vytvářet lokální větve, které se nikdy na žádném serveru neobjeví, ale to stejné může platit pro ty serverové, že se větev toho názvu nikdy neobjeví lokálně.
hlavně práce s větvemi mně zajímá nejvícPokud tě zajímá hodně aktivní práce s větvemi, tak podle mě nemůžeš vybírat aniž bys do výběru zahrnul Git.
ale názory lidí, kteří s těmito systémy opravdu pracují, by mi určitě pomohly.
Hezký den
má problémy s Gitovskou syntaxí (je fakt nejednotná)A nestálo by za to („once again“) udělat k tomu Gitu prostě jednotný frontend? Pokud technicky vyhovuje a pokud části lidí vyhovuje, tak by to mohlo dávat smysl. Frontend může být v shellu nebo třeba v Pythonu, těžké je pouze definovat tu syntaxi, zpracovat ji do kódu už je vcelku primitivní.
architektura workdir -> index(stage) -> repo je taky oproti jiným hodně jiná.A přesně z toho důvodu se jí dá v Gitu úplně vyhnout.
Takže váháme mezi Bazaarem a Mercurialem.Bazaar jsem nějakou dobu používal a od té doby k němu cítím určitou nedůvěru, ale už je to dlouho a nejsem schopný teď přesně popsat proč. O Mercurial tu psal Franta Kučera a docela s nadšením, najdi si článek.
Tohle je IMHO nesmysl.A IMHO je to nejjednodušší cesta pro obě strany.
Pokud chci používat rozumně git, tak musím vědět, co se asi děje vevnitř, jinak se chová strašně nelogicky.A jak si myslíš, že vzniklo současné rozhraní Gitu? Úplně stejně. Je to sada příkazů, které pracují nad databází blobů (souborů), stromů (adresářů) a commitů.
A právě tak nelogicky by se choval nějaký frontend.Jenže on se Git nijak nelogicky nechová. Jediné, co se může zdát v určitých případech nelogické či nekoherentní je právě UI. Rád se nechám poučit, kdy se Git jako takový chová nelogicky a není to pouze věc UI.
(nebo by ten frontend musel být hodně vymakaný a to už je jednodušší vysvětlit git)Napsat za dvě odpoledne extrémně vymakaný CLI frontend nebo za více odpolední GUI frontend (fakt je to jednoduché, těžké je specifikovat požadavky), je mnohem jednodušší než se zavázat k tomu, že budu věnovat nadbytečné úsilý všem současným i budoucím uživatelům. Git už jsem pár lidí do různé míry naučil, ať už komerčně nebo soukromě. Ale rozhodně si netroufám na to, ho učit univerzálně kohokoli, když kolikrát mnohem lepší výsledky dává CLI či webový skript.
pak bys nemusel řešit přechod, centrální repository by zůstalo v gitu, uživatelé požadující něco jednoduššího by dostali mercurial/bazaar/whateverTo mi přijde jako zbytečnost. Git technicky zvládá vše, co je potřeba, takže stačí nad ním postavit frontend, jehož UI vyhovuje potřebám těchto uživatelů (pokud není účelné přizpůsobit uživatele Gitu). Je to velice jednoduchá věc, která se dá splácat za kus odpoledne a pak dolaďovat jak se revidují skutečné potřeby uživatelů. Pak si může každý vybrat jestli používat nadstavbu nebo Git, či dokonce obojí na lokálním repozitáři kombinovat.
). Zároveň jsou tam přehledně vidět větve - jen je potřeba zkontrolovat předem, že v defaultní konfiguraci u vás ukazuje všechny větve. V některých starších verzích ukazoval jen ty potřebné pro zobrazení grafu k atuální větvi.
A co se týče dokumentace, tak moje zkušenost je ta, že o gitu je napsáno mnoho. Strašně mnoho. A pro začátečníka toužícího pochopit logiku je 99% toho nepochopitelné. Jako ideální se mi ukázala úžasná kniha Git Pro. Vyšla díky CZ.NIC i v češtině. Je free elektronicky a za pár korun se dá (i ta česká) koupit v papírové podobě. Osvědčila se obrovsky snad všem, koho znám, že potřeboval pochopit git. Na Ábíčku vyšla recenze s odkazy na stažení i zakoupení.
Ano, 'git add -i' nepovažuji za rozumný nástrojJe to dřevorubecký nástroj, ale pracuje se mi s ním dobře.
git add -i (resp. -p, to je moje nejčastější použití) chladně vládne a pravítkuje.
Je to dřevorubecký nástroj, ale pracuje se mi s ním dobře.Proti Gustavovi žádná dišputace. Mně to uživatelské rozhraní připomíná editaci textu pomocí shellového for-cyklu přes všechny řádky souboru, kde se mě u každého zeptá, jestli chci tento změnit. Takže umím s tím, ale v 99% případů mám k dispozici X-ka a git gui, tak proč sebe sama týrat. Jako trénink na soutěž podrátě?
Takže umím s tím, ale v 99% případů mám k dispozici X-ka a git gui, tak proč sebe sama týrat.To by mě hrozně zdržovalo.
Git zase natahá do Windows půlku unixu, emulátor bashe a půlky unixových příkazů. Navíc s poznámkou, že sorry, cokoli kromě unixu není oficiálně podporováno.Nic z toho mi nepřipadá jako nevýhoda, snad kromě té (ne)podpory. Kdybych byl nucen používat Windows, tak se Cygwinovi stejně nevyhnu.
Nevýhodou je to, že člověk potřebuje od VCS poněkud absolutní spolehlivost.Pokud toto vnímáš jako nevýhodu... :D.
cygwin mi samozřejmě do Windows nesmíTo mně taky ne. A není to kvůli cygwinu :).