V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
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: