Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
Nový CEO Mozilla Corporation Anthony Enzor-DeMeo tento týden prohlásil, že by se Firefox měl vyvinout v moderní AI prohlížeč. Po bouřlivých diskusích na redditu ujistil, že v nastavení Firefoxu bude existovat volba pro zakázání všech AI funkcí.
.
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 :).
Tiskni
Sdílej:
