Ale oni to opravdu zavideji (ti kteri vedi o cem je rec)....
Cela rada je jich linych cokoliv menit, dalsi jsou s Windows svazani kvuli nekterym specializovanym aplikacim, ale poradny system spravy baliku se softwarem by cela rada z nich uvitala - a opravdu mne nekteri rikaji: "to ti zavidim, chtel bych to taky mit ve Windows a ne ten neskutecny bordel"....
a neni tohle treba zpusobeno nasilnym bundlovanim winu k HW ?
prece vime, jak ochotne vsichni prechazeji na Visty (standartni politika prodejcu je: no, mate u toho visty, ale ovsem ze vam k tomu dame i xpcka a ty budete moct pouzivat nez to zacne fungovat).
a na nasi politicke scene se kazde 4 roky opakuje fraska "voli voli voly", ktera bezpecne ukazuje, ze tupy dav po reklamni kampani opet zvoli dodavatele, ktery nikdy nedodal to co slibil (to ze stran mame vice a microsoft je jen jeden je u ... monopol jiz delsi dobu drzi jeden a ten samy konglomerat, a kdo jim zrovna pricmrndava je celkem jedno).
To je fakt. Netuším, k čemu jsou Visty dobrý, krom toho, že maj super SP1 1GB. A to bundlování, dobrý značky mají na výběr i linux a špatný holt nabízí i holej stroj.
Podle státních institucí je ovšem rozhodující kritérium, jestli je v systému Freecell.
o automaticke rozpoznani hw a zavedeni driveru se jiz dlouho stara kombinace udev a hotplug, ale musi mit driver k dispozici, toto reseni Dellu si mi libi, protoze resi situaci, kdyz hw je rozpoznan, ale neni co zavest.
nevim jak jinde ale v Mandrive pomuze jeste i s prekompilaci toho ovladace.
typicka situace: update jadra na vyssi verzi. pri bootu se najednou objevi radky ze neni k dispozici driver nvidia a ze to dkms zkompiluje.
je to moc dobra vec ve chvili kdy se smirime s third-party kernel drivers.
porad vsak rikam: nejjednodussi je kupovat jen podporovany hw.
jedine tak se situace zlepsi. nekdy to samozrejme nejde, ale jsou pripady kdy naopak probleny s nekompatibilitou vznikaji jen z pouhe "nahody" ci neinformovanosti.
Pravidelne updatuju Fedoru pres yum. Cloveka moc nepotesi, kdyz si po tydnu vsimne ze ma vlastne novej kernel a ze by si mel prekompilovat nvidia drivery. Obvykle je to ve chvili, kdy jste si zrovna chteli zahrat Enemy Territory :).
Zni to jak z reklamy, ale od doby co mam nvidia jako dkms modul, nemusim na to ani sahnout.
Naopak - prebalil jsem si dalsi moduly (gspca, madwifi, cisco vpnclient) abych se uz s nima nemusel zabejvat.
Mohlo by to ist este dalej a z oficialneho jadra by sa mohli vypustit vsetky specializovane ovladace. Trochu mi prekaza ked si musim instalovat jadro (pripadne naviac kompilovat) v ktorom je podpora pre XY grafickych kariet, wifi, tunery,...
Zrovna WIFI ovladače bych nechal v jádru, pokud si nechcete číst následující hlášky:
* pokouším se stáhnout z internetu ovladač na Vaši wifi
* pokouším se připojit k internetu
* připojení k internetu selhalo, chybí wifi ovladač
* stažení wifi ovladače selhalo, nejde internet
To se u nás ve Windows řeší tak, že systém přichází s "cache" velké spousty driverů na distribučním médiu. Tedy u nás pravda není třeba nic kompilovat, protože vývojáři Windows publikují stabilní interface, což v Linuxu prý nejde...
JJ, ta "cache" ve Windows je tak obrovská, že tam kolikrát nejsou ani základní věci, jako řadič disku, aby vůbec systém šel někam nainstalovat a další samozřejmé věci, jako jsou například síťovky. Dokonce ani po instalaci neexistuje způsob, jak všechny ovladače automaticky upgradovat a doinstalovat chybějící a člověk je nucen lovit to manuálně někde po webu. To je opravdu věc ke chlubení :-D
Držme se fakt. Windows XP nabízely v roce 2002 drivery k obrovské spoustě HW. Nemá moc smysl konstatovat, že neobsahovaly drivery pro HW vyrobený po tomto datu - těžko zahrnovat drivery pro něco, co ještě neexistuje. Samozřejmě CD Windows XP SP2 má drivery navíc.
Samozřejmě po instalaci XP se drivery tahaly automaticky z inetu (Windows Update). Bohužel se někteří výrobci rozhodli své certifikované drivery na Windows Update nedávat. Ovšem ve Vistě je tam dát musí (je to podmínkou certifikace). Pochopitelně nelze nijak zaručit, že ke každému HW eixstuje driver pro Windows, natož že je každý výrobce seriózní a drivery certifikuje. Nicméně od toho je tady ta certifikace. Certified for Windows Vista? Bude na Vistě fungovat, a bude fajn. Works with Windows Vista? Bude na Vistě fungovat.
heh, tuhel jsem delal vlastni instalacni cd win xp, kvuli ovladacum radice disku - nezvladli totiz ani prechorustat floppy s driverem, natoz aby ten driver byl defaultne na cd
Asi šlo o HW uvedený po uvedení XP. Lze například použít CD XP SP2 (tuto instalačku byste dostal k novému poči), nebo driver připálit k instalaci XP na nové CD.
Zrovna nedávno jsem měl krásný příklad toho jak spolehlivě to funguje ... koupil jsem USB->Serial ....
připojim v linuxu: ejhle ono to začalo fungovat.
Připojim u windows: Nový hardware->chybi ovladace->pres net si to samo nic nenaslo->kouknu do Spravce zarizeni na PID a VID a podle toho hledam na netu jakykoliv ovladac, asi na po 30 minutach nachazim vyrobek i s ovladacema uff... sice jiny vyrobce ale co zarizeni se hlasi stejne a jiny nazev v ovladacich panelech me trapit nebude.
PS: ano cd s ovladaci jsem nemel pri sobe, moje chyba. Ale takove rozchozeni scanneru z roku 1998 ve windows je taky lahoda, asi takova ze uz jen pri vidine krasne straveneho odpoledne clovek bali penezenku a hura nakupovat neco novejsiho ;)
K tomu následující: 1) k výrobku bylo CD s ovladači, a pokud ho nemáte, je to vaše chyba, 2) Vista všechny certifikované drivery stahuje z inetu, 3) Pokud drivery hledáte, tak nejlépe na support stránkách výrobce zařízení, a ne pomocí Google.
Souhlasím, že rozchození 9 let starého scanneru může být problém. Na Linuxu je ovšem problém rozchodit v podstatě jakýkoliv scanner (včetně 9 let starých). A když ho člověk rozchodí, setkává se s problémy typu "ztuhne to při nastavení rozlišení X", "při nastavení rozlišení Y je výsledek neskutečně zubatý", "barvy vypadají příšerně", "ignoruje to endorser" apod. Navíc pro Linux člověk nesežene DTP SW pro práci s výsledkem (Gimp je pro DTP mimo), SW pro slušné skenování (třeba skenování 120 stran za minutu), slušný imaging, OCR/ICR/Automated Forms Processing, propojení na podnikové systémy...
Samozřejmě chápu, že VÁM stačí rozchodit scanner, který jste našel na dně skříně, naskenovat jeden obrázek (za minutu) za pomoci command line utility, a jste happy. Ale to se bavíme o trochu jiných kategoriích.
So support stránkami výrobcov máme mnohí svoje skúsenosti.
Že by bol problém rozchodiť scanner pod Linuxom ..nevšimol som si. Tuhnutie nenastalo NIKDY, ani pri vysokej záťaži počítača a skenovaní. Pod Windows mi to párkrát zatuhlo, to je pravda.
Softvér je problémom dovtedy, kým výrobcovia ignorujú platformu. To sa pomaly, veľmi pomaly, mení k lepšiemu.
Pravda, drivery pro Linux mnohdy nemá smysl hledat na stránkách výrobce. Drivery pro Windows má naopak smysl hledat POUZE na stránkách výrobce.
SW je problém třeba i proto, že Linux nemá color management. Dále s těmi věčnými klacky pod nohy ne-GPL vývojářům těžko můžete očekávat, že někdo pro to 1% desktopů (vlastněných lidmi, kteří neradi za cokoliv platí) bude cokoliv vyvíjet. Například slušné OCR/ICR.
Hele, sokoliku, co jsem udelal spatne, kdyz jsem si domu nedavno prinesl scaner, pripojil jej do USB, parkrat kliknul a pak spustil aplikaci xsane a zacal scanovat ?
O existenci commandline utility jsem se dozvedel az pote, co jsem se zacal zajimat o to, coze to je vlastne to SANE :-))
Netykáme si. Měl jste asi štěstí. Zkuste si například rozlišení odlišná od optického rozlišení scanneru, se slušnou pravděpodobností bude výsledek silně zubatý. Jak děláte shodu barev (kalibrace scanneru)? Ale i když jí uděláte, tak je vám na nic, protože zbytek systému (zobrazování a tisk) jí nepodporuje, na rozdíl od situace na Windows a Macu. Jak řešíte podavač, endorser, čtečku čárových kódu, adaptér na diáky? Jak rychle váš scanner skenuje pod Windows a jak rychle pod Linuxem? Skenuje pod Linuxem v HDR, nebo jen 24-bit (nejlépe s ořezáním, nikoliv kompresí dynamiky)? Jak říkám, linuxáci jsou v principu velmi nenároční :)
Mimochodem já mám doma Astra UMAX Astra 4700, USB. Samozřejmě to není nic skvělého, ale barevné podání má na svou cenu slušné (v roce 2003 ho německý PC Direct ohodnotil jako Very Good), a má certifikaci Designed for Windows XP. SANE ho nepodporuje.
S tím tykáním to je taky vynález. Kdysi si na BBSkách a pak i na netu tykali všichni a nikomu to nevadilo.
Kalibrace barev je kapitola sama pro sebe. V domácích podmínkách víceméně na nic. Co inkoustu vždycky vyteklo, než tisk odpovídal originálu, kalibrace-nekalibrace. Pokud nepoužíváte profi zařízení jako osvitovky a ofsetový tisk, tak se s tím stejně musíte s prominutím sr*t ručně. A kdo dělá profi grafiku, tak stejně většinou jede na macu.
Ona vám 24 bitová barevná hloubka nestačí nebo co?
Jak je na něčem napsáno designed for anythong, dávám ruce pryč. Připomíná mi to "best viewed in IE 6 in 1024x768".
Říkám profi grafiku, ne nějaký domácí kutil s warezem :) Co znám grafiky i ve velkých tiskárnách, jedou na Macu, nebo po něm touží ;) Stejně jako profi 3D se nedělá v 3D Studiu, ale v Maye na Unixech (Pixar apod.)
vono s tou mayou na linuxu/unixu je to kapku osemetne kdys pominu to ze pixar ma k dispozici zdrojove kody k maye a v pripade ze mu nejaka funkce nesedi implmentuje si jí pro vnitrni pouziti sam samozrejme na to ma take rozpocet .. dalsi vec je ze maja se chova v kazdem prostredi trochu jinak predevsim jeji gl zobrazeni v lin/unix a win je uplne jine jinak maya byl puvodne pro win/mac myslim teprve lucas arts donutil alias(dnes mayu vlastni autodesk uvidime co z toho bude :D) vyvijet mayu pro linux a unix ... ale jinak priznavam chci mac hlavne kvuli jeho podani barev a pod .. win me v praci pekne stvou ale adobe veci v linuxu moc nejdou
Kdysi na BBC byla trochu jiná doba. Benzín byl levnější, lidi se měli rádi. Peníze jsme neměli, ale byli jsme šťastnější. Co nám všechny ty vymoženosti a peníze přinesly? Jen starosti a neklid duše ;)
Kalibrace barev je předpokladem pro úspěšný proces reprodukce. Linux je absencí podpory ICM diskvalifikovaný. Na DTP se statisticky nejčastěji používají Windows, nakonec jako ve většině oblastí.
24-bitová barva opravdu nestačí. I levné skenery mají běžně 12-bitové převodníky, natahuje se do nich tabulka s gamma korekcí, a pak vracejí obraz se správně komprimovanou hloubkou na 8 bitů na kanál. Vyjma toho umožňuje řada skenerů až 48-bit hloubku; samozřejmě takový obraz musíte být schopen vyžádat, přijmout a uložit. Ovšem na Linuxu vám stejně k ničemu nebude, protože tam prakticky neexistují aplikace s podporou HDR (více než 24 bitů na pixel). Na Vistě naopak lze používat určení barev i ve floatu.
Designed fox X znamená, že to v X funguje. Když si koupíte náhodně vybraný HW, a výrobce k němu dělá mizerné drivery, máte prostě smůlu. Certifikace říká, že zařízení má zaručené parametry (třeba u zvukovky odstup signál/šum), zaručené features (třeba u zvukovky barevně odlišené konektory), driver existuje, má dané features a je kvalitní.
Slušně diskutovat se dá i bez vykání. Naopak i vykající člověk může urazit ;)
"Kalibrace barev je předpokladem pro úspěšný proces reprodukce." jistě, pokud pracujete na profi zařízeních. Domácí uživatel a Astra scannerem přes usb a inkoustovou tiskárnou se stejně ruční korekci nevyhne, nebo jsou rozdíly tak nepatrné, že to nemá smysl.
"Linux je absencí podpory ICM diskvalifikovaný." to ano, nicméně až bude zapotřebí, může se kalibrace barev dodělat. Zatím není důvod, protože stejně nejsou aplikace pro DTP.
"Na DTP se statisticky nejčastěji používají Windows" to je jako s webem, jsou "webdesignéři", těch je statisticky více a používají různé wysiwyg editory a podobné hrůzy, no a pak jsou webdesignéři, kteří jsou schopni vytvořit kvalitní web s gimpem a třeba vim-em. Stejně tak je to v profi grafice.
K barevné hloubce... to je zase jen o uživateli. Pro domácí potřebu je 24bit dostačující. Pro komerční profi sféru jsou jiné systémy.
K tomu designed for X... já se řídím jinými parametry při výběru hardware, než nálepkou na krabici :) Ale nikomu to samozřejmě nevnucuju ;)
Samozřejmě color management má smysl i doma. Zkuste si na Linuxu vytisknout z pár aplikací barevnou fotku na tiskárně. Třeba to zkuste z OpenOffice Writeru, KWordu, vyberte si pár dalších, vyberte si pár tiskáren. Fotografie budou vypadat, jako když mají lid na nich nějakou prudce nakažlivou a nejspíš smrtelnou chorobu ;)
Color management není věc, která se dá jednoduše dodělat. Musí se s ním počítat už při návrhu grafického subsystému. Jenže Linux nemá ani grafický subsystém (X11 a CUPS není subsystém).
Samozřejmě pro domácí potřebu 24 bitů dostačuje. Proč mít ale doma odlišnou platformu, než kdekoliv jinde? Proč vůbec mít více platforem, pokud nehovoříme o nějakých opravdu vysoce speciálních požadavcích?
Parametry jsou při výběru HW často o ničem. K čemu mi je, když mám WiFi PC-card se skvělými parametry, která mi ale nejede pod Linuxem, protože toho driver víc neumí, než umí (ad-hoc mode, PWA-PSK)? A k čemu mi je zvuková karta s Dolby Digital Live (jediný rozumný způsob, jak z počítače dostat prostorový zvuk v digitální kvalitě), když jí vyrobila neznámá malá společnost, a driver víc neběhá než běhá? Certifikace mají VELMI dobrý důvod. Nakonec když Novell řekne "SCSI řadič ABC je kompatibilní se SuSE Linux Enterprise Serverem", je to jiná situace, než když si řadič vyberete na slepo či podle parametrů. Lehko se vám totiž může stát, že důležité parametry nebyly uvedeny, produkt vykazuje neočekávané vlastnosti (například můj Linux vždy na cca 15 sekund vytuhnul při startování Atheros WiFi), parametry jsou vázané na nějaký úchylný SW atp. Výrobce takový šmejd může uvést na trh, a běžně se tak děje. Certifikace pak říká, že výrobek splňuje nějaké dané požadavky. Je škoda, že tuhle problematiku řada lidí ignoruje, a pak se hrozně diví, že koupené produkty nefungují jak mají.
"Samozřejmě color management má smysl i doma" no to jsem viděl při tisku ve windows :D
"Jenže Linux nemá ani grafický subsystém" já vím, já si vlastně ty okýnka kreslím pastelkama na monitor. BTW co má color management pro skenování nebo tisk společného s "grafickým subsytémem"?
"Samozřejmě pro domácí potřebu 24 bitů dostačuje. Proč mít ale doma odlišnou platformu, než kdekoliv jinde?" protože to stačí.
"Proč vůbec mít více platforem, pokud nehovoříme o nějakých opravdu vysoce speciálních požadavcích?" máme jednu dominantní a je vidět, jaký to má vysledek.
"Parametry jsou při výběru HW často o ničem.... atd." ehm BSOD jsem si s "certifikovanými" "blabla for windows" výrobky a ovladači užil, že mi to stačí na dva životy.
Ano, color management je při tisku z Windows velmi dobře vidět. Výtisky z Linuxu jsou pravidelně barevně daleko horší.
Zvát X11 grafickým subsystémem je poněkud nadsazené. Zastaralá technologie, mizerně dokumentovaná (extensions, bug to bug compatibility), podporuje pouze obrazovku... GDI je proti tomu technologický orgasmus. Samozřejmě byste ale musel znát alespoň architekrutu X11 a GDI. Několikrát jsem tu o tom, najděte si to. Color management má s grafickým susbytémem společné to, že je jeho součástí.
Ano, doma vám 24 bitů stačí. V práci ne. Co s tím? Mít doma aplikace domácí platformu a domácí SW, a v práci pracovní platformu a pracovní SW? Jednu platformu pro hry, další pro kancelářskou práci, další pro DTP, a ještě jinou pro řízení technologických procesů? Daleko efektivnější je mít jednu platformu, která pokryje velkou většinu praktických potřeb.
Dominantní platforma znamená, že na jakémkoliv stroji spustíte obrovskou hromadu SW. Když napíšete SW pro dominantní platformu, máte stovky milionů potenciálních zákazníků. Když napíšete SW pro platformu, kterou používá 1% uživatelů, máte daleko horší pozici. Obecně jedna platforma má řadu technických výhod.
Já si užil BSOD s necertifikovaným HW i s certifikovaným. A protože jsem dost zkušený, velmi dobře vím, jak velký rozdíl to je. Chápu, že to nemůže vidět každý. Dál šťastně kupujte HW podle typu čipsetu, a pak se divte, že je nekvalitní, půlka věcí neběhá, drivery jsou mizerné atd.
Končím diskusi, tohle nemá smysl. Vy jste přesvědčený o své pravdě, já zase vím, co jsem viděl a zažil za těch 16 let, co s PC pracuju jako profesionál. Podotýkám, že nadpoloviční většinu z toho času jsem strávil s MS based produkty. Ne proto, že bych chtěl, ale protože jsem musel. Takže si troufám tvrdit, že nějaké ty zkušenosti mám.
Netvrdím, že Windows jsou špatné a Linux je super. Nejsem žádný Linux fanatik. Jenom se musím pousmát nad výlevy MS fands, kteří tvrdí opak. Výroky typu "GDI je proti tomu technologický orgasmus" mě opravdu dokážou rozesmát. Poukazuji na nedostatky, toť vše.
Jediná platforma pro všechno přináší to nebezpečí, kterému celý svět začíná čelit. A to, že se stává závislým na jednom dodavateli. To, ať už chcete, nebo ne, není v pořádku a nevěstí nic dobrého.
Obecně lze říct, že jsem si prožil dost trápení jak s Windows, tak s *nixy. Ale u unixových systémů je prostě řešení problémů díky jeho otevřenosti daleko znažší, než u molochálních Windows. Zažil jsem několikrát zavádění MS serverů do podniků. Po třech měsících konfigurací certifikovanými administrátory stále něco nefungovalo, nebo fungovalo jinak.
Pokud to že X Windows podporuje barvy bereš jako color management, pak se dá polemizovat co bylo dříve (to by potom chtělo přesné datum uvedení obou věcí na trh :D )
Ale máš pravdu že jsem nějak ignoroval fakt že si se o linuxu nezmínil. A omlouvám se za rušení toku myšlenek :)
Již v příspěvku předtím jsem upozorňoval na letopočty ... ale budiž:
Microsoft uvedl první Windows (odtud i název - okna) na trh v roce 1985
http://cs.wikipedia.org/wiki/Microsoft_Windows
Takže MS Windows už existovaly, teď už můžeme jenom slovíčkařit o termínech ;)
Pocitam zivot operacniho systemu MS Windows od NT nikoli od nadstavby MS-DOSu. Ale budiz. Opravuji tvrzeni na .... "X window system mel CMS drive nez existovaly WinNT"
Nicmene, ze nazev okna vznikl na zaklade MS Windows je nesmysl. Za prve X window system existovali urcite uz pred rokem 1985 a za dalsi Xeroxove meli window system uz nekdy na prelomu 70./80. let.
je to neštastná formulace, ale já jenom citoval ... měnit to na wiki nebudu, tak vzdělanej zase nejsem :)
Zmiňujete určitě Alto od Xeroxu ... no ještě tedka se divím kolik věcí které tehdy s Altem přišli se pořád používá, vždycky mi to připomene, že není důležité něco vymyslet, ale umět dobrý nápad zkopírovat :D .
A neni lepší pořídit si na profi věci profi scanner? To jest takový ten co mají grafici tady o patro výš? Rotační bubnový s vlastním diskem,vestavěným počítačem a ethernetem? Žádné drivery jsem tam nepotřeboval instalovat. Funguje to všem. Neni třeba přestat si hrát na profesionály jak je to dnes zvykem a když chci být profesionál tak se taky profesionálně vybavit? U drahého hw zpravidla nemusíte řešit takový ,,umělý" problém jako ovladače. Buď to máte dodáno jako řešení včetně počítače a nastaveného os a nebo je ten hw natolik inteligentní že mu stačí pouze připojení k síti.
Nechci vám brát iluze, ale ono tak trochu záleží na tom, co chcete dělat. Mít bubnový scanner nemá pro většinu grafiků dnes opodstatnění. Bubnové scannery jsou dnes hromadně nahrazovány vyšší třídou scannerů s plochým ložem. Kvalita scannerů s plochým ložem se totiž za posledních 15 let výrazně zlepšila, a náklady jsou nesrovnatelně nižší. Je to podobný efekt, jako když podnikové aplikace dnes běží na Intel HW, který prostě začal výkonem dostačovat na věci, které byly dříve vyhrazeny HW profi unixů.
Osvitové jednotky se samozřejmě používají, a pro některé aplikace je nelze nahradit. Ale pro jiné aplikace je výhodnější tisk laserem či inkoustem na fólie. Náklady jsou opět řádově nižší. V oblasti pre-pressu se zase prosazuje Computer to plate, kde klasická osvitová jednotka v řetězci úplně chybí.
ad 3) Předveďte prosím své dokonale vypilované dovednosti pro hledání ovladačů a najděte mi nový ovladač pro USB ADSL winmodem Siemens A-100-I, který před pár lety dodával tehdy ještě Český Telecom. Dokonce mi nezáleží ani na cílové operačním systému. Stránky výrobce se k takovému produktu pro jistotu vůbec nehlásí a Google našel jen nadávky nespokojených majitelů.
Co se týče skenerů v Linuxu, já mám skener z roku 1998 UMAX Astra 1220P (připojený přes LPT, pro domácí použití funguje výborně). K němu je dodané jako ovladač cosi založené na rozhraní TWAIN (znalci šli po přečtení tohoto slova zvracet) partially translated do _e_tiny (polovina textů je anglicky a ty české mají místo diakritiky podtržítka). Instalace samozřejmě vyžaduje několik restartů, při výběru skenované plochy si TWAIN software dělá co chce a pokud se výsledný obraz nevejde do RAM, tak si opravdu DLOUHO počkáte. Polovina voleb ovládacího programu není přístupná a skenování přes síť je jen zbožné přání.
Oproti tomu SANE ovladač na Linuxu stačí nainstalovat a bez restartu spustit, vybrat typ zařízení a po krátkém zahřátí skeneru (10 vteřin oproti 30 vteřinám u TWAIN) můžete skenovat. Klidně i přes síť. Výběr skenované plochy funguje, základní ovládací rozhraní má dostupné mnohem víc voleb než TWAIN protějšek a se skenováním obrázků, které se nevejdou do RAM, není nejmenší problém.
Na driver někdo dával link. Zřejmě daný HW nebyl cetifikovaný, proto pro něj Windows Update nemá drivery. Je to pak čistě věc výrobce.
TWAIN drivery jsou pro použití v DTP vcelku v pohodě. Samozřejmě WIA je daleko zajímavější, a pro high volume se typicky používá ISIS. Jestli má UMAX mizerné drivery k LPT "taky-scannerům", je to jistě smutné.
S tím zahříváním jste mě rozesmál. Samozřejmě výrobce ví, proč zvolil právě danou dobu, a ne kratší. Když se doba zahřívání zkrátí, utrpí barevné podání. Chápu ale, že vás to nijak netrápí.
Jediný rozdíl proti ovladačům dodaným na instalačním CD je konfigurační soubor pro PPPoE. Verze pro PPPoA je do posledního bitu stejná jako na instalačním CD.
Jestli to zahřívání chápete jako úplné rozsvícení lampy ve skeneru, tak se mýlíte. Jde jen o kalibraci krajních poloh snímacího ramene.
Co mám dělat s vaším driverem ADSL modemu? Je mi vcelku jedno, jestli pro něj existuje nějaký driver. Když už ho někdo našel, je mi zcela jedno, jestli je to stejná verze, jakou máte na CD. Nevidím, k čemu je dobré o tom mluvit.
Scannery mají teplotní závislosti. Proto se výbojka nechává nějakou dobu nahřát. Kalibrace krajní polohy mechaniky u řady scannerů není nutná (možná u vašeho ano). Každopádně zkrácení doby před prvním skenem se může výrazně projevit na kvalitě výsledku. Opět rozumím tomu, že jako mimořádně nenáročný uživatel potřebujete jen aby scanner skenoval.
No tak, sam jsem napsal že to byla moje chyba že jsem ty ovladače neměl a že jsem nevěděl co je to za typ/výrobce.
Dále já se nebavil o tom, že to je scanner na 120 stran za minutu, na tuhle "úroveň" jste to postavil vy. Je to jako bych řekl že Win98 mi pro práci s úložným zařízením stačí a vy jste mi to vyvracel tvrzením, že nepodporuje Fibrechannel a že jsem úplně mimo.
Ohledně linuxu jsem se o scanneru nezmiňoval, u scanneru jsem řekl, že je výhodnější koupit nějakej, kterej ty ovladače má u sebe než se pokoušet nějaké najít pro starší, funkční nicméně jenom funkční.
Celkově byla moje reakce směřovaná na tu superdruper vymakanou bezchybnou věc s automatickym stahováním ovladačů a s přítomností ovladačů u Windows, která tu byla, možná že ne takhle přímo, ale podobně nastíněna.
PS: Nevím proč MĚ konkrétně škatulkujete na nějakého studentíka co je rád když si může prohrabat smetí, takovou věc co jsem napsal řeší kluci v počítačových servisech často... Ano neberou za to 1500 na hodinu jestli na to budete narážet. Já jenom popsal zkušenost a vy jste ji odrazil argumentací která s tou zkušeností vůbec nesouvisí, příště se víc zamyslete.
Já jsem jen tvrdil, že na Linuxu se SANE můžet skenovat, pokud máte štěstí na typ scanneru, smíříte se s řadou nedodělků, nezáleží vám na kvalitě, nejde o vysoké objemy stran, nepoužíváte méně obvyklé features scanneru (jako endorser), nepotřebujete HDR atd. To jsou technická fakta. Linux není vhodný ani pro high volume scanning, ani pro DTP.
U automatického stahování driverů jsem jasně psal, že pro certifikovaný HW funguje vždy u Visty.
Počítačové servisy, zvláště v ČR, řeší typicky problémy plebs, co si koupí jakýkoliv levný polofunkční šmejd. S tím toho moc neudělám.
Kupodivu jsem mel XP SP2 CD a nic. A hw nebyl podle me nejak exoticky - nvidia SATA raid radic. Zajimave bylo, ze tvrdosijne odmital disketu s ovladacem - jako ovladace nactl, pole poznal - ale pri pokracovani instalace si je na disk nechtel zkopirovat.
Kolikrát mi přijde že ta cache je spíš muzeum ovladačů spojené s muzeem hardwarových myšlenek velkých firem které nikdy nebyly dány na trh. Muzeum ztracených nadějí. Kolikát tam člověk najde věci které nikdy neměl šanci vidět. Kdejaká stříhací karta kterou si pořídí tak deset lidí z miliónu. Když se mrknu do jádra linuxu tak tři čtvrtě věcí vim kde bych hledal a zbytek tuším. Jenom nepatrná část tvoří silně specifický balast.
Pichol som satelitnu kartu do PCI nakrútil do nej koaxial, zapol PC, spustil multimediálny prehrávač Kaffeine, dal naskenovať programy a všetko bolo OK. Všeho všudy 7min. Skús to s XPčkom... Hľadanie tej správnej verzie driverov a ich testovanie či ide-nejde zaberie pol dna. Tí čo majú SkyStar2 na XP vedia o čom hovorím. A ešte nepočítam hľadanie cracku na nejaký DVB program..
>... ked si musim instalovat jadro (pripadne naviac kompilovat)
> v ktorom je podpora pre XY grafickych kariet, wifi, tunery,...
A proc tedy s nimy jadro kompilujete, kdyz je vubec nepotrebujete? Kompilace jadra prece umoznuje nechat si v jadre a v modulech jen to, co opravdu potrebujete a vsechno ostatni vyhazet. Ja to tak delal jeste v dobach, kdy kompilace jadra znamenala desitky minut (na opravdu pomalych strojich i nekolik hodin) casu a kazdy ovladac, filesystem nebo jina fetura, ktera nebyla potreba, znamanala dlasich par minut casu a pripadne par desitek kilobytu neswapovatlene pameti navic.
Škoda, že tomu chybí empatické rozhraní, které by poznalo co jeho operátor potřebuje a to ostatní by skrylo.
Jinými slovy ... to je argument jak díra do prdele. Na co vůbec kompiluje jádro, když se v tom nevyzná. A ještě - proč otevírá položky menu o kterých nic neví.
Ne, Vas argument je jako ten hezky vyraz co jste pouzil. I kdyz se v tom clovek vyzna a chce zkompilovat jadro, tak ho ty kvanta voleb skutecne dokazou otravovat. Projit vsechny mozne nabidky vseho mozneho hardware je opravdu dosti otravne - pokud toho chcete vetsinu vyhazet a mit opravdu minimalisticke jadro tak to projit musite. V dobach jader 2.0.x to byla operace na chvilku... u 2.4 uz je to o dost horsi a 2.6 je peklo. Jo a uz existuje nejaky inteligentni system ktery by kontroloval zavislosti jednotlivych voleb? Kdyz jsem jednou kompiloval jadro asi 6krat nez jsem zjistil co se spolu hada a co naopak na sobe zavisi, tak jsem malem zesedivel. Mam Linux rad, pouzivam ho temer vsude, ale tohle je fakt peklo. Ovladace jako takove jsou mozna kvalitni, ale system jako je ta vec popisovana v clanku je skutecne potreba. Nechapu proc napr. neni mozne mit stabilni rozhrani alespon v ramci jaderne rady. Ja byt vyrobce hardware tak na Linux asi take kaslu. Protoze pro windows napisou jeden ovladac a pokud ho napisou dobre, tak funguje nekolik let a muzou na nej s klidem zapomenout. Pokud chce vyrobce HW podporovat Linux, tak musi neustale koukat jestli nevysla nova verze jadra a pripadne svuj ovladac poupravit kvuli nejake bomba novince. A v pripade ze vydava binarni ovladace (coz je jeho plne pravo), tak je jeste prekompilovavat pro novou verzi. Fuj. Linux neco jako DKMS potrebuje jako sul. Ovsem jeste lepsi by bylo, kdyby ovladace nebyly zavisle na verzi jadra a ten system by je pouze automaticky hledal a instaloval - a mohly by tam (pokud by nebyl duvod je upgradovat) zustat treba pet let a prezit 20 zmen verze jadra.
Asi by bylo lepší kdyby ovladače byli k dispozici a uživatel se nemusel kvůli licencím připojovat k Internetu. Tato funkce není ničím nová, a vychází z podstaty problematiky, kdy není možné šířit ovladače přímo v distribuci, ale uživatel si je může pro své vlastní potřeby stáhnout. Jde asi v podstatě o podobnou funkci jako známé CNR, ale místo programů jsou to ovladače.
Kdyby Dell raději vydal kompletní ovladače pod licencí GPL a o to stejné požádal i své další dodavatele a partnery, jsem si jistý, že by to bylo méně pracné a Dell by se stal naprostou jedničkou.
Dell je firma, která prodává počítače, nikoliv poskytuje služby, takže GPL by pro ně nebylo to pravé.
Podpora Linuxu je u Dellu proto aby prodaly počítače těm kteří by si jinak kombinaci Pc+Win nekoupili , nikoliv pro Linux samotný. A to hlavní "Dell ovladače" je jen virtuální pojem. Protože vlastně neexistuje "Dell HW" , vevnitř je Intel, Ati, Toshiba, Widcomm , a spousta jiných , takže jak můžou za ně vydat něco pod GPL? Jediné co může je apelovat na ony prvotní výrobce HW aby to vydaly pod GPL.
To že pro nějakou zájmovou\názorovou skupinu budou jednička je hezké ale užitek musí být oboustranný a pro Dell je ten užitek zisk a ne jen nějaké uznání někde ve forech.
Pleteš se když říkáš:
1. "Dell je firma, která prodává počítače, nikoliv poskytuje služby"
PC a hlavně servery bez služeb neprodáš, Dell služby dělá a poměrně dobře. Dell není prodejce PC někde na rohu ulice.
2. "Podpora Linuxu je u Dellu proto aby prodaly počítače těm kteří by si jinak kombinaci Pc+Win nekoupili , nikoliv pro Linux samotný"
Tože si někdo chce koupit PC s linuxem asi znamená jde především o Linux samotný.
Toto je podle mě jen další logický obchodní krok.
3. "Dell ovladače" je jen virtuální pojem.
To bych neřekl, protože v ČR se vyrábí základní desky a jiné komponenty a jsou opravdu DELL - mající vysoký standard. Další DELL výroba je v Irsku... mimo jiné příklad NTB DELL nemá základní desku Intel ale DELL.
4. "To že pro nějakou zájmovou\názorovou skupinu"
jistě by jsi chtěl ukázat jak ten Linux je špatný a postavený na pár lidech co si s tím jen hrají bez zodpovědnosti. Ale takové brojení a psaní už dnes nemá žádný smysl. Linux je už zde a už není okrajovou záležitostí.
----
Raději si ověř, jestli to co píšeš je tak úplně pravda, stačí si přečíst něco z firemních stránek a tak.... :)
----
Jinak, stahování ovladačů z licenčních důvodů je obtížné, pro uživatele bez přístupu na Internet neřešitelné a celková koncepce je zkostnatělá.
1. Dell je stále největší producent osobních počítačů
2. Oni chtějí prodávat počítače, pokud Vám lze prodat jen NTB+Linux dostanete od nich Linux , když BSD tak BSD . Ale dělají to pro to aby se jim prodávali NTB lépe, ne pro blaho Linuxu oni podnikají, nehrají si na charitu\hrdiny až bude v modě QNX tak tam budou cpát QNX
3. Ne nepochopil jste, deska je Intel takže ikdyž to vyrábí Foxconn u Pardubic je to záležitost ovladačů na Intel. Proto jsem myslel že nemůže Dell bez posvěcení těch ostatních něco dát GPL.
4. Opět nepochopil, pokud vydají pod GPL bez dovolení toho kdo to opravdu vytvořil budou sice u Vás jednička ale u toho komu něco zveřejnili budou mít průser.
> Byl už proto zkompilován tak, aby spolupracoval s dalšími nástroji různých distributorů
> YUM (Yellow Dog Linux), Kickstart (Mandriva) a další.
Yum sice puvodne znamena "Yellow Dog Updater Modified" ale dneska bych rekl, ze vice nez z YDL je znamejsi z Fedory, CentOS nebo RHELu - tj. obecne "Red Hatich distribuci"
Tak koukám, že mě petr předběhl. Chystal jsem podobnou noticku do zítřejší sklizně.
Koho zajímá více informací, tak doporučuji tento článek: http://www.linuxjournal.com/article/6896
Automatická instalace v budoucnu má být možná, díky automatickému vkládání Provides: programem mkrpm.
Osobne si to představuji (to znamená že to nevím jistě), že se tam dá něco jako:
Provide: ati-2600XT-driver
A instalátor se podívá co máte za kartu (lspci) a pak spustí ekvivalent k "yum install jmenokarty-driver" a mělo by to fungovat.
Mi by uplne stacilo, kdyby se dalo Ubuntu 7.07 Feisty (flame mne NEZAJIMA!) naintalovat ma muj DELL Latitude D630 BEZ PROBLEMU s instalaci (musel jsem jit pres Desktop Alternate CD, pak nejake aktualizace a az pak grafika).
A to nemluvim o tom, ze se mi STALE NEpodarilo rozchodit X-ka tak, abych mohl pouzivat ten laptop a dalsi pripojeny LCD monitor v Xinerama rezimu...
Kdyz si vybavim, ze pitome widle potrebovaly jen par prosto-clicku, je mi z toho do place. Tezko pak budu nekoho presvedcovat o tom, ze Linux je LEPSI...
Vo windows to ide? Obvykle totiz notebooky nemaju dual head iba prepnutie vystupu z LCD na externy vystup co je iba primitivny obvod. Takze to z pohladu HW ani nie je mozne.
Jo jo přesně tak Takhle je to řešený i u mého 9 let starého ThinkPadu. Ale dneska je už doba jiná, v podstatě všechny dnešní grafické karty počítají s připojením 2 monitorů současně, takže ten výstup vzadu z noteboku na monitor je nezávislý na tom, který je vevnitř připojen na displej. Takže z pohledu HW to možné je a je s tím i počítáno.
Aha tak som to vyskusal a mas pravdu. Mam NVidiu a pomocou standardneho setup panelu som bez hackovania nastavil TwinView na externy monitor. Dokonca bez restartu Xka. Tie klikatka ma dostali.
Podla packages.ubuntu.com je vo feisty xserver-xorg-video-i810-1.7.4, X3100 potrebuje >=2.0.0 (predpokladam, ze je tam intelia grafika, s nvidiou a xineramou som problem nikdy nemal).
Dalej treba xserver-xorg-core >= 1.3.0.0, ktory podporuje xrandr 1.2 extension.
Potom uz staci len:
xrandr --output VGA --left-of LVDS --auto
(--same-as, --right-of, apod.), pripadne sa za behu daju displaye vypinat. V dalsich verziach by to uz malo byt podporovane aj v KRandrTray (KDE klikaci applet).
Diky, vidim v tom snahu o pomoc.
Ale MOC se omlouvam, ja pouzivam Linux jenom jako trochu vic zkusenejsi uzivatel a toto byly rady od profika profikovi.
Nezadam, aby ses tady rozepisoval do detailu, ale mohl bys mne, prosim, odkazat na nejake stranky, kde bych nasel nejaky podrobny postup?
PS: ta karta je opravdu Intel965 GM (Intel GMA x 3100) ...
Len aby sme sa nedozili toho stavu s ovladacmi, aky existuje na windows. Ze kazdy jeden kus HW bude mat svoje vlastne ovladace, DKML bude hladat ovladace pre _PRESNE_ ten kus HW a nie tak, ako doteraz, ze ovladace budu viazane na chipsety, cize staci pre XY podobnych HW jeden ovladac.
Kazdopadne dobry clanok, vyskusam to, aj ked pre moje zelezo mam vsetky drivery skoro priamo v kerneli.
To bych neviděl jako problém. Stejně bude potřeba udržovat databázi HW, takže když se objeví nový kus železa se stejným chipsetem, správce jen zapíše, že ID 123456789 patří ovladači XY a bude to.
Neda mne to, abych tady (jako jinak spokojeny dlouholety uzivatel Linuxu) nenapsal jednu vec:
Vsechny tyto komplikace s ovladaci by odpadly pokud by ABI v jadre neovlivnovaly myslenky nekterych fanatiku. Nutnost prekladat znovu (a nekdy i trochu modifikovat) ovladac pro temer kazdou verzi jadra je tou nejvetsi slabinou Linuxu. Az se toho zbavime (a neni to technicky nybrz ciste "politicky" problem), bude to velky svatek.
Da se chapat nekompatibilita binarky ovladace mezi "velkymi verzemi" jadra - 2.2, 2.4, 2.6, ..... to se pochopit da. Ovsem nekompatibilita mezi treba dejme tomu 2.6.18 a 2.6.21, to pusobi spise jako vyplod nejakeho sabotera.
Aha, stačilo se jen trochu proplesknout, přečíst si to znova a už to začínám chápat.
Ale opravdu si myslíš, že ty změny v jádře linuxu dělají schválně, jenom aby zamezili kompatibilitě zkompilovaných modulů?
Ty zmeny tam delaji z jakychsi pofidernich duvodu, ktere souviseji s pocitem, ze by se snad zastavil vyvoj jadra, pokud se subverze od subverze nebude menit jako chameleon. A pak tam jiste hraje roli i GNU fanatismus - umyslne znesnadnovani tvorby binarnich uzavrenych ovladacu (jenze tim otravi i vyrobce, kteri by jinak byli i ochotni delat ovladace otevrene).
GNU fanatismus - To zní jakoby byli někteří jaderní vývojáři uchyláci. Co si pod tím představuješ?
Nepleť si příčinu a následek. Problém dělají binární ovladače. Ne ti co se jim brání.
Určitě víš, že je kernel šířen pod GNU GPL v.2. To znamená, že všichni kteří se na něm podílejí s touto licencí dobrovolně souhlasí, a také jelikož to jsou inteligentní lidé lze předpokládat, že ví co dělají. Tvorba binárních uzavřených ovladačů je v příkrém rozporu s filozofií GNU GPL resp. svobodného softwaru. Každý kdo je alespoň trochu při smyslech netouží po uzavřených ovladačích. Z druhé strany vzato tvorba binárních ovladačů nepřinese svobodné ovladače. Je to buď a nebo. Vzpomínám si na jednu výstižnou odpověď Davida Kolera, když se ho kdosi ptal proč dělá jen velké koncerty: "Protože když chceš dělat velké, tak nemůžeš dělat malé".
Samozřejmě snadno dostupné ovladače instalovatelné bez kompilace jsou v zájmu každého uživatele Linuxu. Zachování duševního vlastnictví k HW (tedy utajení zdrojáku ovladače) je zase v zájmu každého výrobce HW, a navíc v některých případech nutnost před zákonem (například driver nesmí povolit překročení některých parametrů u WiFi a modemů, což u open source driveru nelze zaručit). No a v zájmu vývojářů Linuxu zase je, aby měli open source ovladače pro veškerý HW, protože open source je prý dobrý. Když jsou ty zájmy takhle různé, těžko si to sedne :)
Dodržování limitů výkonu vysílače je záležitost provozovatele zařízení, ne tvůrce ovladače. Není žádný objektivní důvod proč uměle bránit nastavení tak velkého výkonu, že s pomocí WiFi karty bude možné ohřát si objed jako v mikrovlnce, pokud to zařízení fyzicky umožňuje. Důležité je jen to, že se takový výkon nenastaví samovolně.
Minimálně v případě modemu tento neprojde homologací, pokud může vybočit z parametrů způsobem, který by mohl poškodit telefonní síť. To je důvod, proč řada winmodemů nemá open source drivery. U WiFi karet je to nejspíš podobné - například na některých frekvencích nesmí být schopny vysílat atd.
To je nesmysl, homologace se týká hardware a ne ovladačů. To by pak musely být homologovány všechny updaty driverů. To, že něco nemá open source ovladače určitě není kvůli homologaci.
Ta homologace se týká výrobku jako celku, včetně firmwaru (ukažte mi modem bez procesoru s rychlostí nad 2400 bps). Winmodem ani velké procento WiFi karet (a mimochodem třeba řada zvukových karet) si bez uploadu firmwaru do zařízení ani neškrtne, a nefunkční "cihla" asi homologaci nedostane. A protože firmware zařízení je součástí driveru (který provede ten upload firmware do zařízení), nelze dost dobře mít open source driver, protože by umožnil parametry zařízení výrazně změnit.
Dost casto je firmware primou soucasti zarizeni (ulozen v EEPROM) a ne driveru. Krom toho existuji i oficialni open-source drivery pro zarizeni, u kterych driver nahrava firmware do zarizeni.
Důvod proč nejsou ovladače k winmodemum je ten,že se vývojáři dohodli že jedná o zlo které nebudou podporovat. Já sem si kdysi koupil "winmodem" který měl v sobě DSP a k tomu opensource ovladač byl.
Ukažte mi modem, který nepodporuje několik vzájemně napěťově nekompatibilních typů linek na stejném rozhraní, ale zároveň hardwarově umožňuje softwarovou regulaci napětí mimo bezpečné hodnoty.
O WiFi kartách teď plácáte nesmysly. Až do nedávna u nás bylo pásmo 5GHz licencované a nebylo možné ho používat pro soukromé sítě bez povolení od ČTÚ. Podle vaší logiky by tedy žádné zařízení podporující standard IEEE802.11a (5GHz WiFi) nemohlo projít homologací, respektive by měly být prodejné pouze proti povolení od ČTÚ na využití pásma 5GHz k provozu WiFi sítě. Přesto mám v tuto chvíli na stole hned 2 zařízení, která jsou homologovaná, podporují IEEE802.11a, koupil jsem je ještě před uvolněním pásma 5GHz pro nelicencované soukromé sítě a žádné povolení jsem nepotřeboval.
Hardware se deli na dva druhy: komplikovane zalezitosti, ktere vyzaduji komplikovane chipy na zarizeni (napr. graficke karty) - v takovem pripade ovsem je know-how v onech chipech a nikoliv v ovladacich (viz i nedavne prohlaseni AMD/ATI), a triviality jako jsou winmodemy, kde jednoduse neni zadne dusevni vlastnictvi ktere by stalo za to chranit, pokud tedy nepatrite k lidem kteri uznavaji napr. patent na doubleclick.
OS GNU/Linux nepotrebuje spravu ovladacu, ani zadne podobne nesmysly.
Bezny uzivatel nevyzaduje kvalitni ovladace, bezny uzivatel vyzaduje aby mohl spoustet vsechny programy, ktere sezene a to nejlepe bez konfigurace cehokoli a na jedno kliknuti.
Soucasny zpusob (kompilace kernelu) je plne vyhovujici a lameri z Dellu na tom pracovat mohou, presto se to uzivatelu jako jsem ja nastesti netyka, zadny ze skutecnych GNU/Linux developeru spravu ovladacu nepotrebuje, mame find, grep a kernel/Documentation/.
Programovat OpenSource pro nekoho jineho, nez pro programatory je zvrhlost, BFU se spokoji s widlemi a jejich klony ala *buntu $hit/Debilian.
az na narazku na debian s tebou souhlasim.
bojim se toho ze vyrobci hw nakonec nebudou distribuovat ovladace jinak nez pres toto udelatko. precijenom je linux o svobodne volbe a doufam ze to tak i zustane.
Ja bych proti Debianu a jeho derivatech nerekl jedine krive slovo, kdyz by z nej markentingovi trotlici denne nedelali the best of the world. Vzdyt je to tu vsude samy Debilian / *buntu $shit / Suse / Mandriva / DesktopBSD / GreenLinux a same podobne distribuce pro lamy, o kterych bohuzel pise take jedna z lam, z toho jsem znechucen a tak trolluji v diskusich a snazim se zpet vnest rovnovahu.
Debian je uplne obycejna distribuce, neni v nicem nadprumerna, nikam se nehodi vice, nez konkureti a jedina vyhoda je, ze byl tvoren pro Debbie (pro zenskou), tzn. neni logicky a vetsina jeho (napriklad) cest ke konfiguracnim souborum nedava smysl, tzn. nelze si je odvodit, jen se je naucit z pameti, coz je memory-wasting...
Za svinsky marketing by se melo strilet, Vista $hit, *buntu $hit, Solaris $hit.
Nelze pouzivat google, aniz bych narazel na lamerske Vista/*buntu/apod. imitace odbornych clanku.
+1 :-) Asi ne, já už mnoho let používám SUSE (první koupená verze byla 7.0) :-) a tak jsem holt lama. No asi je to proto, že nepřekládám kernel nejméně jednou týdně a též si ani nepíšu s Andrewem Mortonem o tom že parametr /NODEVICE /NOFLOATING při volání funkce jádra je neefektivní :-) Heheheh
Jenom by mě zajímalo, jakou rovnováhu. To jako má zase linux vypadat jak v 90. letech nebo co? Mně to naopak vyhovuje, že se nemusím starat o kdejakou ptákovinu, kvůli každé změně rekompilovat jádro a podobně a můžu se věnovat tomu, co mě živí.
Nikdo vám nebrání zůstat u těch distribucí, které vám vyhovují, ale nebraňte ostatním, aby přiblížili linux obyčejným uživatelům. Všichni máte plnou hu... ústa svobody, ale sami ji druhým nedopřejete.
Je to troll. Podla jeho prispevku vsetko je zle. Vsak nech si vsetko stahuje. Uz aj cisty blazni pochopili ze potrebuju nejaky automatizmus aby sa z toho vsetkeho software nezblaznili. O com inom je Gentoo.
Niekedy na systeme stacilo jadro, VIM a GCC a clovek sa citil spokojny. Dnes toho treba o cosi viac. Od vtedy ako som zacal pouzivat Debian som jadro nekompiloval a nevidim to ako problem. Vsetko okrem nejakych Java programov taham z repository.
Přesně tak. Nevím, proč kompilovat, když nemusím. Ať si kompilujou na desktopu nadšenci. Mi úplně stačí, když to musím dělat na serverech. Na desktopu kliknu a nestarám se :) Už vidím někoho, kdo spravuje xx desktopů všude možně, třeba i u známých, jak všechny obchází nebo přes ssh stahuje zdrojáky jádra a ovladačů a šplichtí se s tím.
ale no tak, po instalaci se system nakonfiguruje a pri kazde dalsi rekompilaci kernelu se pouzije jeden jediny prikaz:
/bin/cp -r /usr/src/linux /usr/src/linux-2.6.22.1 && cd /usr/src/linux-2.6.22.1 && /usr/bin/wget http://kernel.org/pub/linux/kernel/v2.6/incr/patch-2.6.22.1-2.bz2 && /usr/bin/bzcat patch-2.6.22.1-2.bz2 | patch -p1 && /bin/cp ../linux/.config . && make oldconfig && make modules && make modules_install && /usr/bin/rm /usr/src/linux && /usr/bin/ln -s /usr/src/linux-2.6.22.1 /usr/src/linux && /sbin/reboot
prikaz muze byt snadno vygenerovan a s pomoci regularnich vyrazu v nem mohou byt upraveny veskere dynamicke hodnoty + take lze snadno rozsirit o automatickou upravu grub.conf (popr. jiny bootmgr.conf) a vsem novym features muzete klidne automaticky priradit N, pokud na ne nemate cas.
Na serverech je potreba kompilovat kernel kvuli bezpecnostnim chybam, ktere se ve starsich verzich nachazeji.
At se na jednom nejmenovanem serveru nauceji pracovat v shellu.
Jenže celá ta konfigurace zabírá zbytečně čas, tak proč toho nevyužít, že to dělat nemusím?
Na serverech se kompiluje nejen jádro, ale i spousta dalšího softu jako databáze apod. Ale zase tam odpadají starosti s hardwarem a grafickými drivery :)
Ono ho to celé přejde ve chvíli, kdy si uvědomí, že ten skript musí nakrmit současnou a cílovou verzí kernelu. Podruhé ho to přejde, až si uvědomí, že když wget nenajde co hledá, a místo toho stáhne stránku "404 - nenalezeno, ale vyberte si z následujících linků...", tak se to pak bude snažit dál zpracovat. Podobných problémů bude tisíc, a zatím co on je bude řešit, a po takto strávených dnech až týdnech si libovat, že mu to běhá skoro jako Windows NT 3.51 (jen bez aplikací, a chudší na features), ostatní budou pracovat a vydělávat peníze. No a protože práce kvalifikovaného odborníka má cenu několika licencí Windows za den, je lehké si spočítat rentabilitu.
Já na Gentoo nic krmit nemusím, mě se pravidelně při updatech stahují zdrojáky aktuální verze kernelu a navíc se ještě vytvoří symlink /usr/src/linux na nejnovější verzi. Už asi půl roku používám triviální skript, který buď zkopíruje .config z /proc/config.gz nebo z poslední verze zdrojáků a spustí make oldconfig (update .config z předchozí verze zdrojáků), nebo spustí make menuconfig (interaktivní nastavení pomocí nabídek), když nenajde žádný použitelný starší .config. Pak všechno zkompiluje a nainstaluje a navrch ještě zkompiluje a nainstaluje všechny externí moduly (ovladače WiFi, Ethernetu a grafiky). Vygenerování GRUB nabídky podle vzoru to samozřejmě umí také. Jediné, co musím udělat, je spustit root terminál, spustit skript, odklepat pár nových nastavení a po 2 minutách restartovat počítač.
Kolikrat to jeste clovek bude psat.... no ale budiz:
1. Stabilni API neni politicke, ale ciste technicke (a spravne) rozhodnuti. Jeho zavedeni by rychle ucinilo kernel temer neudrzovatelny, vyvoj by se nesmirne zpomalil a velmi by pribylo chyb. Vice viz /usr/src/linux/Documentation/stable_api_nonsense.txt
2. Vzhledem k cislovani verzi kernelu rady 2.6 jsou 2.6.18 i 2.6.21 "velke" verze kernelu. "Male" verze maji o tecku vice. Nicmene kdyby to bylo treba kvuli oprave chyby, jiste by bylo spravne zmenit API i mezi nimi.
Musim nesouhlasit. Nemusim argumentovat ja, muzeme si precist primo Linuse:
- I _want_ people to expect that interfaces change. I _want_ people to know that binary-only modules cannot be used from release to release. I want people to be really really REALLY aware of the fact that when they use a binary-only module, they tie their hands.
Note that the second point [vyse uvedeny] is mainly psychological, but it's by far the most important one.
Takze _je_ to politicke rozhodnuti. Samozrejme nektere zmeny musi byt provedeny, ale clovek by si pokazde mel rict "je to opravdu nutne?" a ne "no nic, tohle smaznu a at se s tim hosi s ne-jadernymi ovladaci (klidne open-source) poperou po svem".
Uvedomte si proboha, ze tohle zasahuje daleko vice open-source ovladace, ktere nejsou v jadre, nez firmy s binarnimi ovladaci. Vite kolik lidi, co vyrabi ruzne drivery pro USB kamery, exoticky HW, atd. musi pri kazdem releasu jadra venovat svuj volny cas do patchu jenom proto, ze se neco zmenilo? A argument "at si to dostanou do jadra" take neobstoji, protoze tam neco dostat je beh na hodne dlouho trat (viz nektere filesystemy, atd.)
Vašee odmítavá reakce na předchozí příspěvek je pouze projevem emocí. Z čistě technického hlediska má ten pisatel pravdu. Vámi linkovaný mail od Linuse pak Vaši věc vůbec nepodporuje, neboť je k tématu irelevantní. Linus zde pouze zdůrazňuje, že si přeje, aby všichni věděli, že vnitřní API se budou měnit, aby pak za ním nechodili skuhrat.
To, že se Linus rozhodl vést jádro tímto směrem, bylo zajisté politické rozhodnutí. Avšak z hlediska vývojáře jádra a OS driverů je to technicky nejlepší rozhodnutí. To, že to ztěžuje život vývojářům closed source driverů je jistě nepříjemné, ale z dlouhodobého hlediska pro Linux možná jen dobře.
Ne, neni to projevem emoci, ale racionalniho uvazovani. Nekolik let je mym hobby rozchazeni exotickeho hardware pod Linuxem a verte mi, neni nic horsiho nez zmena ABI/API s kazdou verzi. Cetl jste muj dovetek, ze nejde o binarni ovladace (protoze zaplatit programmera, ktery jednou za mesic neco patchne neni napr. pro nVidii opravdu problem), ale daleko vice o open-source, ktere nejsou v jadre?
Podivejte se treba na vyvoj spca50x a jejich Changelog, jak neustale museli neco fixovat, jenom proto, ze se "nahore" (LKDs) bylo rozhodnuto, ze se nejaka funkce zmeni. A to jsou "ti hodni" open source lidi! Ostatne moje prihoda s LIRC nize mluvi sama za sebe.
Z ciste technickeho hlediska pravdu opravdu nema, protoze zpetna kompatibilita je sice balvan na noze pro vyvojare jadra/knihoven/atd., ale odlehceni pro vsechny ostatni, kteri ten konkretni kus SW pouzivaji. Diky tomu, ze nekteri neciti tuhle zodpovednost, se neustale resi problemy typu "no, tak tohle od verze knihovny libxxx-3.10.1a uz nejede, protoze hosi zmenili API, takze si pockejte, az to fixnem u nas". Pokud se neco zmeni v "korenovem" systemu stromu zavislosti, mnozstvi investovane prace vsech ostatnich stoupa geometrickou radou.
Princip je v tom, ze vyvoj by mel byt z vetsi casti evolucni (tj. zpetna kompatibilita) a revolucni (tj. zmena API, principu fungovani, atd.) jenom v pripade, kdy je to nezbytne nutne.
Nepamatuji si presne cislo, ale kdyz placnu 82-92%, tak natolik jsou geneticky kompatibilni lide s vetsinou lidoopu (neplest s opicemi, tam je to horsi. Nechytat za slovicka, vsadim boty ze predrecnici mely na mysly lidoopi). Asi ze 47% se zelim.
A ted doufam ze neplacam blbosti, ponevaz si to ted nemam jak overit.
Takze ne plne. Nema nekdo tuseni na kolik procent je si je ABI komatabilni mezi verzemi?
S simpanzi 96%, do tech 82% by se mozna vesli i ty opice, 20% genu mame spolecnou s E.Coli. Nicmene vsimnete si, ze pres tak velkou shodu neni mozne aby spolu clovek a simpanz meli potomka.
Jinak, co se tyce "par tydnu" ... jadro se za posledni rok zlepsilo mnohem vic nez clovek za poslednich 10000 let. Bude jeste pekne dlouho trvat nez bude jadro tak stabilni jako clovek ...
Why? Because I'm a prick, and I want people to suffer? No.
Because I _know_ that I will eventually make changes that break modules.
And I want people to expect them, and I never EVER want to see an email
in my mailbox that says "Damn you, Linus, I used this binary module for
over two years, and it worked perfectly across 150 kernel releases, and
Linux-5.6.71 broke it, and you had better fix your kernel".
See?
I refuse to be at the mercy of any binary-only module. And that's why I
refuse to care about them - not because of any really technical reasons,
not because I'm a callous bastard, but because I refuse to tie my hands
behind my back and hear somebody say "Bend Over, Boy, Because You Have
It Coming To You".
Pokud tohle "politické" rozhodnutí znamená, že se v jádře nemusí udržovat 4 různá USB rozhraní jen aby pár prehistorických binárních ovladačů fungovalo i po 10 letech, tak je to rozhodnutí správné. V jádře je spousta důležitějších problémů než údržba zastaralého kódu.
Ten zásah open source ovladačů mimo jádro není zase tak velký. Až na výjimky se obvykle mění jen drobnosti a upravit ovladač pro nové jádro zvládne každý programátor, který umí používat grep a číst changelog. Pak už záleží jen na tom, jak dobře spolupracují hlavní vývojáři toho ovladače s komunitou.
No pockat, ale neni to nahodou presne to, co rikam?
Tj. Linus si zvolil cestu "nechci mit balvan udrzovani API/ABI na svych bedrech", coz je jiste pouze v jeho kompetenci a jeho osobni rozhodnuti a jak sam tvrdi, ze "not because of any really technical reasons". Ja chapu, ze je zpetna kompatibilita je "vopruz", na druhou stranu benefity jsou vice nez znatelne.
Priklad Linuse je, sam uznavam, trosku spatny, protoze je to clovek veskrze pragmaticky. Bohuzel jsou kolem jadra jini (napriklad Greg KH), kteri jsou opravdovi fundamentaliste, kteri chteji dokonce moznost jakehokoli std. ABI znemoznit. 2 mesice zpet kolem toho byla tusim dost drsna diskuze na LKML.
A co se tyka zasahu do okolnich driveru:
Jedna vec je zmena kodu (kterou proste musi udelat vsichni a nemyslim si, ze by byla nejak nicotna), druha vec jsou uzivatele, kteri cekaji, az se patch dostane vubec ven. Jen tak pro ilustraci vypis (baj woko, bez grepu) z Changelogu jiz zmineneho spca50x:
* Fixes for compilation against 2.4.20 kernels
* FIX compilation problem under kernel 2.4.24
* Add usb_kill_urb() for the 2.6.9 kernel
* Re-sync with spca5xx to fix support for > 2.6.5 kernels.
* sync with spca5xx to make it compile with gcc 3.4.3 and to make it work with linux 2.6.10.
* restore the le16_to_cpu() for kernel up to 2.6.11
* FIX from Ulisses De Penna Kernel problem with 2.4.23
* FIX compilation with kernel > 2.6.14
Ja vim, mozna to pro nekoho neni moc (urcite to neni vsechno), mozna pro nekoho ano. Faktem vsak zustava, ze cloveka nenastve nic vic, nez ze po upgradu kernelu se musi prekompilovat X modulu, z nichz pulka ani nejde, protoze se ceka na fix.
Ano, protože se čeká, až to někdo (jiný) opraví. Ze 3 počítačů používám ovladače mimo jádro jen na jednom (celkem 3 - fglrx, r8168 a ipw3945), z toho jen s fglrx mám vámi popsané problémy, protože kvůli uzavřenosti nemohu dělat drobné opravy sám.
1) opravim si to sam a cekam, az to bude ofiko
2) musi si to opravit jini a cekaji, az to bude ofiko
3) a nakonec to opravi autor driveru a je to ofiko
Takze jsme na tom delali vlastne vsichni -> plytvani zdroji. Jiste, autorovi muzu poslat svuj patch, ale ten ho opet musi projit, udelat si to "po svem", takze zase prace navic.
A uvedomte si take, ze ne vsichni jsou si schopni neco sami opravit. Samozrejme je zde nekde vyse uvedeny argument "Linux neni pro BFU", a pokud tomu tak opravdu je, muzeme klidne diskuzi utnout, protoze ne-BFU si to fakt mohou opravit sami, o tom nepolemizuji. A hazet vsechno na spravce distribuci (jak nekdo nahore navrhoval) mi pripada jako presouvani problemu z jednoho cloveka na jineho.
I když se zanedbají BFU, pořád je tu dost programátorů používajících daný hardware na to, aby oprava byla venku během pár hodin po vydání nové verze jádra.
Umim instalovat a spravovat domeny, nadnarodni site, politiky, clustery a libovolne sluzby jak na Win tak na Linuxu. Presto kdyz je ve zdrojaku neco rozbite a nejde to zkompilovat, tak to vetsinou neumim opravit (vlastni rukou), protoze mne programovani nikdy nebavilo a kaslal jsem na to. Takze jsem podle teto definice asi BFU. Takovou logiku miluju.
Z pohledu vyvojare jadra BFU zcela jiste jsi (jako asi vetsina z nas, co nejsme profesionalni programatori). Nechapu proc se rozcilujes, neni to nic hanliveho.
Az poletis letadlem, taky budes z pohledu kapitana "tamten pasazer vzadu" (ekvivalent BFU), u doktora "tamto vezetpecko" (ekvivalent BFU) a z pohledu pravnika jen "pripad XY" (rovnez ekvivatent BFU). Clovek proste nemuze umet vsechno na svete a proste ve vetsine pripadu vystupuje prave v roli BFU.
To jestli umis konfigurovat site, opravovat servery nebo nejlepe z cele Prahy zpivat karaoke s tim nesouvisi.
LoL, pokud si vazne myslis, ze na tom neni nic hanliveho, tak si najdi definici te zkratky a mozna pochopis. Osobne bych taky nikdo nerekl o programatorovi, ze je to BFU, protoze neumi spravovat to co ja. Je to taky odbornik, ale v jine oblasti. Oznaceni "BFU" je proste zcela mimo.
Btw letadlem litam docela casto...i jako pilot :-D
IMHO Bloody Fucking User jsou spíše slova, ze kterých ten akronym vzniknul, v diskuzích se už dávno většinou BFU používá ve smyslu Běžný Franta Uživatel. Akronymy jsou zkrátka praktické a lepší akronym než BFU zkrátka nikdo nevymyslel (nebo se aspoň neujal). BTW já jsem také BFU ;-)
> No pockat, ale neni to nahodou presne to, co rikam?
Ty mozna jo, nicmene puvodni prispevek od glx byl ve stylu "kerneli vyvojari meni rozhrani jen proto, aby zkomplikovali zivot vyvojarum closed-source driveru".
Oproti tomu prispevek Linuse ukazuje ten technicky duvod - udrzovani kompatibilty je pracne a komplikuje vyvoj - rozhrani se meni proto, ze vyvojari se pri upravach jadra nechteji svazovat udrzovanim kompatibility.
No, ted jsem opravdu zaskocen, protoze jsem si myslel, ze tenhle nazor na ABI mam jenom ja. Kdyz jsem s necim podobnym prisel do diskuze na ABCLinuxu, vsichni mne vyfuckovali big-time :-/
Prihoda z realneho zivota: zrovna vcera jsem si chtel zkompilovat po dlouhe dobe LIRC pro ovladac meho TV tuneru. Samozrejme LIRC neni v jadre (mam Debian-patchset 2.6.22), takze jsem musel rozkompilovat jadro, zacit kompilovat LIRC a ejhle - dva symboly se ztratily z ovladace BT8xx, takze LIRC nejde rozchodit (presneji receno modul lirc_gpio). Samozrejme se ted ceka na vyvojare LIRCu, az si najdou trosku casu a fixnou to. Chybi totiz 2 docela podstatne funkce (get_gpio_queue a get_card_info) a moje pokusy o nalezeni potrebnych informaci nekde jinde v jadre skoncily asi po pul hodine. Kdyby bylo stabilni ABI, byl by svaty klid a nemysel bych kompilovat nejaderne ovladace pokazde po upgradu jadra jak mameluk a modlit se, at se tam proboha nic nezmenilo.
Tento nazor hajim jiz velmi dlouho. Za ta leta jsem dosel k jednoznacnemu zaveru, ze propagatori "nestabilniho" ABI jsou nahony vzdaleni praktickemu zivotu a pohybuji se pouze kdesi mezi ryzimi akademiky.
Podle me je prave toto vec, ktera rozvoj Linuxu brzdi. A brzdi jej velmi silne. Pokud by se Linux tohoto nesmyslu zbavil, razem by ochota vyrobcu hardwaru podporovat Linux stoupla prinejmensim o jeden rad, pribylo by uzivatelu a diky tomu se objevily nektere klicove aplikace v nativni verzi.
Motivaci umyslne "nestabilniho" ABI chapu skutecne cim dal mene. Chapu to skutecne predevsim jako zalezitost jisteho fanatismu a nesmyslneho purismu nekterych lidi. Je to VELKA skoda.
Na druhe strane je obdivuhodne, kolik hardwaru dnes prumerna Linuxova distribuce bez problemu podporuje i pres tuto nesmyslnou prekazku.
Tím jste ale nedokázal nic o Linuxovém ABI, ale pouze to, že tvůrci vaší oblíbené linuxové distribuce nedělají správně svojí práci. Kdyby totiž dělali svojí práci, tak dvěmi kliky nainstaluejte lirc z repozitáře a odcházíte na párek.
To je klasika. Když o něčem tvrdíte, že to není skvělé, nesmí to být Linux nebo na Linuxu. Možná vás (i tady) vyfuckují méně, když začnete slovy "Linux je super, miluji myšlenku open source, ale...", a skončíte slovy "A teď jdu pracovat na GPL projektu, protože je to náplní mého života".
Víte co to je ABI? Zjevně ne, protože jinak byste tu nemachroval s těma pojmama a nepsal kraviny http://en.wikipedia.org/wiki/Application_binary_interface vs http://en.wikipedia.org/wiki/API. Takže ovladače používají kernelovou API a uživatelské programy používají kernelovou ABI. A ano, je pravda, že API se mění. Ovšem s tím se počítá, protože kernel je velice živé maso.
Mozna nez zacnete machrovat byste si mohl aspon precist to na co odkazujete a vedel byste, ze to neni tak jednoznacne.
"An ABI differs from an application programming interface (API) in that an API defines the interface between source code and libraries, so that the same source code will compile on any system supporting that API, whereas an ABI allows compiled object code to function without changes on any system using a compatible ABI."
Čeho byste dosáhl? Pár volných MB operační paměti, pár desítek volných MB na disku, asi tak půl vteřiny ušetřené při startu systému, pár ušetřených kilowatthodin elektřiny a možná i pár procent výkonu navíc. Na dnešních počítačích už to ale není tak zajímavý zisk.
Nerobí to OS, ale správci balíčků dělají svojí práci pořádně.
Funguje ti vsechen hardware ? Pokud ano, bud mas kliku nebo sis dobre vybral. Pokud ne, tak kdyby sis ty ovladace zkompiloval, mozna by to zacalo fungovat.
(Samozrejme tohle je dodatek k tomu, co uz rikal Martin Doucha).
(PR)Dell nezjednodusi, ale zkomplikuji vse ceho se dotknou, ti BFU jen svazuji ruce skilled adminum, Dell nemam rad, protoze si jen dela reklamu a jeste k tomu neudal zadne tech specs, jen marketingove kecy.
Kdyz nad tim tak premyslim, tak problemy Linuxu jsou v pristupu jakym se ovladace pisou. Nejprve HW, pak se bastli ovladac a ten se pak ohyba, aby zvladl varianty stejneho hw od ruznych vyrobcu. Mozna ze to jde delat i jinak. Proc vsechny postscriptove tiskarny funguji s jednim ovladacem? Protoze dodrzuji jednotny standard. Proc spustite na procesorech AMD anebo VIA programy psane pro procesory Intel? Protoze se snazi byt maxialne kompatibilni.
Jiny pristup k ovladacum bude, ze se nadefinuje API, kteremu se musi vyrobci HW prizpusobit. Problem je navrhnout dobre API. Ale pokud by se definovali tridy HW s jasnym API (podobne jako treba tridy v FireWire, pripadene USB), byl by problem podpory HW na ruznych platformach jednodussi. Nebylo by treba delat reverse engeneering, nebylo by treba ziskavat "tajnou" dokomentaci od vyrobcu HW. Problem by se otocil. Vyrobci by HW navrhovali tak, aby byl kompatibilni s API definovenym pro ovladace. Pokud by vyrobce nemohl API dodrzet, musel by vydat specifikaci popisujici odchylky. Vim, ze neni snadne provest popsanou zmenu, ale napad je to zajimavy, ze?
Nevim, zda Dellu pomuze distribucni system na ovladace. Budou mit vlastne co distribuovat? ;-) Kvalitni ovladace v jadru jiz jsou a ten zbytek je lepsi tam nemit... Pokud budou distribuovany jen binarni ovladace, je mozne, ze bude dochazet k vzajemnym kolizim mezi ovladaci, k problemum na SMP systemech (protoze ovladac byl vyvinut jen pro jednojadrove CPU), a podobne.
Samozřejmě drivery mají standardní API (tedy ve Windows), a zařízení mají zpravidla standardní rozhraní (USB, SCSI, PCI). Ovšem to, že něco připojíte přes USB, ještě nic neříká o komunikaci na vyšší úrovni abstrakce, kterou má na starosti driver.
Proč musím mít speciální driver pro webkameru a neni definováno obecné zařízení camera které jenom pošle zpátky fičurky co umí? Proč se v operačních systémech jenom neaktualizují tyto obecné komunikační protokoly? Vemte si příklad třeba z USB Mass storage. Musíte mít na každý flashdisk driver? Ne nemusíte. Tak proč není možné toto u HW?
Flashdisk je taky HW. U spousty zarizeni neco podobneho skutecne funguje, nebo treba alespon castecne (kazda graficka karta funguje jako VGA, dneska navic vetsina umi VESA, i kdyz to neni uplne presne ono protoze to pouziva kod v pameti karty spousteny na procesoru). Problem je, ze vyrobci se obvykle moc nesnazi dohodnout, tyhle standardy bud vymysli nekdo jiny nebo zacinaji jako "budme kompatibilni s tou a tou hotovou kartou" (treba dost dlouho byl takovy standard ISA soundblaster). Casem se to mozna zlepsi, ale porad zustane oblast veci co jsou moc novy nebo je vyrabi tak malo firem ze nemaji duvod se dohodnout.