Americký výrobce čipů Intel propustí 15 procent zaměstnanců (en), do konce roku by jich v podniku mělo pracovat zhruba 75.000. Firma se potýká s výrobními problémy a opouští také miliardový plán na výstavbu továrny v Německu a Polsku.
MDN (Wikipedie), dnes MDN Web Docs, původně Mozilla Developer Network, slaví 20 let. V říjnu 2004 byl ukončen provoz serveru Netscape DevEdge, který byl hlavním zdrojem dokumentace k webovým prohlížečům Netscape a k webovým technologiím obecně. Mozille se po jednáních s AOL povedlo dokumenty z Netscape DevEdge zachránit a 23. července 2005 byl spuštěn MDC (Mozilla Developer Center). Ten byl v roce 2010 přejmenován na MDN.
Wayback byl vydán ve verzi 0.1. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána nová verze 6.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově se lze k síti Tor připojit pomocí mostu WebTunnel. Tor Browser byl povýšen na verzi 14.5.5. Thunderbird na verzi 128.12.0. Další změny v příslušném seznamu.
Meta představila prototyp náramku, který snímá elektrickou aktivity svalů (povrchová elektromyografie, EMG) a umožňuje jemnými gesty ruky a prstů ovládat počítač nebo různá zařízení. Získané datové sady emg2qwerty a emg2pose jsou open source.
Byla vydána (𝕏) nová verze 25.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 25.7 je Visionary Viper. Přehled novinek v příspěvku na fóru.
Před 40 lety, 23. července 1985, společnost Commodore představila první počítač Amiga. Jednalo se o počítač "Amiga od Commodore", jenž byl později pojmenován Amiga 1000. Mělo se jednat o přímou konkurenci počítače Apple Macintosh uvedeného na trh v lednu 1984.
T‑Mobile USA ve spolupráci se Starlinkem spustil službu T-Satellite. Uživatelé služby mohou v odlehlých oblastech bez mobilního signálu aktuálně využívat satelitní síť s více než 650 satelity pro posílání a příjem zpráv, sdílení polohy, posílání zpráv na 911 a příjem upozornění, posílání obrázků a krátkých hlasových zpráv pomocí aplikace Zprávy Google. V plánu jsou také satelitní data.
Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Byla vydána nová verze 2.4.65 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2025-54090.
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: