Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Přijde mi zavádějící tohle připisovat gitu a jeho rozšíření. To, jakým způsobem projekt (ne)označuje, (ne)testuje a (ne)vydává nové verze, je IMHO dáno především náturou a způsobem uvažování jeho vývojářů. Podle mých zkušeností projekty, které buď přešly na git buď z CVS/SVN nebo které předtím ani veřejně přístupný VCS repozitář, svou release policy obvykle nijak zásadně nezměnily.
Git může řadu postupů usnadnit, ale pokud vývojář např. míchá nesouvisející změny dohromady nebo nepíše smysluplné commit message, git ho k tomu sám o sobě nedonutí. A s polikou pro vydávání a označování verzí je to IMHO úplně stejné. Z hlavy mne napadá třeba mplayer, který měl dlouhou dobu jen jeden prastarý (pre-)release a denní snapshoty, a to ještě předtím, než byl k dispozici veřejný VCS repozitář.
vývojář např. míchá nesouvisející změnyto on existuje nejaky system, ktery nesouvisejici zmeny rozezna? Jak?
Jediný takový systém, který znám, je přísný a důsledný maintainer. :-)
Ale to byla podstata mého příspěvku: git může workflow usnadnit a dobře vedenému projektu pomoci. Ale pokud vývojáři nemají disciplínu a na "štábní kulturu" kašlou, nepomůže takovému projektu sebelepší VCS.
Spousta let k plné spokojenosti (teda krom toho že po pár letech v tom začne být obrovský bordel a nejvíc místa na disku sežere adresář /usr/src).A právě o tom to je. Pokud si někdo šmudlá dva tři víceméně podobné stroje, tak je to ještě únosné, ale pokud je těch strojů více, každý pes jiná ves. Každý s jiným účelem, v různých lokalitách, s různou konfigurací - pak se stává situace neúnosnou a bez nástrojů jako Puppet, Chief apod. totálně nezvladatelnou. Po pravdě řečeno - kdybych nezvolil již před lety strategii jakou mám (kritické balíky vlastní provenience, základní konfigurace udržované přes Puppet a sledované přes git) tak už bych byl v pytli.
Pokud si někdo šmudlá dva tři víceméně podobné stroje, tak je to ještě únosné,No moc ne. Hele a dělá si někdo vlastní balíčky nebo dokonce provozuje vlastí repositář?
Hele a dělá si někdo vlastní balíčky nebo dokonce provozuje vlastí repositář?
Třeba já. Dokonce několik.
openSUSE Build Service - výhodou je, že pokud u projektu povolím publikování, výsledné balíčky jsou k dispozici přes URL, které můžu přímo předat "zypper addrepo
" a funguje pak stejně jako kterýkoli jiný repozitář.
Až na výjimky (např. snapshoty Firefoxu, u kterých chci, aby nekolidovaly s distribučním balíčkem) se snažím držet FHS a dalších distribučních zvyklostí.
Buď si lze udělat kompletní repo, jako máme třeba pro vlastní buildy cross-kompilátorů. Něco o použití a instalaci těch kompilátorů zde https://rtime.felk.cvut.cz/hw/index.php/Cross_compilers. O použití vání Debian repa na našem serveru https://rtime.felk.cvut.cz/wiki/index.php/Debian_packages_repository a obecně, podle čeho to bylo postavené http://blog.jonliv.es/blog/2011/04/26/creating-your-own-signed-apt-repository-and-debian-packages/
Pokud se jedná o použití jen o použití na jednotlivém počítači nebo o nutnost instalace vybuildovaných balíčků závislostí během kompilace než je odzkoušené, že má smysl balíčky poslat do repa, tak je nejjednodušší provést
mkdir -p /usr/local/debs echo "deb file:/usr/local/debs unstable main" >/etc/apt/sources.list.d/local-debs.list cd /usr/local/debs mkdir -p pool mkdir -p dists/unstable/main/binary-amd64 mkdir -p dists/unstable/main/binary-i386 touch override
Pak si vybuildovat balíky, s tím, že ve vastních mám control třeba nastavené unstable, ale není nutností. Balík, pokud je vybuildovaný třeba před dpkg-buildpackage
dám například do /usr/local/debs/pool/fpc
, nakopíruji všechny vygenerované *.deb
a často si tam schovám i zdrojáky v TARu, abych to měl u sebe a pak provedu
umask 022
ARCHS="amd64 i386"
OVERRIDE=override
DISTRIBUTION=unstable
cd /usr/local/debs || exit 1
for ARCH in $ARCHS ; do
dpkg-scanpackages -a${ARCH} pool ${OVERRIDE} \
>dists/${DISTRIBUTION}/main/binary-${ARCH}/Packages
gzip -c dists/${DISTRIBUTION}/main/binary-${ARCH}/Packages \
>dists/${DISTRIBUTION}/main/binary-${ARCH}/Packages.gz
done
apt-ftparchive -c conf/apt-${DISTRIBUTION}-rtime-release.conf \
release dists/${DISTRIBUTION} >dists/${DISTRIBUTION}/Release
A pak již klasicky
aptitude update aptitude install jmeno-baliku
Většinou tedy jdu spíš přes interaktivní režim a přes "l" vyberu balík a pak vidím, jakou verzi nabízí distribuce (její verze bude podle nastavení distribuce default) a jaké alternativní verzi mám k dispozici včetně té mé a tu si vyberu a nainstaluji. Pokud později distribuce přejde na novější verzi, než mám lokálně přidanou, tak se mi i v updatech automaticky objeví, ale updaty distribuce, které jsou mezi staršími verzemi než je ta moje se automaticky nenabízí. V aptitude si ale kdykoliv mohu verzi vybrat a přeinstalovat mezi nabídkou různých repozitářů, jsou vidět jen aktuální verze z repositářů, vracet se ke starším bez jejich uložení v local nejde a mít v jednom local více verzí pod stejným jménem balíku také povede k tomu, že bude nabízený jen ten nejnovější. Alespoň takto to umím já, možná je nějaká alternativa.
S gitem se to má jako s PHP.Asi tak jako se to s autem má jako s nohou. :)
Neni to spise tim, ze mas obavy, ze lide, jako jsi ty sam, by v ciste kapitalismu posli hlady?To tedy rozhodně nemám. Lidé jako jsem já jsou totiž pro čisté kapitalisty jako ty slepice co jim nesou zlaté vejce. Sice se jim moc nechce sypat zobání, jenže bez něj nejsou ta vejce na kterých stojí jejich byznys. Nedělám si iluze, ale kolik je v téhle zemi lidí co se hrabou v technologiích co já? 50? A to jsem možná přehnal. Ale co tam počítače. Je tolik jiných činností co člověk může dělat a mít z nich potěšení i obživu. Takže opravdu ne. Ale mezi uživit se a parazitovat na práci jiných je nebetyčný rozdíl.
Já mám svůj vlastní příklad takového problematického distribučního balíku, kterému se principiálně vyhýbám - Pacemaker. Ne proto, že by ten distribuční balík nebyl funkční, ale nemohu si zkrátka dovolit riskovat rozbití funkčního clusteru kvůli obyčejné aktualizace. Cluster není desktop. Když se rozběhá, tak musí běžet a to i řadu let - pak již není prostor na hledání příčiny toho proč něco nefunguje.Jen tak mimochodem - Pacemaker už je taky v jessie-backports. Ale automatický upgrade z wheezy na jessie prý fungovat nebude, takže už se těším, že budu mít co na práci
třeba gnunet si snaží vynucovat štábní kulturu používáním svn a ne gitu.Nikoliv. Tedy alespoň podle toho, co tam píšou.
First, we want to be open to new developes and make the learning curve as simple as possible.A proto se člověk musí učit mnohem složitější nástroj namísto nástroje, který může během několika minut používat i pro vlastní projekty.
Sure, git does not prevent this, but it makes it too easy to keep code "private".Tomu subversion nijak nezabrání a nejlepším důkazem je právě dále zmíněný git-svn. Já chápu, že Git není svatý grál, je to jenom nástroj se svými výhodami i omezeními. Chápu i to, že lidé dají vědomě přednost jiným nástrojům. Ale obávám se, že subversion existuje pouze z historických důvodů a udržuje se pouze díky stávající user base.
Nikoliv. Tedy alespoň podle toho, co tam píšou.Vyplývalo mi to právě z toho
Second, as a maintainer I want developers to commit ('push' in Git terminology) often, so we have an integrated version and run automated regression tests, portability analysis, static analysis tools, etc. on the code all the time. Sure, git does not prevent this, but it makes it too easy to keep code "private".ale může být, že jde spíš hlavně o zvyk na svn.
Pacemaker netvoří jen jedna komponenta. Jeho funkcionalita je závislá na celé řadě komponent, které mají své vlastní vývojové repozitáře. A stačí jen drobná změna v chování některé z nich k tomu, aby vaše skvělá konfigurace přestala pro aktualizaci fungovat tak jak máAle souhlasim s tim, ze bude hur. Ale ne kvuli GITu, ale kvuli rezignaci na princip KISS u lidi, kteri se venuji infrastrukture, a snaham budovat obrovske molochy, kde neni jasne, co se deje uvnitr a co souvisi s cim.
"Záporná" role verzovacích systémů je především v tom, že díky svým vlastnostem oddalují okamžik katarzeVerzovaci systemy verzuji, nic vic, nic min. Ze si nekdo zvoli proces vydavani verzi podle svych potreb, je bud jeho nebo tvuj problem, ne verzovaciho systemu. FYI: Podstata meho sdeleni byla uplne jina. Tvuj problem je uz v samotnem Pacemakeru a v jeho (molochovite) architekture a implementaci a za to GIT opravdu nemuze. Pokud mas problem, ze dilci aktualizace neco rozbije, zvazoval bych poohlednuti se po jinem reseni.
Tiskni
Sdílej: