Firefox pro iOS přichází s integrovaným blokováním reklam. Funkce je ve výchozím nastavení vypnutá a lze ji aktivovat v Settings > Browsing > Ad Blocker.
Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila (𝕏) open-source robota Microduck. Předobjednat jej lze za 340 eur.
Open-source autonomní AI agent OpenClaw (Wikipedie) byl vydán ve verzi 2026.8.1 aneb 2.0. Přehled novinek v poznámkách k vydání.
Byla vydána první veřejná preview verze PrusaSliceru 3.0. Přesně 15 let po zveřejnění první verze Slic3ru, které připadlo na 1. září 2011. Jedná se o dosud největší upgrade PrusaSliceru: "Řídili jsme se tím, co skutečně potřebujete, a tak jsme například zcela zahodili stávající uživatelské rozhraní a vytvořili ho znovu od nuly. Přinášíme také nový systém projektů, kompletně přepracované profily navržené pro moderní tiskárny s větším
… více »Byl vydán Mozilla Firefox 155.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Vypíchnout lze Smart Window, zatím ale dostupné pouze pro uživatele v USA, Kanadě a Francii. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 155 bude brzy k dispozici také na Flathubu a Snapcraftu.
Tima Cooka na pozici generálního ředitele společnosti Apple dnešním dnem nahradil John Ternus, který byl dosud odpovědný za hardware. Tim Cook vedl Apple od roku 2011, kdy funkci převzal od později zesnulého spoluzakladatele společnosti Stevea Jobse. Za 15 let v čele Applu více než zdvojnásobil tržní hodnotu firmy.
Organizátoři konference LinuxDays ukončil veřejné přihlašování přednášek. Teď je na vás, abyste vybrali nejlepší témata pro letošní ročník. Hlasovat můžete do pondělí 7. září, poté bude podle výsledků hlasování sestaven program pro letošní ročník.
Servo, engine webového prohlížeče napsaný v Rustu, byl vydán ve verzi 0.5.0. Novinky shrnuje přehled projektu za červenec. Došlo k dalšímu pokroku ve vykreslování webových stránek. Současným cílem projektu je vytvořit komponentu webového prohlížeče jako WebView pro použití v jiných aplikacích.
IKEA a XBOX představují kolekci YXSTABY (pdf). Ta přináší designová a praktická řešení, díky nimž se prostor pro hraní během sekundy promění v útulný a harmonický domov.
Jonathan Thomas oznámil vydání verze 4.0 nelineární střižny OpenShot. Nově podporuje nahrávání obrazu a zvuku, vylepšuje uživatelské rozhraní, mj. color grading, přidává další efekty a mnoho dalšího (seznam změn).
Řešením této situace, kdy balíčky mezi všemi distribucemi a jejich verzemi jsou vzájemně nekompatibilní, by bylo vytvořit program, který by podle zadaných metainformací sestavil balíčky pro všechny možné distribuce a verze. Balíčky by pak už nedělali tvůrci distribucí, ale samotní autoři programů, čímž by odpadlo mnoho problémů. Je jasné, že třeba řešení typu debian, kdy distribuce bude obsahovat úplně všechno, je do budoucna neúnosné.
Je třeba vytvořit něco, co bude podporovat různorodost balíčkovycích systémů, protože snahy o sjednocení (každý bude používat rpm, xxxpm, ...) jsou nereálné. To dá ale dost práce, do které se nikomu nechce.
Nastíním, proč si myslím, že toto není řešení.
Například v Debianu existuje nástroj alien, který umí překonvertovat rpm, tgz, ... do .debu, který pak lze přímo nainstalovat. Jenže ten původní balíček je dělán pro jinou distribuci, kde je třeba adresářová struktura vyřešena jinak než v Debianu (zrovna Debian má dost přísné podmínky, co musí splňovat každý balíček - debian policy). Hodně je to vidět třeba u init scriptů, Slackware používá BSD like, ostatní sysvinit like. Potom je tu problém s jinými gid vyhrazenými u té které distribuce. O závislostech nemluvě.
Je toho samožřejmě mnohem víc, co způsobuje, že alien nemůže plnohodnotně konvertovat rpm nebo tgz balíček na deb. A cokoliv co není deb způsobuje v Debianu problémy, prostě to nebude nikdy čistě fungovat.
Proto si myslím, že je lepší, když tvůrce balíčku místo rpm/debu vytvoří jakýsi metabalíček s tím, že už bude počítat s rozdíly mezi distribucemi, a tento balíček následně použije na výrobu výsledných rpm, deb, tgz, cokoliv ..., které už jsou kvalitní, protože všechno už obstaral program, který přežvýkal metabalíček na rpm, deb, ...
Nejde tu jen o to fyzicky překonvertovat balíček do výsledného formátu, ale o to, aby balíček měl určitou kvalitu. Nikomu by se nelíbilo, kdyby si nainstaloval binární program někam do /etc nebo /usr/share.
Proto taky tezce doporucuju pouzivat konzistentne vetsinu veci z jedne distribuce -- ovsem upkg jakozto backend umoznuje v pripade chybejiciho balicku jeho trivialni instalaci.
Ale přístup "každá distribuce bude obsahovat vše" je do budoucnosti neudržitelný. Ve winech se instaluje každý program přes setup.exe, který si může dělat co chce, nemusí zajistit korektní odinstalaci, etc., ale každý si může nainstalovat program přímo od výrobce. Mně tu jde o to, aby byla ta samá možnost i v linuxu, ale aby se využívalo výhod balíčkovacích systémů. Výrobce by mohl snadno vydat sadu balíčků pro všechny více používané distribuce a k tomu by vydal zdrojový metabalíček, pomocí kterého by si uživatel minoritní distribuce mohl binární balíček už sestavit jednoduchým způsobem a nemusel by instalovat někam do /usr/local.
Metabalicek je uz technicky vzato tezko implementovatelna vec... uz jenom proto, ze kazda distribuce ma mirne jinou hierarchii atd., jak jsi popsal vyse.
Já si myslím, že udělat jde. Prostě tvůrce programu by vytvořil určitý soubor (obdoba spec filu nebo debian/control), který by obsahoval informace, jak balíček zkompilovat, co obsahuje, atd. a předhodil by to tomu nástroji. Ten by z toho sestavil source balíčky pro distribuce, pro které by bylo třeba. Pak by se třeba v chrootu nebo přímo na těch distribucích tyto balíčky prohnaly kompilátorem a binární balíčky jsou na světě.
Šlo by tím tvořit balíčky i pro různé architektury, což bude do budoucna důležité. x86_64 bude používat stále více lidí. Zdrojový balíček by už existoval a v chrootu s cross-compilerem by se jenom sestavil binární balíček pro x86_64.
Je tu i hodně zádrhelů. Kdyby chtěl vývojář tvořit balíčky pro mnoho dister, musel by mít hodně chroot prostředí a to by zabíralo místo. Ten samotný nástroj by bylo jistě těžké napsat, protože by musel ošetřovat vlastně všechno, co může balíček obsahovat - binárky, manuálové stránky, game binárky, konfigurační soubory, /var/games/..., dokumentace, info soubory, /usr/share/..., menu soubory, preinst a postinst (ty by se nemohly psát přímo), init scripty (ditto), knihovny, /bin, /sbin, atd.
Nešlo by to třeba používat na moc složité balíčky, které by třeba obsahovaly jaderné moduly (to by byl asi dost problém). Pak by se muselo ošetřit všechno možné, co se dá dělat v preinst a postinst scriptech pomocí generických volání, to samé pro init scripty. Dále třeba funkcionalita alternatives v Debianu, nevím jak jsou na to ostatní distra.
To, ze nektery balicky jsou smejdy nejvetsi, je smutna vec -- ale to riziko na sebe clovek bere kdykoliv, kdy bere balicek mimo distribuci (a i v ramci distribuce jsou obcas hodne zajimavy ulety)
Právě ten balíček, co by byl vytvořen tímto postupem, by měl zajištěnu určitou kvalitu třeba ohledně preinst a postinst scriptů a souborové hierarchie.
Zkusím to vysvětlit ještě jinak, o co mi konkrétně jde.
Tvorba balíčku = adaptace na konkrétní distribuci. Když je program rozumně vytvořený (tzn. používá autoconf, automake správně, rozumí cestám, které jsou mu předány pomocí ./configure parametrů), tak je ta adaptace celkem snadná. Pak vůbec nezáleží na tom, jestli distribuce dodržuje FHS nebo ne. Je akorát třeba stvořit preinst a postinst, vytvořit popisek balíčku, atd. To je pro každou distribuci vlastně stejné, takže by to šlo dělat genericky.
Tvůrce programu by se musel držet při tvorbě Makefilů nebo configure.ac/Makefile.am zdravého rozumu a nepoužívat různé špinavé triky. To by měl vlastně dělat i když nebude pak program balíčkovat on sám. Takovýto program je pak vcelku snadné zabalíčkovat, je to generický postup. A hlavně je pro většinu distribucí stejný. Jenom je v každé distribuci něco odlišného, třeba Slackware neřeší závislosti, Debian má priority a sekce balíčků (u rpm nevím, jak je toto vyřešené), a tak dál.
Prostě si myslím, že balíčkování je zbytečná činnost, která by se nemusela dělat, kdyby autor programu dodržoval jisté (přesně dané) konvence a balíčkovaní by potom mohlo proběhnout strojově.
V žádném případě se tu nesnažím vytvořit utopii, jen si myslím, že jistá činnost se zbytečně duplikuje při tvorbě balíčku jednoho programu pro různé distribuce.
Není už těch balíčkovacích systémů nějak moc?<fb> Je. Navíc když už tu 12 let spolehlivě funguje Slackware package management
</fb>
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz