Portál AbcLinuxu, 6. května 2025 17:59
1) Kde menu je JINE (nikoliv automaticky spatne), take mi trvalo, nez jsem si na nej zvykl, ale ted na nej nedam dopustit. Je to ale otazka cviku a lze samozrejme zapnout i puvodni menu.
2) .. Půl hodiny jsem nastavoval síť a pak jsem zjistil, že se tam musí dát něco jako konec a ono se to uloží aź potom ... .. a to ma jako prubezne ukladat kdyz napisete ip 123 save . save 122 save . save .... to jako v cem je vyhoda ? To jako urychli praci ?
3) ... Nainstallování ovladačů NVidie pro jistotu taky nešlo .... Nainstalovani ovladacu Nvidie je zalezitost asi 1 minuty i s restartem Xek a spociva v nainstalovani 3 balicku z repozitaru. To je teda fakt drina.
4) Nic jinýho jsem ani nedělal a dělat nebudu . ... nikdo vas nenuti. Jenom nevynasejte unahlene rozhodnuti o necem cemu (bez urazky) nerozumite.
Preji hezy den.Nevim, jak si někdo může myslet, že je to KDE menu dobrý ... Absolutně nepraktický ... Sice hezký, ale pro rychlou práci ne ...V článku je sice řeč o GNOME, ale i tak jsem se nad tím zamýšlel obecně: Klasická podoba menu je výhodná "pro rychlou práci" pro ty, kteří již mají své zkušenosti, ale skutečný BFU se v takovém menu ztrácí (pozoruji). Je tedy dilema, zda defaultně nasadit menu pro totální začátečníky, které je pro ně prostě přehlednější - jako to v GNOME, viz screenshot - i když nám zkušeným připadá zbytečně těžkopádné. Jenomže my zkušení si jednak můžeme za 10 sekund přidat na panel menu klasické anebo spouštět aplikace třeba přes Alt+F2 - prostě jak je kdo zvyklý. Člověk, co si prvně nainstaluje linuxovou distribuci, ale i jako poměrně zkušený windowsák nejprve dost tápe - stručný výběr "oblíbených aplikací, posledních dokumentů apod." na první kliknutí a kompletní přehled na druhé - to může být v bloudění klasickým menu dost velká pomoc. Mě to taky otravuje, protože už vím, co si chci spouštět a kde to v menu najdu, ale ověřil jsem si na několika BFU, že pro začátek je tento styl ze SUSE podstatně schůdnější. Proto mě docela mrzí hlasy některých zkušených linuxáků, kteří tomu nemohou přijít na jméno.
Asi chameleona smažu a půjde tam Bubuntu(jednoduší,má větśí komunitu,atp) ...O té větší komunitě bych trochu pochyboval (alespoň v Česku), v nejlepším případě větší amatérskou komunitu, ale pravda je, že Ubuntu je čím dál tím lepší a lepší konkurence i takovým etablovaným distribucím jako Mandriva a SUSE. A jestli se nebudou chtít z vývoje Ubuntu poučit, za chvíli je převálcuje... Instaloval jsem v poslední době všechny tři a zatímco bych stále dal přednost Mandrivě a SUSE pro ty uživatele, kteří se do systému nebudou hrabat (také kvůli pečlivějšímu počeštění), pro "power-users" bych asi zvolil právě Ubuntu (stejně tak jako pro starší HW).
Napr. mono nebo vsechny knihovny na pristup na smartcard nelze odebrat, protoze na nich zavisi pulka yast-* balicku
To byla pravda pouze v 10.1, ve verzi 10.2 to už neplatí.
pomalost yastu - silena, nemam zrovna nejnovejsi stroj (mobile P/900 MHZ)
Naopak, YaST je v 10.2 výrazně rychlejší než býval; vaším problémem bude spíš nedostatek paměti, pak je zpomalení celkem logické, ale není to tím, že by YaST byl pomalý.
Tot moje poznatky po cca mesici s openSuse 10.2. Docela lituju tech penez co jsem za to dal....
Hm… To je řeč o těch asi 100-150 Kč za vylisované DVD?
A vsichni jsou blazni, jenom ja jsem letadlo. LOLNaopak, YaST je v 10.2 výrazně rychlejší než býval; vaším problémem bude spíš nedostatek paměti, pak je zpomalení celkem logické, ale není to tím, že by YaST byl pomalý.
Naopak, YaST je v 10.2 výrazně rychlejší než býval; vaším problémem bude spíš nedostatek paměti, pak je zpomalení celkem logické, ale není to tím, že by YaST byl pomalý.Možná není pomalý YaST jako takový, ale pomalé je z uživatelského hlediska to, co YaST dělá, hlavně než se spustí a načte aktuální konfigurace - tipuji, že to bude tím, že zatímco jiné systémy pracují s rozdíly databází, YaST snad pokaždé stahuje kompletní seznamy software ze zdrojů znova (?). Ve výsledku je to pro uživatele hlavně ve srovnání s konkurenčními správci instalace extrémně pomalé, spustíte YaST kvůli instalaci nějakého programu a on skoro 5 minut natahuje a načítá, než se vůbec spustí a dá vám možnost vybrat (člověk už skoro zapomene, co to vlastně chtěl). Argument nedostatkem paměti neobstojí právě ve srovnání s ostatními systémy, které se na tomtéž stroji chovají velmi svižně (vůbec nepočítám rychlost samotného stahování a instalace programů, ta může být jistě srovnatelná). Mám silný dojem, že je to prostě koncepcí YaSTu. A protože je nastaven jako výchozí, nedělá SUSE dobrou reklamu.
YaST snad pokaždé stahuje kompletní seznamy software ze zdrojů znova (?).
U instalačních repository to nedělá, pokud jim omylem nezapnete refresh (v české verzi obnovit), k čemuž není důvod. U update repository se IIRC stahují pouze změněné soubory.
U instalačních repository to nedělá, pokud jim omylem nezapnete refresh (v české verzi obnovit), k čemuž není důvod. U update repository se IIRC stahují pouze změněné soubory.Nejsem si vědom, že bych cokoliv v tomto smyslu zapínal, což nevylučuje, že to bylo "omylem" - v tom případě je to ale taky špatně, neboť pokud nějaká funkce tak znatelně zpomaluje práci systému, mělo by to být někde u vypínání/zapínání řečeno. Zkusím to najít... tedy až mě YaST vůbec k sobě pustí. Před chvílí jsem YaST spustil a právě se "Inicializuje..." (stahuje z repozitářů) už osmou minutu a odhaduji, že to bude ještě nějakou dobu trvat. To vše ještě předtím, než se ukáže jakýkoliv výběr. To pro ilustraci.
Před chvílí jsem YaST spustil a právě se "Inicializuje..." (stahuje z repozitářů) už osmou minutu a odhaduji, že to bude ještě nějakou dobu trvat. To vše ještě předtím, než se ukáže jakýkoliv výběr. To pro ilustraci.18 minut. Čekat tak dlouho na prosté spuštění nějakého nástroje bez možnosti interakce je dost fatální pro pocit uživatele a mezi distribucemi ojedinělé. I poté, co jsem u všech zdrojů povypínal "Obnovit", trvá 5 a půl minuty od kliknutí na "Správce programů" a zadání hesla, než můžu začít v YaSTu vůbec začít hledat programy, které bych si chtěl nainstalovat.
Tak jsem si to zkusil změřit. V normálním nastavení (refresh pouze u update repository) 56 sekund, když jsem vypnul refresh i u něj, naměřil jsem 20 sekund. Ten druhý výsledek je samozřejmě ovlivněn i tím, že se podruhé většina lokálních souborů četla z cache a ne z disku. Tak či onak nemohu vaši zkušenost považovat za univerzální.Dobrá, kde je tedy problém? Jak to musí člověk, který si právě nainstaloval SUSE jako já způsobem popsaným v článku, nastavit, aby byl YaST (při spouštění!) aspoň srovnatelně rychlý jako správci software v ostatních distribucích? Minuta až dvě jsou tolerovatelné (pakliže se viditelně něco děje), samo stahování a instalace vedlejší - tam je třeba počítat také s parametry připojení a výkonem počítače. Frustrující je a špatnou reklamu dělá to spouštění. Představte si, že někomu SUSE předvádím a řeknu: A takhle si pohodlně nainstaluješ programy: Kliknu na spráce software a 5 minut čumíme na "Inicializuje se..." Je problém třeba v nastavených zdrojích a pomalým přístupem k nim? Jak tohle vyřeší člověk, co si právě podle návodu nainstaloval openSUSE? PS. Protože jinak má SUSE moje sympatie (viz článek), skutečně mi nejde o to, nějak tento systém napadat, právě naopak, bych rád našel řešení pro zatím jedinou věc, která mi vadí.
Bez bližších informací těžko hádat, ale kdybych měl střílet naslepo, tipoval bych paměť. Současné verze (řekl bych, že od 10.1) modulů sw_single
i online_update
jsou paměťově dost nenažrané, takže na počítači, který nemá dost paměti, to může vést ke swapování, a tedy i drastickému zpomalení. Např. na jednom serveru s relativně rychlou konektivitou a 512 MB fyzické paměti, na kterém běží pár paměťově náročnějších služeb (zejména squid a amavis+AVG), je modul online_update
neskutečně pomalý; důvodem je, že dokáže spotřebovat něco kolem 300 MB. Prostě ta distribuce je podle všeho stavěná na současný hardware a 512 MB je pro ni dolní hranice použitelnosti*.
* - to ale neznamená, že by nedokázala vystačit i s podstatně menším přídělem, třeba nedávné experimenty ([1], [2]) při malé velikosti fyzické paměti jsem prováděl právě na OpenSuSE 10.2
online_update
na svém desktopu a vytáhl to až na 568 MB, a to při pouhém zobrazení dostupných aktualizací (žádné nové nebyly). Nechápu… Začínám mít temné podezření, jestli k tomu staticky nepřilinkovali celé Mono (na mono-*
balíčcích to nezávisí).
top
, už hodnoty VIRT
pro firefox a y2base
dávají dohromady víc, než kolik je podle něj spotřebované paměti celkem.
důvodem je, že dokáže spotřebovat něco kolem 300 MB. Prostě ta distribuce je podle všeho stavěná na současný hardware a 512 MB je pro ni dolní hranice použitelnostiZkoušeno bylo na 384M RAM, takže to tím být může. Nicméně zbytek distribuce kromě "Správce software" opravdu běhá i na předpotopním HW velice slušně (včetně přehrávání filmů z DVD), a jak jsem popsal v článku, dokonce i 3D desktop běží. O to víc prostě kontrastuje normálně použitelný systém na starším HW s jednou jedinou jeho částí, kterou je YaST. Pokud 512M RAM byla dolní hranice použitelnosti, je to bohužel pro SUSE minus oproti ostatním linuxovým systémům, protože tam je minimálně o polovinu i více menší. V takovém případě bych si např. rozmýšlel používat tuto distribuci na notebooku (dodnes často 128-512M RAM) - naštěstí vím z praxe, že to tak není. Člověk ostatně dokáže pochopit určitá zpomalení na paměť náročných aplikací třetích stran i některých např. grafických či jinak náročných funkcí, ale u systému samotného, vlastně jedné jeho části nota bene sloužící ke správě, to docela vrtá hlavou. Pokud bych nabízel někomu Linux jako skutečnou alternativu k Windows Vista, dělal bych to také z toho důvodu, že lze nainstalovat a provozovat současný zbrusu nový systém na HW, na kterém běží slušně 6 let starý Windows XP - tohle je poměrně silný argument. Pokud se dolní hranice použitelnosti nějaké linuxové distribuce zvýší na dolní hranici použitelnosti Windows Vista, tento argument padá. Jistě není jediný, ale nutnost zakoupit nový HW kvůli up-to-date systému se zatím uživatelům Linux připomínala jen velmi decentně.
Proboha člověče, pokud máte nastavené obnovování repozitářů a k tomu pomalé připojení, nebo to taháte z momentálně přetížených serverů, tak se nedivte, že to běží pomalu a hlavně nemelte kraviny o tom, že je YaST pomalý. YaST se v tuhle chvíli nudí a nedělá nic - čeká až se stáhnou informace o balíčcích. Kdyby to dělal jakýkoliv jiný systém, bude to trvat stejně dlouho. Prostě to jen čeká, až se stáhnou nějaká data. Trochu soudnosti...Jakýkoliv jiný systém zvládne totéž (totiž být od startu připraven k interakci) nesrovnatelně rychleji. Je možné, že to souvisí s tím, že pro YaST je k rozumné rychlosti 512 MB RAM dolní hranice použitelnosti, jak se píše výše (kteroužto debatu jste si evidentně neráčil před svými výlevy ani přečíst). Na méně RAM je tedy YaST asi ten nejpomalejší správce balíčků, jaký jsem kdy měl tu čest poznat. Jak byste nazval vy, když od spuštění uživatelem po připravenost k zadání úkolu trvá nějakému nástroji kolem 5 minut? Jestliže se v tu chvíli nudí a nedělá nic, totéž platí i o uživateli. Podotýkám, že obnovování všech repozitářů je vypnuto, a jak píšu výše, toto hlemýždí tempo YaSTu je asi jediné místo, kde člověk v celé distribuci narazí, protože zbytek výborně funguje na tomtéž HW (včetně přehrávání videa, i přes Internet, na PII 400 MHz). Z této perspektivy je prostě pomalost YaSTu nikoliv kravina, ale evidentní a zcela objektivní skutečnost, jak ve srovnání s balíčkovacími systémy jiných distribucí, tak ve srovnání s jinými nástroji vlastního SUSE.
No v tom pripade hodne lituju uzivatele 10.1. Jak uz jsem psal, na 3-ti pokus jsem byl schopen najint nejmensi instalovatelnou sadu balicku (ale mono i smartcard v tom bohuzel byt muselo, abych nemusel pul hodiny potvrzovat ze jsem si vedom ze ty balicky jsou potreba pro x, x+1 .....)Napr. mono nebo vsechny knihovny na pristup na smartcard nelze odebrat, protoze na nich zavisi pulka yast-* balickuTo byla pravda pouze v 10.1, ve verzi 10.2 to už neplatí.
Zase, velmi lituju uzivatele 10.1. No, asi to bude pameti, protoze pri prestupu z 10.0 na 10.2 jsem upgradoval a pridal k 256MB dalsich 128 MB. Bohuzel ani to asi nestacilo. Zipper si bere na 10 minut vic pameti nez firefoxpomalost yastu - silena, nemam zrovna nejnovejsi stroj (mobile P/900 MHZ)Naopak, YaST je v 10.2 výrazně rychlejší než býval; vaším problémem bude spíš nedostatek paměti, pak je zpomalení celkem logické, ale není to tím, že by YaST byl pomalý.
Rec je o tech 59.90$ + 9$ za dopravu. Velmi tech penez lituju, ale je to moje chyba, mel jsem kupovat na ebay, ne od novellu.Tot moje poznatky po cca mesici s openSuse 10.2. Docela lituju tech penez co jsem za to dal....Hm… To je řeč o těch asi 100-150 Kč za vylisované DVD?
Asi bych se vyhnul pouzivani terminu operacni system a pouzil bych presnejsi: distribuce.Já bych naopak řekl, že je na čase pomalu přestat tuto speciální charakteristiku linuxových operačních systémů, která je de facto odborným žargonem, v obecně zaměřených kontextech používat (podívejte se na stránky jednotlivých "distribucí": "Ubuntu is a complete Linux-based operating system"). OpenSUSE je především operační systém, a až další charakteristika je, že je to linuxová distribuce. Mimo linuxovou komunitu je nadto pojem "distribuce" v podstatě nesrozumitelný a vyvolává jiné konotace. "Operační systém založený na Linuxu" či "linuxový operační systém" je podle mě přijatelnější formulace, která je zároveň dostatečně korektní. "Distribuce Linuxu" mj. působí dojmem, že existuje nějaký konkrétní operační systém "Linux" a distribuce vznikají jeho pouhou úpravou, což je pravda jen v jednom významu pojmu "operační systém", a to v tom odbornějším, jak se v obecném kontextu dnes nechápe. Je to spíše naopak: pojem Linux zahrnuje vlastně všechny konkrétní distribuce, tj. operační systémy na linuxové bázi, kterou pak mají více či méně společnou a díky níž jsou vzájemně kompatibilní, přičemž znovu, tato kompatibilita se ani tak netýká koncových uživatelů, ale odborníků, kteří systémy dávají dohromady, případně administrátorů, kteří se mohou inspirovat řešením problému v jiné distribuci (ale musí ho pak většinou přizpůsobit). Koncový (power) uživatel ale vnímá dvě různé distribuce jako dva různé operační systémy, z nichž každý má svá specifická řešení a návody, specifickou správu instalace programů a různou míru uživatelské přívětivosti. Což je také zájmem firem i jednotlivců či amatérských týmů, které se produkcí distribucí zabývají: ty určitě chtějí "prodávat" a dělat reklamu pro svůj plnohodnotný operační systém, nikoliv "Linux" obecně (mnou stále omílaný příklad: automobilka taky neprodává "Nafťák", ale auto své značky, jehož typ motoru je až druhořadá odbornější charakteristika). Zkuste si taky odpovědět na otázku typu "nainstaloval jsem si Linux..." - jako první se zeptáte na distribuci, tj. konkrétní operační systém, abyste mohl pokračovat. To neznamená, že by bylo třeba vyhýbat se pojmu Linux - ale používat ho důsledně buď jako přívlastek nebo ve spojení s konkrétním názvem distribuce, anebo opravdu jako souhrnný pojem pro všechny linuxové distribuce. V tomhle smyslu je "linuxová distribuce" pouze odborná obecná charakteristika rovnající se významem pojmu "operační systém na bázi Linuxu" či "operační systém linuxového typu". Krátce a jednoduše: používáním pojmu "operační systém" pro Gentoo Linux, openSUSE, Ubuntu atd. se můžeme zbavit navenek prezentovaného dojmu, že "Linux" je konkrétní operační systém, a že tedy liveCD "Lhotix" Franty z Horní Dolní je totéž co SUSE Linux Enterprise Desktop (totiž "Linux"), pouze jinak přebarvený a s jiným názvem, a nikoliv dva rozdílné operační systémy s vlastními týmy odpovědných, které mají společnou toliko stejnou bázi.
Čerpání výhod z patentů jako nastroje pro zválcování konkurence je ve světě svobodného software neakceptovatelné. Neporušit zákony ještě neznamená jednat čestně. Jsou i mnohem vyšší hodnoty, které logicky vyplývají ze stávajících smluv. Jestliže se někomu podaří takovéto smlouvy obelstít pro svou chvilkovou převahu nad konkurencí i za cenu toho, že uzavře smlouvu se skutečným nepřítelem nelze toto jednání přehlížet a tvářit se, že se nic nestalo!
Každý může udělat chybu. Tu je však pak třeba napravit. Vůbec ale nevidím snahu ze strany Novellu očistit distribuci OpenSUSE. Ze strany firmy Novell podepsání této smlouvy je výrazem hluboké ignorace vzájemné pomoci, jaké tato firma čerpá ze společenství Svobodného Software. Stačí jen vycouvat z patentové dohody z Microsoftem a potvrzení svých závazků jako beneficienta Svobodného Software. Pak zase bude vše OK a SUSE se bude moci opět upřímně dívat ostatním uživatelům Svobodného Software do očí.Kdo má rád SUSE podpořte jeho očištění. Dejte najevo, že Vám to není jedno jakou filozofii si teď Novell zvolil. Ať se zase říká o Novellu že je schopný a ne všeho schopný.
uprmi
, yast
, yum
, smart
a apt*
a yast
z toho vyšel nejpomalejší. Na urpmi
mi vadil pouze šílená velikost těch hdlist.cz, které musí stahovat a trochu taky to, že nemá aptí syntaxi Jakou mate zkušenost se smartem na openSUSE 10.2?Bohužel není ve výchozí instalaci - je třeba ho vědomě doinstalovat a konkrétně v testované verzi se nainstaluje s anglickým GUI. Což není právě něco, co by nováčka pozvalo k používání Smartu namísto integrovaného YaST.
Upgrading packages (7):
k3b-1.0-100.pm.0@i586 kdepim3-kpilot-3.5.6-24.7@i586 xorg-x11-Xvnc-7.1-33.1@i586 kde3-windeco-suse2-0.4.1rc1-2.guru.suse102@i686 libzypp-2.14.2-1.1@i586 kdeaddons3-konqueror-3.5.5-5.1@i586 release-notes-10.2.19-1.1@noarch
Downgrading packages (5):
kdebase3-3.5.5-102.1@i586 kdelibs3-3.5.5-45.2@i586 ktorrent-2.1.1-1.guru.suse102@i686 x11-video-nvidia-1.0.8776-1@i586 xine-lib-1.1.2-40.1@i586
Removing packages (1):
nvidia-gfx-kmp-default-1.0.9631_2.6.18.2_34-0.1@i586
Committing transaction...error: file /opt/kde3/share/config.kcfg/kpilot.kcfg from install of kdepim3-kpilot-3.5.6-24.7 conflicts with file from package kdepim3-3.5.5-36
error: file /opt/kde3/share/services/memofile-conduit.desktop from install of kdepim3-kpilot-3.5.6-24.7 conflicts with file from package kdepim3-3.5.5-36
error: file /usr/lib/libxine.so.1 from install of xine-lib-1.1.2-40.1 conflicts with file from package libxine1-1.1.4-0.pm.0
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.