Na crowdsourcingové platformě Crowd Supply byla spuštěna kampaň na podporu open source biometrického monitoru ve tvaru hodinek HealthyPi Move. Cena je 249 dolarů a plánovaný termín dodání listopad letošního roku.
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.
$ git init $ cat .git/hooks/post-update.sample
#!/bin/sh # # An example hook script to prepare a packed repository for use over # dumb transports. # # To enable this hook, rename this file to "post-update". exec git update-server-infoTakže po SSH uděláš push a hook ti rovnou aktualizuje potřebná metadata pro HTTP přístup. Nic víc netřeba a takto to původně bylo zamýšleno autory Gitu. Pak příšel Gitolite. Založí se jeden společný unixový účet pro všechny repositáře a podle SSH klíče použitého k přihlásení se Gitolite rozhoduje, zda přístup povolí, či nikoliv. Nemá žádné GUI, je to jen pár hooků v Gitu a SSH. V principu je to stejné, jako předchozí přístup, jen trochu pružnější (obzvlášť při spolupráci více lidí). Repozitáře jsou stále obyčejné bare repositáře, které můžeš vystavit na webu. Mají jen nastaveno pár hooků. Gitolite také umí snadno zakládat repozitáře při prvním push na neexistující adresu a lze ho používat i bez dedikovaného unixového účtu. Na jednoduché hostování repozitářů je to velmi praktické. Github, Gitlab a podobné jsou jen hezčí webové nadstavby nad tím samým principem, který používá Gitolite. Pokud to chceš vystavovat na statický web (a tedy nechceš ty hezká webová prohlížítka), určitě bych při pushi vygeneroval nějaký přehled, co tam zrovna je – výpis větví, tagů a kousek nedávné historie. Hodí se to pro kontrolu, zda je tam to, co si myslíš, že tam je.
.git
, ve kterém jsou nasázeny soubory gitu. Kdyby o něm takhle nemluvil Pavel, když mi ukazoval jak na to, tak bych na to i teď čuměl jako puk. Jak už jsem zmínil, i když používám git dlouho, nejsem zase tak zběhlý uživatel, protože jen málokdy potřebuji dělat nějaké složitější operace.
Ono na hodně věcí může přijít člověk sám, ale na všechno ne. Sám na sobě jsem mohl pozorovat, jak raketově jsem šel nahoru když jsem nastoupil na ÚMOb Ostrava-Jih. A to jen proto, že jsem se měl koho ptát. Ovšem zanedlouho jsem se dostal do stadia, kdy už jsem se neměl koho ptát. Naštěstí jsem změnil práci a opět další raketový vzestup. Naštěstí na VŠ je stále se koho na co ptát – to je důvod proč se nehrnu do komerční sféry. Tam nikdo nemá čas na to aby se s někým bavil o věcech, které jsou zrovna mimo to co dělá. Sice je to také přínosné, ale jen po určitý čas a do určité míry. A to ještě musíte mít takové štěstí, jako jsem měl já, že natrefíte na člověka, kterému není zatěžko věnovat svůj drahocený čas, aby vás k něčemu zajímavému a prespektivnímu nasměroval.
git
vůbec žádný přínos.
A konečně – pokud bych se GitHubu chtěl přecejen vyhnout, aby byl OSS trochu víc decentralizovaný, tak by bylo lepší to celé hodit do jednoho zkomprimovaného archivu. Na read-only repozitáři nemá klonování přes git vůbec žádný přínos.Presne, medzi GIT repozitárom read only a ZIPom nieje rozdieľ.
Za tu dobu jsem však potkal i několik aplikací, které upadly do zapomění zcela nezaslouženě – jen proto, že vznikly příliš brzy na to, aby našly své uživatele. V lepším případě po nich zůstal alespoň po nějaký čas opuštěný repozitář, než definitivně zmizel.na tom serveri sa určite dočkajú slávy, uznania a rozšíria sa v komunite. Nechcem haniť žiadnu snahu o záchranu nejakých slobodných projektov, ale toto im nijak nepomôže, jedine tak zázrakom.
Na read-only repozitáři nemá klonování přes git vůbec žádný přínos.Do archivu release nebo i .git? Pokud to první, tak je to horší v tom, že nevidím jednotlivé commity, nemůžu bisectovat chyby a release se typicky vydává málo často; pokud to druhé, tak je opruz updatování (musím - typicky ručně - stáhnout celý archiv, zatímco git pull pouze automaticky stáhne změny).
.git/
. Updatování by se tady nejspíš nekonalo, pokud se bavíme o mirrorování discontinued projektů. I kdyby ten projekt pořád žil, většinou si budeš pullovat primárně od hlavního maintainera. Mirror by přišel na řadu až jako poslední.
Updatování by se tady nejspíš nekonalo, pokud se bavíme o mirrorování discontinued projektů. I kdyby ten projekt pořád žil, většinou si budeš pullovat primárně od hlavního maintainera. Mirror by přišel na řadu až jako poslední.Než jsem ten zápisek publikoval, tak jsem ho notně ořezal, protože to byla jenom omáčka k tomu jak umožnit klonování git repozitáře. I tak je to docela dlouhý zápisek. Ale jak vidím, některým by asi prospělo, kdyby si ji přečetli. Takže… Ač se to zdá k nevíře, jsou vývojáři co při své práci dodnes nepoužívají žádný verzovací systém. Osobně to považuji za zhovadilost, ale chápu, že pečlivé ukládání změn do jednotlivých commitů vyžaduje značnou vnitřní disciplínu, kterou sám nemám. Nicméně snažím se alespoň čas od času uložit do gitu aktuální stav, než něco rozvrtám. Obvykle je totiž situace (alespoň u mne) taková, že rozvrtám jednu věc, kvůli ní musím upravit jinou a pak další, atd. atd. To si člověk říká, dodělám to, ať to není v gitu rozbité. Jenže mezitím přijdou důležitější úkolu, které se musí řešit, A nakonec, když se k tomu zase po čase dostanu je z toho jedna velká hromada změn, s popiskem - "Aktualizováno". Ovšem pořád je to lepší než nic. A pak – kdo by se chtěl chlubit svým chaotickým způsobem programování, že? Není lepší veřejně publikovat jen stavy, které lze považovat za použitelné? Celá historie gitu by nezasvěcené bez řádného dokumentování commitů jen mátla, protože by neměli ponětí, proč něco zrovna nefunguje. Pak jsou aplikace, které sice mají svého maintainera, ale ten je dlouhodobě neaktivní. Z nejrůznějších důvodů. No a pak se objeví (v lepším případě) fork, ve kterém jsou změny, které autor ani dostatečně neotestoval, ale sračky padají na původního autora. S projekty na github a pod. je spojená i hromada byrokracie na kterou nemám čas ani náladu, případně to má i další háčky a zádrhele, o kterých nikdo jiný nemusí vědět. Já chci mít svoje věci u sebe, na svém serveru. Svoje projekty si programuji primárně pro sebe a nemám zapotřebí aby mi do toho někdo paralelně hrabal. Jestli chceš, tak si to naklonuj, vrtej si do toho sám a pokud to uznáš za vhodné, pošli mi patch mailem nebo si to dej kam chceš. Já změny přidám až si najdu čas na to aby zkontroloval, jestli se mi tím něco nerozbije.
Obvykle je totiž situace (alespoň u mne) taková, že rozvrtám jednu věc, kvůli ní musím upravit jinou a pak další, atd. atd. To si člověk říká, dodělám to, ať to není v gitu rozbité. Jenže mezitím přijdou důležitější úkolu, které se musí řešit, A nakonec, když se k tomu zase po čase dostanu je z toho jedna velká hromada změn, s popiskem - "Aktualizováno". Ovšem pořád je to lepší než nic. A pak – kdo by se chtěl chlubit svým chaotickým způsobem programování, že? Není lepší veřejně publikovat jen stavy, které lze považovat za použitelné? Celá historie gitu by nezasvěcené bez řádného dokumentování commitů jen mátla, protože by neměli ponětí, proč něco zrovna nefunguje.Na to existuje taková šikovná věc, jmenuje se to větve Před tím, než to rozvrtám, tak si vytvořím novou větev, tam se v tom hrabu, commituji dle potřeby. Hlavní větev se nerozbije a že nebude fungovat vývojová větev se přece dá očekávat No a když vývoj úspěšně skončí, tak jej nahraji do hlavní větve. Podstatná výhoda je, že během tohoto procesu nemusím zachovat kompletní historii vývojové větve, ale můžu provést revizi, některé commity sloučit, u jiných upravit popis. Všechno tak, aby to dávalo smysl a historie byla dostatečně popisná.
I tak je to docela dlouhý zápisek. Ale jak vidím, některým by asi prospělo, kdyby si ji přečetli.Já jsem ji („tu zápisku“) četl. Otázku, v čem je klonování pomocí
git clone
výhodnější než stažení archivu, to neodpovídá. Proč to provozovat přes HTTP už vůbec ne.
Následující elaborát o tom, že někdo Git nepoužívá vůbec, tak ty ho používáš alespoň naprosto prasácky, je vskutku dojemný, ale na žádné diskutované otázky to taky neodpovídá.
I .git/.
Pokud je cílem někde vystavit zaarchivovaný repozitář k downloadu, tak bych spíš řekl "jen .git/
" (resp. bare repository). Vycheckoutovaný snapshot jen zbytečně nafoukne archiv a vytvořit ho je otázka jednoho příkazu.
Tiskni Sdílej: