Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
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.
Poměrně často opomíjenou skutečností je fakt, že balíčkovací systém používají různé skupiny uživatelů mající různé potřeby a požadavky. Jejich skloubení není vůbec jednoduché, ale je nezbytné.
Základní požadavek běžných uživatelů by se dal shrnout do věty Ať je to jednoduché a především pořád stejné. To znamená, že všechny základní operace jako instalace, odstranění, upgrade nebo nastavení musejí být jednoduché a především konzistentní.
Podobné požadavky mají správci. Ti bývají navíc zodpovědní za bezpečnost spravovaných systémů, takže ocení kryptografické zabezpečení balíčkovacího systému (nejčastěji pomocí GPG) pro jeho větší důvěryhodnost. Ovšem i jim by se hodil jednotný způsob instalace např. bezpečnostních aktualizací. Navíc by pro ně bylo občas vhodné mít možnost vedle sebe nainstalovat několik verzí paralelně, což stávající systémy neumí.
Distributoři se naopak tváří, že právě jejich distribuce je tím pravým řešením. Prostě stačí, aby všichni vytvářeli balíčky pro tu konkrétní distribuci, a problém je vyřešen. Ovšem jedna z mála věcí, na níž se uživatelé různých distribucí shodnou, je, že právě ta, kterou používají, je ta nejlepší. Myšlenka dominantní distribuce, pro kterou budou všichni primárně tvořit balíčky, nevypadá reálně; tím spíš, že za poslední tři čtyři roky se do mainstreamu protlačily dvě, které mají svůj vlastní formát balíčků (Gentoo a Arch Linux). Daleko větší naděje se vkládají do aktivit jako LSB, které by měly vést k vytvoření společného základu pro různé distribuce. Problém je v tom, že balíčky třetích stran nemají podporu v instalačních nástrojích dané distribuce. Požadavek distributorů je nicméně jasný: chtějí mít co největší kontrolu nad instalovaným softwarem, protože nejsou schopni zajistit stabilitu/bezpečnost těch částí systému, které pocházejí od třetích stran. Na druhou stranu se v distribucích běžně vyskytuje spousta podobného softwaru - binární kodeky, Flash pluginy nebo třeba Opera.
Vývojáři zase potřebují jednoznačný způsob, jak vytvářet software dostupný i pro Linux. Poskytování binárky pro každý typ linuxového systému není vůbec jednoduché. Bez možnosti využívat definované a dostupné nástroje například pro updaty nebo konfiguraci se vývojáři ocitají ve stejné situaci jako na Windows, kde musí podobné věci řešit každá aplikace vlastními prostředky. Problém tvorby binárních balíků by mohl v budoucnu vyřešit OpenSUSE Build Service. Vývojáři navíc chtějí zasahovat do nainstalovaných knihoven, což je v Linuxu tradiční oblast distributorů.
Pojem distribuce jako třeba Debian GNU/Linux zahrnuje jádro Linux, základní systémové utility (coreutils a binutils), systémové knihovny (glibc, uclibc), systém init skriptů, různé podpůrné nástroje (update-alternatives) a hlavního hrdinu — balíčky ve formátu .deb. S těmi pracuje nástroj dpkg a jeho nadstavby apt, aptitude, nebo synaptic. Stejně tak distribuce Gentoo má svoje ebuildy ve stromu Portage, svůj nástroj ebuild a vysokoúrovňový emerge. Fedora má zase svoje rpm s programem rpm a nadstavbou yum. Jiné distribuce založené na rpm mohou obsahovat yast (SUSE), urpmi (Mandriva), nebo cokoliv jiného.
Všechny tyto nástroje v konečném důsledku dělají to stejné. Stáhnou odpovídající balíček, jeho případné závislosti (až na installpkg, který takto nefunguje) a vše nainstalují a nastaví. Máme jednotný způsob instalace balíčků, jednotný způsob prohledávání, jednotný způsob prohledávání nainstalovaného softwaru, jednotný způsob odebírání a také jednotný způsob updatů, o něž se samotné aplikace nemusí starat.
Balíčkovací systém tak nabízí samá pozitiva a sociální jistoty. Stará se nám o pořádek v systému, zajišťuje, že se aplikace stáhne a nainstaluje se všemi potřebnými závislostmi, že nám zlovolně napsané balíčky nebudou přepisovat soubory jiných balíčků, a odvádí spoustu mechanické a užitečné práce - třeba to, že nemusíme nic stahovat ručně. Poměrně opomíjenou (i když velice podstatnou) výhodou balíčkovacího systému je, že nejste vydáni na "milost" schopnostem tvůrce softwaru, ale používáte ověřený balíček (nejste-li příznivcem experimentálních verzí). Máte automaticky zajištěné updaty, takže jste chráněny před chybami, které se v softwaru najdou. A to nejlepší nakonec: toto vše se děje naprosto automaticky (ano, pokud nejste ten, kdo vytváří balíčky), takže autor softwaru se o nic podobného nikdy nestará. Těchto výhod by se mnoho uživatelů velmi nerado zbavovalo.
Tento přístup sebou nese i nevýhody. Vezměme si třeba program psi. Ten existuje v jedné binární formě pro Windows, v další pro systém OS X, ve formě platformně nezávislých zdrojových kodů. Dále potom jako balíček v x verzích pro distribuce Arch, Debian, Fedora, SUSE, Ubuntu, Mandriva, ... Nepříjemnou vlastnostní balíčkovacích systémů je skutečnost, že zvyšují počet vzájemně nekompatibilních verzí. Je však třeba říct, že takové Psi je poměrně známá open source aplikace a distributoři (více či méně) mlčky odvádí tu špinavou práci, takže ji máme jednou ve verzi pro Debian, podruhé pro Fedoru, potřetí pro Mandrivu, ...
Potíž v současném pojetí balíčkovacích systémů je jednak v tom, že vedou k obrovské duplicitě práce distributorů, ale hlavně v obrovském množství verzí toho stejného softwaru. Příkladem budiž Opera, která nabízí více jak 50 binárních balíčků pro různé verze různých distribucí. Toto číslo je až neuvěřitelně velké. Ovšem Opera vytváří svůj prohlížeč pro více jak 11 platforem (nepočítaje mobilní verze), tudíž pro ně nemusí být takový problém upravit svůj release tak, aby zahrnoval i více jak 50 binárek pro různé distribuce.
Nicméně, za současného pojetí, pokud jako vývojář vytvořím jednoduchou aplikaci, jsem de facto nucen vytvářet hromady binárních balíčků. Pokud ty balíčky přesto nějak udělám, nebude mít uživatel možnost aktualizace, protože ta se týká pouze softwaru z repozitáře. Pokud udělám staticky slinkovanou verzi, ztrácím veškeré důvody k používání balíčkovacího systému jako takového a mohu rovnou používat třeba GoboLinux. Pokud vystavím pouze zdrojové kódy, nutím tím uživatele si software zkompilovat (což ne každý zvládne nebo chce dělat) a buďto nainstalovat natvrdo, nebo udělat vlastní balíček (který se jen tak do repozitáře nedostane).
Stejně tak není možné vytvářet x balíčků pro tak drobné věci jako rozšíření Firefoxu nebo témata vzhledu. Respektive, možné by to bylo, ale vývojáři distribucí si rozhodně na nedostatek práce nemohou stěžovat a toto pro ně není tolik zajímavé. Takže stávající balíčkovací systémy mají jistou granularitu a i když by bylo hezké mít součástí distribuce i takový Adblock, nikdo to nedělá a raději systém obchází. S tím pak souvisí i potíž, že málokdo bude chtít updatovat distribuci jenom proto, že vyšla nová verze jeho oblíbeného rozšíření.
Druhou stranou mince jsou "third-party" aplikace, které z nejrůznějších důvodů v repozitářích nejsou. Příkladem může být sqldeveloper od Oracle, Netbeans od Sunu (kvůli licenčním omezením) a tak dále. Výrobci softwaru to většinou řeší tak, že aplikaci udělají v rpm (jsou certifikovány Red Hatem) a někdy i statickou binárku. Protože z mnoha důvodů není možné, aby byl takový software v rukách tvůrců balíčků jednotlivých distribucí, pro tyto aplikace neplatí vůbec žádná z výše uvedených výhod balíčkovacích systémů. Dokonce nikde nemáme v systému záznam o jejich instalaci - není žádný standardní prostředek, který by systém řekl, že tam a tam je ta a ta aplikace.
Prostě, v současné době existují pouze dva stavy:
Že je něco špatně, napoví i blogpost Software installation on Linux: Today, it sucks (part 1) od nikoho menšího než Iana Murdocka, zakladatele distribuce Debian. V jeho příspěvku naleznete i odkaz na porovnání postupu instalace Sun Studia na Windows a linuxové distribuci. Free Standard Group a její pracovní skupina LSB se ovšem zabývaly (počátek roku 2007 došlo ke sloučení FSG a OSDL, vznikla Linux Foundation) řešením tohoto problému na dvou úrovních. LSB definuje standardní množinu softwaru, který by měla distribuce obsahovat. To by mělo vyřešit potíže se závislostmi, protože aplikace si pouze zkontroluje (pomocí lsbappchk) přítomnost potřebných lsb balíčků, které by měly být v každé běžné distribuci.
Na prosincovém summitu LSB face-to-face (December 2006) se hovořilo o způsobu, jak by nezávislí producenti softwaru (ISV — Independent Software Vendor) mohli mít více kontroly, což se logicky střetává s odporem distributorů a velké části uživatelů.
Ve druhé části svého blogpostu Software installation on Linux: Tomorrow, it won't (with some cooperation) (part 2) Ian Murdock asi nadzdvihnul poměrně značnou část uživatelů.
After reading through the comments to part 1, let me first point out that our goal is to create a vibrant third party software ecosystem around Linux-you know, like the one Microsoft has built around Windows. No, it's not about imitating Microsoft. It's about being competitive. A platform is only as good as the applications that run on it.
Po přečtení komentářů k první části mi dovolte upozornit na to, že naším cílem je vytvořit živý a pulsující ekosystém nezávislého softwaru kolem Linuxu — něco podobného, co vytvořil Microsoft kolem Windows. Ne, není to o napodobování Microsoftu. Je to o tom být soupeřem. Platforma je pouze tak dobrá, jak dobré jsou aplikace na ní běžící.
FSG se rozhodlo vytvořit most mezi propastí, která je mezi tím, co distribuce potřebují a tím, co požadují ISV. Problém zní Jak? Z hlediska ISV by bylo nejlepší, kdyby pojem Linux zahrnoval jednu platformu, což znamená, že by stačilo zabalit software do nějakého definovaného formátu - stejně, jako je tomu ve Windows. Někteří (jako například Michael Leibowitz ze společnosti Intel) dokonce navrhují vznik nového balíčkovacího systému pro tyto aplikace (vizte některé nezávislé balíčkovací systémy).
Ovšem v následné diskusi se většina lidí shodla na vytvoření základního API, které bude spojovat dnešní existující balíčkovací systémy. Velkým usnadněním práce pro tvůrce může být, že většina ISV nebude potřebovat žádné složité operace. Většinu instalací by dokonce mohl řešit pouhý dotaz na to, zda systém obsahuje potřebné lsb závislosti (a jejich případné stažení plně v režii stávajícího balíčkovacího systému) a nějaký způsob registrace souborů, které s sebou software do systému nese (zde je nezbytně nutné, aby balíčkovací systém kontroloval instalované soubory, protože v opačném případě se ztratí jedna z nejužitečnějších funkcí tohoto systému). Ovšem vše je ještě ve stádiu příprav a spousta problémů není vůbec vyřešena. Proto vznikla pracovní skupina Packaging, která bude mít tuto problematiku na starosti.
Doufejme, že se podaří překlenout dnešní propast mezi centralizovanými a nekompatibilními repozitáři a balíčky třetích stran, ať se to týká rozšíření Firefoxu, pythonních vajíček, nebo aplikací od větších či menších společností. A to tak, aby dnešní nepopiratelné výhody instalace softwaru v Linuxu prostřednictvím balíčků a repozitářů zůstaly zachovány. Ovšem úkol to není nikterak jednoduchý.
V současné době není konference příliš aktivní (jak napovídá pohled do archívu) a navíc existuje pouze návrh API, který ovšem, z mně neznámých důvodů, v archívu konference chybí.
LSB definuje jako výchozí formát balíčků rpm s některými omezeními, která se týkají pojmenování, vlastností, virtuálních balíčků a závislostí. Protože se v mnoha případech nejedná o nativní formát, existuje nástroj alien, který jejich instalaci umožní. Dalším problémem může být fakt, že i když se jedná o formát používaný velkou částí distribucí, jednotlivé implementace se poněkud liší. Navíc vývoj tohoto nástroje dlouho stagnoval.
Specifikace také nedefinuje standardní způsob instalace/odstranění/upgradu balíčků, takže si to každá distribuce řeší sama. Program rpm je nízkoúrovňový nástroj, který používají vysokoúrovňoví správci jako rug, yum, yast, urpmi, apt4rpm anebo distribučně nezávislý smart. Ovšem přesné postupy, jak provést instalaci, jak spravovat repozitář a podobně, jsou distribučně závislé. Každý nadstavbový systém to řeší vlastními prostředky.
LSB rovněž zavádí omezení závislostí a virtuálních balíčky. Jak je stanoveno, balíček nesmí záviset na nějakém ne-LSB balíčku. Toto ovšem komplikuje situaci, kdy nejsou k dispozici žádné jednoznačné názvy. Každá distribuce si svoje balíčky (i ty virtuální) pojmenovává jinak. Například na Debianu existuje virtuální balíček mail-transport-agent, který zahrnuje sendmail, postfix, exim a jiné. Stejná věc se ovšem na Fedora Core nazývá smtp-server. Naprosto stejná situace panuje v systému pojmenování balíčků, kde opět platí, že každá distribuce má vlastní systém.
Příště se podíváme na zoubek existujícím distribučně nezávislým balíčkovacím systémům. Na řadě bude autopackage.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
a co by v základu distra nebylo tak si ostatní dodavatelé zkompilujou staticky a FUCK OFF! jednoduchý jako facka... mohl by se dodávat také i bez balíčkovacího systému nějaký binární základ linux+ programy a kdo by chtěl tak by jsi to ztáhnul a nadstavěl by jsi na to vlastní desktopový distro. Jo a ještě jedno řešení vidím: přejdeme na redhat, suse a nebo rovnou na SOLARIS páč tyhle komerční věci jsou jednoduše komerčnímy společnostmi podporovány a kam se hrabe ubuntu pánové (samozřejmě komu stačí firefox tak nekomerční distro kolikrát stačí). )
27.3.2007 01:42
Sešívaný | skóre: 23
| Brno
A na to seti každá firmy víš co, vysere...
27.3.2007 02:14
Sešívaný | skóre: 23
| Brno
27.3.2007 08:45
hwsoft | skóre: 19
27.3.2007 08:46
hwsoft | skóre: 19
PS tedka jsme se koukal na stránky dodavatele a podporuje pouze Solaris a RedHAt. A linuxová verze je jenom na 32 bit s tím že po verzi 3.0 končejí z podporou linuxu a zustane jenom windows a solaris vole! SW podpora
Jinak samozřejmě konkrétně vím o rozjetým Pro/Ečku na SUSE, DEBIANU, Gentoo,.....
27.3.2007 22:10
otula | skóre: 45
| blog: otakar
| Adamov
Vladimíre, prosím tě, piš své příspěvky až po přihlášení. Mám tě blokovaného, takže se mi tvé výplody nezobrazují. Když už chceš psát nechutně, buď alespoň ohleduplný k těm, kdo to nemají chuť číst.
PS: Možná by byla dobrá možnost volit blokování i podle IP adresy.
28.3.2007 03:16
Prcek | skóre: 43
| Jindřichův Hradec / Brno
. Pred dvema dny jsem si Vladimira zablokoval (a to jsem si myslel, ze tuhle funkci nikdy nevyuziju) a on jako na potvoru zacal psat neprihlaseny - no to by mi z toho jeblo, Ivanku .
Navic podpora se nabizi pro ty distribuce kde to ma smysl (velky podil na trhu). Pokud se nejaka firma rozhodne vyvijet a nebo portovat svoji aplikaci na Linux tak vetsinou se setkate s podporou RHEL, mozna jeste SUSE.Až někdo vymyslí, jak by bylo možné, aby nebyla každá distribuce více či méně samostatným operačním systémem, tj. aby byly všechny distribuce totožné a lišily se snad pouze výchozím nastavením wallpaperu a barvami, tak to dejte těm firmám vědět. Budou jistě nadšené tím, že SUSE bude totéž co Red Hat což bude totéž co Mandriva. Skvěle se na to bude dělat reklama a skvěle se to bude prodávat. Měli bychom si konečně zvyknout na to, že linuxové distribuce jsou prostě svébytné operační systémy podobného typu a přestat se tomu divit a stěžovat si na to. Monokultura, ač má jistě své finanční výhody, má také degenerativní nevýhody (např. Windows Vista
).
kdžytak kdyby něco nechtělo jet tak mě pošli výpis z příkazovky na muj mail vzima at centrum.cz a já se ti pokusím poradit pokud budu vedět. Pro/E komunita na linuxu je zatí dost malá no...
27.3.2007 09:09
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Je jen otazkou casu kdy Ubuntu Shuttleworthovi zacne vydelavat...pokud uz tomu tak neni ted. Jen tak lejt do distra prachy, ktery neutratil na vylete po vesmiru, to by byla neudrzitelna kravina a Mark to vi.
27.3.2007 10:10
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Spis vam nedochazeji nektere souvislosti, treba ze na software se da vydelavat aniz by se primo prodaval...
27.3.2007 21:24
LFCIB | skóre: 19
| blog: LFCIB
| /home/lfcib
Jenoduše jendou za rok se vydá nějaká papírovaá kravina jak má linux + programy vypadat jaká má bejt verze programů a to jak si to distributoři namíchat, adresářově je už jejich věc.To by měla dělat právě LSB, ovšem skutečně netuším, jak moc se distributoři snaží něco takového dodržet. Já mám takový pocit, že od distributorů se nějakého sjednocení nedočkáme, ten popud spíš musí vyjít od uživatelů a vývojářů. Ovšem nezdá se mi, že by byla vůle toto řešit.
27.3.2007 03:28
Josef Kufner | skóre: 70
Maximalne jsou uzivatele zvykli doinstalovat nove DirectX. Tento bordel ovsem nechceme, ze. Reseni je treba jeden centralni repozitar proti kteremu by se kompilovalo a potrebne zavislosti se dohravali k aplikaci ci do systemu odtamtud. Ovsem to zni jako zmena distribuce )
28.3.2007 07:09
Max | skóre: 72
| blog: Max_Devaine
. Výsledky stručne:
- xml (nechce sa mi písať entity, tak [])
- dedičnosť balíčkov / verzií (inšpirácia WURFL)
[version version="8.0" major-version="8.0" extends="7.4"/] [version version="8.0" extends="8.0"/] [version version="8.1" major-version="8.1" extends="8.0"/] ...- optional depenedencies
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
[configure type="autoconf"]
[option name="with-jpeg" default="no"]
[requires package="lib-jpeg" min-version="..."/]
[/option]
...
- bundle balíčky (aj bundle balíčkov)
[package name="my-slackware"]
[use package="slackware" version="10.0"]
[without package="mysql"/]
[with package="kernel" version="2.6.20"/]
[with package="php"]
[option name="with-pgsql"/]
[/use]
[use package="postgresql" version="8.2.3"/]
...
- predefinované nastavenie (napr balíček vyžaduje špeciálne uid/gid)[require resource="shm-max" min-value="200000000"/] [require resource="user" value="postgresql"/] [require resource="group" value="dbmaster"/]Finálna inštalácia je len ďaľší bundle.
momentálny stav: zamrzol som
linkujte staticky a vsechen ten bordel s balicky dependencema na libech a cojavimcojeste odpadne. Navic se vam nestane ze "upgradem" nejaky knihovny rozsypete system. Dynamicke linkovani je prezitok z dob kdy sme meli 16MB RAM tak se setrilo kde se dalo, ted kdyz je standard 1-2GB muze byt klidne vsechno zlinkovano staticky a "jedna binarka bude vladnout vsem" :) (dobra, dve binarky, jedna pro i386 a jedna pro x86_64 :)Takže když se najde (bezpečnostní) chyba v nějaké často používané knihovně (třeba zlib), musí všichni autoři vydat nové verze svých programů, které jen slinkují s novou knihovnou? Jak dlouho bude trvat, než tak opravdu všichni učiní? Jak dlouho bude trvat, než všechny ty programy všichni nainstalují?
Ano, ssouhlas. Mám Mandrivu, ta je dobrá, ale dneska jsem zkoušel Ubuntu, zkusmo instaloval blbý program, chtělo to pár lib... Výsledek? Přestal jít Adept, styl oken ten nejhnusnější hnus... Ubuntu letí z disku. Kdyby se byly knihovny instalovaly někam k programu a ne do systému, by se to nestalo.Asi by bylo zábavné, kdybyste sem popsal podrobnosti. Tohle vypadá spíš na klasickou fušeřinu při instalaci "blbého programu" ještě blbějším frikulínem
. V linuxu se dost orientuji. Baví mně skripty, kommandlajna mi není cizí. Ale mám rád hotový základ - proto Mandriva. Jen jsem chtěl po roce vyzkoušet, jestli už je tolik vychvalované Ubuntu dobré. Není. Je pravdou, že jsem blbnul i s Alienem a tak..
27.3.2007 21:54
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
Tak jo, admine. Dám Vám 3k jako za Win a Vy budete po dobu 5 let jezdit 2x denně mi domů adminovat počítač. Platí?Snad 3k za instalaci a optimální nastavení kompletního desktopu (automatizované aktualizace pouze jako bezpečnostní záplaty). I tak za ty peníze dostanete x-krát víc než "jako za Win"
Ano? A proč mi do ICQ účtu chodí od pěti lidí nějake hlášky na porno weby, mají zavirované windows, přitom se jednomu aktualizuje, i má zaplý firewall a sám si nainstaloval antivir a stejně se mu tam nějaký šmejd dostal (toho už bych ohodnotil jako pokročilého uživatele, možná že si tak ceníte uklízečky, netuším), atd..
Nezdá se mi že by obyčejní uživatelé nějak administraci zvládali. Spíše jsou rádi že jim to nějak funguje a pokud něco nejde, tak to nepoužívají, vyhýbají se tomu a obcházejí to (například v jednom diskusním fóru dotyčný na konec každého příspěvku napsal, že pokud tam uvidí link, ať na něho neklikají, že má zavirovaný pc).Proto nakonfigurování, nainstalování OS (a základních aplikací) a poučení o bezpečnosti uživatele administrátorem je docela nezbytné k bezproblémovému chodu stanice a to jak u windows, tak u linuxu.
Samozřejmě že si uživatel může občas doinstalovat program pokud ví jak (napsat apt-get jmeno_baliku po instruktáži či poklikat na důvěryhodný setup koupené aplikace, atd...). Ale těžko si vaše uklízečka nastaví firewall či antivir a bez toho to pak vypadá jak to vypadá.
Všetko, čo popisujete, už zvládnu existujúce balíčkovacie systémy. Problém je napr v pomenovaní, čo balíček žiada. Knižnica môže byť kdekoľvek (/lib, /usr/lib, /usr/local/lib, /opt/*/lib, ...), balíček sa môže rôzne názvy (jpeglib, lib-jpeg, ...).Centralizovať imho treba, názvoslovie, postupy (čo iného vlastne sú vaše návrhy, ako centralizovanie postupov?)
imho sa treba pozerať nie na používanie balíčkov, ale na ich tvorbu, tam sú rezervy.
)? Zavislost se vam zjisti jeste pred instalaci binarky (dokonce pred stazenim potrebneho balicku, na kterem to zavisi) a stazeni a doinstalovani binarky(dalsiho balicku) vam to navrhne a event. provede. Tedy pokud k dispozici je. A pokud neni, tak jste stejne v identicke situaci.
Pokud něco důležitého chybí, dá se to bez problémů nainstalovat (NeoOfficeJ, Firefox aj.), nikdo nemá problém.Ano, nemá problém. Pokud však existuje port pro Mac OS X U linuxových aplikací má každý možnost přiohnout je k obrazu svému.
Linux je jedna velká hromada. Všechno je pohromadě v jednom adresářovém systému (v MacOSX je podobný, ale ne pro uživatelské aplikace) a nainstalovat něco bez rootovských práv a/nebo odděleně od všeho ostatního je nadlidský úkol, snad jen s výjimkou Java aplikací. Navíc toho software jsou pro Linux oceány a oceány...No právě, každý má jiné gusto. Jenže existuje ta drobná nuance mezi administrací a užíváním systému. I v linuxu je možný vámi oblíbený postup. Nicméně Linux je z principu víceuživatelský systém. Tzn. uživatelské aplikace se instalují z jedné vody pro všechny co k nim mají mít přístup. Cpát je do každého uživatelského adresáře extra je z principu špatná volba.
Přiblížit tyhle dva systémy nejde, právě kvůli tomu rozdílnému přístupu uživatelů. Linuxákům většinou nevadí, když se musí rochnit s výběrem distribucí, alternativních desktopů, programů atd... baví je to. O tu svobodu nechtějí přijít, takže tu vždycky bude roztříštěnost a nějaká LSB to nespraví. Jabkáři používají počítač jako vrtačku, nepotřebují vědět, jestli náhodou někde není lepší rukojeť, vypínač, nebo kolečko, ani o tom nechtějí přesvědčovat ostatní. Prostě vyvrtají a šlus:) Zde bych si dovolil přirovnání k Windowsákům, kteří za své peníze místo vrtačky dostali nebozízek, takže jim nezbývá než poohlédnout se po náhradních dílech:DNení to jen o tom že se linuxáci v systému rádi rochní. Spíš naopak. Je to o tom, že Mac OS X je orientovaný především na desktop a jako takový spoustu problémů neřeší, nebo je řeší jinak. Linux má zase dispozice pro to být skutečně masově používaným systémem. I když tomu česká realita zatím nenasvědčuje.
Prečo väčšina aplikácii pod Linux je napísaná neunixovo? Žeby preto, aby sa ľahšie portovali? Prečo napr neexistuje jedno (abstraktné) GUI, s implementáciou gtk+, qt, motif, ... podľa vkusu usera. Prečo napr pre správu mailov neexistuje jeden lokálny unix-socket daemon, vymeniteľný bez nutnosti zmeny aplikácie?
preferred file open dialog = file-open-gtk preferred widget set = qtvýsledok? funkcionalita file-open-gtk (ktorý by nevyužíval priamo gtk_* widgety, ale tie abstraktné) s qt widget setom, vo všetkých aplikáciach.
a ak vravíme "zrovna" o mail klientoch, tak osobne by som ich rozdelil na tri časti: retrieve (napr fetchmail), local-storage(-daemon) a klient. Napríklad.
27.3.2007 19:09
MaT | skóre: 28
predstavte si usera, NFS /home, non-root prístup k stroju, presúvajúceho sa medzi rôznymi strojmi
Ano, nemá problém. Pokud však existuje port pro Mac OS X U linuxových aplikací má každý možnost přiohnout je k obrazu svému.
Nechápu na co reaguješ, tak se zdržím komentáře. Snad jen na vysvětlenou - psal jsem o snadnosti instalace těch portů, ne o tom, zda existují, nebo jak snadno jsou dostupné.
No právě, každý má jiné gusto. Jenže existuje ta drobná nuance mezi administrací a užíváním systému. I v linuxu je možný vámi oblíbený postup. Nicméně Linux je z principu víceuživatelský systém. Tzn. uživatelské aplikace se instalují z jedné vody pro všechny co k nim mají mít přístup. Cpát je do každého uživatelského adresáře extra je z principu špatná volba.
OsX je taky z principu víceuživatelský. Střídám se na Macu s jiným grafikem a práva instalovat programy má jenom ajťák. Dohromady používáme jednu sadu grafických aplikací a každý má na svém účtu svoje dodatečné programy (MacAmp, ICQ...), které si nainstaloval sám. Opět nechápu, s čím bych měl být nespokojený
Není to jen o tom že se linuxáci v systému rádi rochní. Spíš naopak. Je to o tom, že Mac OS X je orientovaný především na desktop a jako takový spoustu problémů neřeší, nebo je řeší jinak. Linux má zase dispozice pro to být skutečně masově používaným systémem. I když tomu česká realita zatím nenasvědčuje.
Opět nechápu, pro co/proti čemu je tahle reakce... Nepsal jsem o rochnění v systému, ale o někdy křečovitému vybírání té jediné správné distribuce, aplikace apod. a také o lpění na tom výběru a jeho fundamentalistickém obhajování. Omlouvám se, jestli jsem se nevyjádřil jasně.
My se vlastně vůbec v ničem nerozcházíme, článek i moje reakce byly o instalaci balíčků, já jen přidal svoje subjektivní porovnání s Macem. Nepsal jsem to proto, abych říkal, že Linux je na hovno:)
Mimochodem, doma používám téměř výhradně Linux už nějakých 8 let, jen abych někoho nemátl, že snad za něco válčím...
27.3.2007 18:28
Prcek | skóre: 43
| Jindřichův Hradec / Brno
).
27.3.2007 20:53
otula | skóre: 45
| blog: otakar
| Adamov
+1
Naprostý souhlas, i když Gentoo nepoužívám. Používám Arch. A ABS systém je tomu Gentoovskému velmi podobný. Na Arch se dívám jako na distribuci, kde je možno si balíčky, u kterých mi nezáleží na optimalizaci, stáhnout zkompilované (i když je asi servírována spíš opačně - že je možno si některé balíčky zkompilovat). Je velmi sympatické, že k mamutům, jako xorg, kde, openoffice, někdo šikovnější vymyslí postup, jak je optimálně zkompilovat, a zveřejní ho. A u ostatního softwaru mne vůbec, ale opravdu vůbec, netrápí, jestli jsou, nebo nejsou, v repozitáři. Prostě si napíšu PKGBUILD a udělám si svůj balíček, takže celá problematika kompatibility a závislostí balíčkovacích systémů/balíčků odpadá.
Predem se omlouvam za to, ze nemam cas cist vsechny prispevky v diskuzi, takze nevim, jestli uz nekdo neco podobneho nerikal, ale zkusim nastinit muj nazor na vec z pohledu developera programu pro windows a linux.
Podle me je soucasna situaci hodne nevyhovujici. Vemte si, ze chce clovek vytvaret program s nejnovejsi knihovnou X, ktera ma verzi pro windows i linux. V repozitarich vetsiny distribuci je knihovna X ve starsi verzi, kterou nelze pouzit kvuli chybam (nebo nedostacujicim vlastnostem). Nezbyva tedy nic jineho nez staticky linkovat aplikaci s nejnovejsi knihovnou, cimz ale napriklad prijdeme o specificke nastaveni systemu (co se tyce QT4 tak prijdeme o prebirani temat z KDE atd.), nebo dodat knihovnu jako balicek do distribuce (s cimz je spojeno vytvoreni vlastniho repository + extra prace + moznost kolize knihoven mezi sebou atd)
Proste kdyz chce clovek delat program pomoci nejnovejsich prostredku, tak je to z hlediska pouzitelnosti programu zbytecne, protoze nepujde spustit rozumne nikde...
Naproti tomu na windows (vim, ze je to dano "systemem" "spravy" aplikaci, ale to srovnani si neodpustim), jednoduse pribalime knihovnu k programu a vytvorime instalator, ktery ji pak i odinstaluje. Vim, ze z hlediska spravy SW to je oproti linuxu o nicem, ale pro uzivatele to je Just Works. A tahle vec mi na linuxu chybi.
Jestli vi nekdo o rozumne ceste, jak vytvaret SW pro linux s pouzitim novejsich verzi knihoven, nez jsou v repozitarich, tak se rad priucim :).
27.3.2007 22:13
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
27.3.2007 22:17
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
27.3.2007 23:06
Mintaka | skóre: 13
Já ten linuch moc nechápu. Když ve Windows vyšla nová verze nějakého programu, stáhl jsem setup.exe a nainstaloval. A bylo to. Když vyjde nová verze linuxového programu, jsem s mým Ubuntu v koncích. Musím počkat, až se distributorovi uráčí tu novou verzi nacpat do distribuce místo té staré a až na to dojde, musím aktualizovat všechno a doufat, že se nic nepokazí. Tohle má být nějak lepší způsob? Nechápu.Opominu, že je to evidentní flamebait a že se jeho stvořitel samozřejmě nehodlá přihlásit, protože se mi zrovna odpovědět chce. 1) Především musí člověk sám hlídat, kdy vyjde nějaká verze programu (a nikoliv ve Windows, ale pro Windows). U jednoho či dvou to ještě může být zábavné, ale u všech, co má člověk nainstalovány? Uživatel linuxové distribuce toto zjistí zpravidla několika povely: nemusí ani hledat, ani stahovat, prostě jen vydá příkaz: aktualizuj systém včetně programů. 2) Distributorovi se uráčí nacpat novou verzi do distribuce zpravidla poté, co ji někdo vyzkoušel a zbavil základních bugů. To také stojí za to, že máte některé programy k dispozici o pár dní či týdnů později: že už je někdo jiný vyzkoušel. 3) Pokud ale tu trpělivost nemáte anebo novou verzi skutečně nutně potřebujete (anebo se chcete podílet na testování), mají solidní distribuce něco jako experimentální větev, kam se zařazují ty nejnovější programy velmi aktuálně, a kromě toho nabízejí postup, jak si vytvořit ze zdrojových kódů balíček pro vlastní distribuci. Shrnuto: instalace programů pro Windows je z hlediska jejich aktualizace předpotopní a velmi nepohodlná záležitost, protože viděno komplexně nevyváží pohodlí uživatelů linuxových správců balíčků ani možnost instalovat jeden program stylem next next finish.
nevyváží [...] možnost instalovat jeden program stylem next next finish.Nehledě na to, že většina distribucí nabízí možnost instalace i aktualizace ještě přímočařejší než "next next finish".
29.3.2007 03:09
Prcek | skóre: 43
| Jindřichův Hradec / Brno
.
ovšem něco jako sloty imo nemá ...
Osobne, keď potrebujem, to riešim post-install skriptom, ktorý presunie obsah balíčku do (napr)/usr/Linux/{package}/{version}/. Pre hlavnú verziu urobí
ln -s {version} current
cp -Rs /usr/Linux/{package}/current/* /
/usr/lib/jvm/java-1.5.0-sun a verze 1.6 je v /usr/lib/jvm/java-6-sun. Ovšem java je v Debianu výjimka, protože to technicky jsou dva různé balíky sun-java5-xxx a sun-java6-xxx.