Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
checkinstallněkdo neměl dlouho rozbitý systém, že?
Primárním cílem není instalace na kliknutí, ale zjednodušení prvního kroku instalacePro ...? Uživatele nebo vývojáře distribuce? Z mého pohledu je nejjednodušší, když si v menu distra např. vyberu program a kliknu na tlačítko: Nainstalovat. Blblblbl... nějaká akce, co mě už vůbec nepotřebuje a hotovo. Kvalita distra pak bude v tom, jak kvalitní bude programová nabídka tímto způsobem instalovatelná - to by mohlo souviset s tím, že z hlediska vývojáře by bylo lepší nalézt nějaký univerzální způsob prezentace balíčků, aby se nemusely donekonečna nafukovat repozitáře, o které se pak nakonec nemá kdo starat. Často také hodně udělají distribuční patche - tohle by odpadlo? Courat po netu a stahovat si odsud ručně software, to nepozvažuji jako uživatel za pohodlný způsob existence a jsem velice rád, že to v Linuxu obecně nemusím. Může to být zajímavá kratochvíle nebo hobby, to ano... ale pak to nepotřebuji mít až tak ulehčeno, asi ani ten první krok.
a především důsledné používání stávajícího balíčkovacího systému. Pokud nebude daný balíček k dispozici, mohlo by to umět vyřešit problém jinak, ale způsob zatím nevím ...Tím spíš to ale vidím spíše jako nástroj pro vývojáře, kteří ho pak zakomponují do vlastního spráce distribuce. BFU by de facto ani neměl na něco takového pomyslet, i když by si mohl umět nainstalovat programy skrze správce balíčků.
aptitude search amarok
(vim /etc/apt/sources.list
, aptitude update
) a aptitude install amarok
. Jenže co chudák BFU, pro nějž jsou tohle hieroglify? Navíc, můj nápad vůbec neodstraňuje možnosti instalaci z konzole, takže vyhledávat balíčky na webu není nutné. Nic stávajícího měnit nechci.
Ten tvůj způsob výběru z nějakého menu je běžně v grafických instalátorech - kpackage, yast, synaptic, nebo textové aptitude a naráží na množství balíčků. V takovém Debianu je kolem 20 000 balíčků (Gentoo kdysi uvádělo kolem 15 000) a vyhledávat v tomto množství není jednoduché ani pro zkušené uživatele (aneb kolikrát jste zjistili, že ten super program, o kterém právě čtete už máte dávno v repository)
Co se týká univerzálních balíčků, docela se mi líbí autopackage.org ... možná se ještě zkusím podívat co nabízí on.
Postup na Windows: vidím to, zaujme mě to, kliknu na odkaz a nainstaluju. Postup na Linuxu: vidím to, zaujme mě to ---> přepnu se do úplně jiného programu, chvíli hledám (ev. hledám repository a přidávám je) ---> nainstaluju. Moje řešení: vidím to, zaujme mě to, kliknu na odkaz (webbin to přeloží na název balíčku, ev si přidá repo a zavolá stávající systém) a nainstaluju.Moje řešení: vidím to, zaujme mě to, řeknu
emerge to
. Když se nudím a autoři používají CVS/SVN/GIT, napíšu pro to ebuild a hodím ho do overlaye
Postup na Windows: vidím to, zaujme mě to, kliknu na odkaz a nainstaluju. Postup na Linuxu: vidím to, zaujme mě to ---> přepnu seHm, u mě to vypadá takto: Něco potřebuju, poptám se, popátrám, jestli něco takového existuje a jak se to jmenuje, prohledám repozitáře své distribuce, nainstaluji, vyzkouším. Hledám-li návod nebo když mám problémy, jdu se podívat do fóra distribuce / přes Google na www / na homepage programu (mám zkušenosti, že relevantní informace najdu v tomto pořadí). Ale ano, pochopil jsem, že vaše idea by leckomu instalace usnadnila... Jen bych ještě přece jen připodotkl, že obecně jako uživatel Linuxu nemám vůbec potřebu instalovat spoustu malých kravinek, jako to bylo za dávných časů s Windows. Částečně je to tím, že užitečné maličkosti jsou často už defaultně obsaženy, stačí je jen objevit, a taky snad tím, že člověk má zábavy dost se systémem samotným. Tedy bych si dovolil tvrdit, že představa linuxáka bloudícího po netu a hledajícího "nějaké" programy, co by ho mohly zaujmout, je mi dost vzdálená. Tím nic proti záměru, pouze si jen tak přemýšlím, jestli bych to já využil vzhledem ke svým návykům. Jinak jsem zastánce usnadňování co to jde.
Tedy bych si dovolil tvrdit, že představa linuxáka bloudícího po netu a hledajícího "nějaké" programy, co by ho mohly zaujmout, je mi dost vzdálená.No linuxáka snad ne (já tohle chápu jako velkou výhodu Linuxu, škoda, že to není marketingově zdůrazňováno), ale co lidé mající Linux (a jsou plní náviků z Windows) chvilku? Škoda, že se tu neozvali.
Tím nic proti záměru, pouze si jen tak přemýšlím, jestli bych to já využil vzhledem ke svým návykům. Jinak jsem zastánce usnadňování co to jde.Částečně to řeší i ten problém na co linkovat, když ne na zdrojáky, jak jsi psal v blogu. Já osobně umím používat balíčky a chápu jejich princip a výhody. takového.
... náviků z Windows ...No ale Michale... styď se!
No linuxáka snad ne (já tohle chápu jako velkou výhodu Linuxu, škoda, že to není marketingově zdůrazňováno), ale co lidé mající Linux (a jsou plní náviků z Windows) chvilku?
Dovolím si kacířskou myšlenku: neměla by se právě na tyto uživatele spíš zaměřit osvěta, která by jim vysvětlila, co je to package management a k čemu je dobrý, místo toho, aby se vytvářely mezivrstvy, které jim budou předstírat, že Linux jsou vlastně Windows v jiném balení?
Zatiaľ si to komplikujem rôznymi požiadavkami typu dvojitá konfigurácia (package + system) a podobne.
Jenže BFU přemýšlí jinak. Někde na síti si najde článek o nějakém super programu. Ihned se ho rozhodne vyzkoušet a první co uvidí je adresa ke stažení.To jsem viděl nejen u BFU. Kamarád Windowsák si nainstaloval Ubuntu a takhle si tam přidal Operu. Naštěstí to šlo - stáhnul .deb a nainstaloval. Opravdový BFU si Linux nikdy nenainstaluje, protože o něm nepíší články o tom, jak si vytvořit šifrovanou složku atd. na Živě.
package_name
bych udělal dle konvence DNS nebo Java package jmen – jinak nastanou konflikty ve jménech./package.wbn
) – pokud už si uživatel stáhne balíček se zdrojáky, může mu jeho správce souborů nebo manažer balíčků podle tohoto souboru pořád nabídnout správný způsob instalacexyz
kubuntu.org/packages/amarok-latest
), jak jsi navrhoval, mělo by být možné se nějak rozhodnout mezi instalací této, nebo oficiální stabilní verze. Takže se s těmi verzemi budu muset nějak vypořádat v každém případě.
Můj návrh je ten, že bude zvolen výchozí způsob (třeba instaluj stable) s tím, že si uživatel někde v pokročilých možnostech bude moci vybrat i jinou možnost.
uname -sr; test -x /usr/bin/{yum|apt-get|pacman|..}
zjistil na čem běží, přidal správná repository do správných konfiguráků, a spustil správný balíčkovač se správnými argumenty. Ad bezpečnost: BFU je to jedno, lepší uživatel se na ten skript nejdřív koukne (beztak se jen v prvním řádku nastaví jméno package, zbytek bude identický). A ruku na srdce, kdo kontroluje při dnešních zaneřáděných Makefiles
, co mu se systémem vyvede sudo make install
?
aby na webové stránce bylo možné přidat <link href="amarok.wbn" type="application/wbn" rel="web-based-installer"> a prohlížeč s příslušným pluginem pozná, že ta stránka nabízí možnost instalace softwaru a nějakým způsobem to uživateli nabídne Proč to komplikovat? <link href="amarok.sh" rel="installer"> je mnohem jednodušší.. Na nějaké XML bych se vykašlal.. Ten skript by jednoduše za runtime pomocí různýchA proč to komplikovat? Proč kopírovat do tisíců skriptů stejné testy na zjištění distribuce a udržovat je aktuální, když můžu naopak distribučnímu správci balíčků předhodit informaci o tom, co jsem zač, pod jakým jménem mne zná a případně kde mne najde, a on už se postará o zbytek?uname -sr; test -x /usr/bin/{yum|apt-get|pacman|..}
zjistil na čem běží, přidal správná repository do správných konfiguráků, a spustil správný balíčkovač se správnými argumenty. Ad bezpečnost: BFU je to jedno, lepší uživatel se na ten skript nejdřív koukne (beztak se jen v prvním řádku nastaví jméno package, zbytek bude identický). A ruku na srdce, kdo kontroluje při dnešních zaneřáděnýchMakefiles
, co mu se systémem vyvedesudo make install
?
autoconf
:(
Vas postup predpoklada, ze distributor bude prohledavat vsechny mozne neoficialni repozitare pro jeho distribuci, aby mohl vybudovat vseobjimajici databazi balicku pro svoje distro. Jenze to je presne to, co distributor nikdy delat nebude. Pro nej konci svet oficialnim repozitarem (skladistem?).Rozhodně budu svůj postup konzultovat s lidmi, co se motají kolem distribucí. Přiznám se, že konkrétní způsob řešení neoficiálních repo neznám. Na druhou stranu o nich někdo vědět musí.
Podle mne tohle delat nebude nikdo. Takze resit alternativni repozitories nema smysl.Správci alternativních repository toto mohou vyřešit. Ovšem je fakt, že je nutné jim ...
Takovy identifikator by klidne mohlo byt URL domovske stranky programu.... co nejvíce ulehčit (to znamená nepřidávat) práci a identifikace podle URL je skvělý nápad! Díky
Tiskni Sdílej: