printerd - tiskový démon nad D-Busem

Printerd je název nového projektu tiskového démona, který bude využívat PolicyKit a D-Bus. Projekt je zatím na úplném začátku, takže nejde o nic vhodného k produkčnímu nasazení. Mimo jiné aktuálně akceptuje jako vstup jen PDF dokumenty.

23.5.2012 13:27 | Luboš Doležel (Doli) | Zajímavý projekt

Komentáře

[kralyk z abclinuxu]

Co je špatného na CUPS?

[Zopper]

Netuším, taky jsem hledal nějaké "Oproti CUPS..." nebo "Toto umožní..." Napadá mě jen jedno: Používá CUPS dBus? Pokud ne, pak by mohlo být cílem prostě jen převést na dBus další věc.

[R]

Napriklad v tom, ze sa vystup z aplikacie x-krat skonvertuje, kym sa vytlaci. Aplikacia vyrobi z bitmapy postscript a posle CUPSu. CUPS to skonvertuje zase na bitmapu (ak tlaciaren tlaci bitmapy) alebo na PCL (ak tlaciaren tlaci PCL). Vykonom sa plytva, kvalita sa straca.

Ale pochybujem, ze prave toto bude printerd riesit...

[Lol Phirae]

Ale pochybujem, ze prave toto bude printerd riesit...

Jasně, že to řeší! Vyrobí z toho PDF, a z PDF vyrobí PS, který pošle na tiskárnu. Jooo a má to to supr dupr výhodu v integraci s tou nesmyslnou polkit srágorou.

[Miška]

• funguje
• nepouziva moderni cool veci jako D-Bus a policykit
• neintegruje se tak hezky do desktopovych klikatek
• ma moc malo obskurnich zavislosti

[Sten]

Nic. printerd je wrapper pro CUPS používající PolicyKit pro autorizaci. Alespoň tak jsem to pochopil.

[xkucf03]

Já to pochopil spíš tak, že Printerd použije ovladače z CUPSu, ale samotný CUPS tam nebudu muset mít, ne?

[Jirka]

Přesně tak. To co popisuje Sten dělá už dávno cups-pk-helper. Jedním z požadavků na printerd je integrace již existujících filtrů (gutenprint, HPLIP, různé konverze formátů něcotoněco). Jako spooler/IPP server už by tam ale nebyl CUPS ale printerd.

[Zopper]

Jestli jsem to z odkazované stránky dobře pochopil, tak ani není v plánu podporovat jiný vstup, než pdf... Možná někdy něco přidají, ale podle diskuze to nevypadá, že by plánovali. A rozhodně ne postscript.

[Jirka]

Pochopil jste to dobře, ale tento postscript-centrický přístup bude na Linuxu od cups-1.6.x minulostí tak jako tak. http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfasstandardprintjobformat

[Jirka]

První beta 1.6.x vyšla právě včera.

[----]

Další zbytečnost postavená na jiných zbytečnostech od freedesktop.org.

[kralyk z abclinuxu]

Ne všechno od freedesktop.org je špatně. Třeba Shared mime info db je imho dobrá věc... jen kdyby to DE rozumně respektovaly... Rozhodně je to lepší než file/libmagic.

Nebo např. Wayland, ten taky vypadá, že by mohl být v budoucnu fajn...

[----]

O Waylandu jsem mluvil s developerem, který naportoval na Wayland celý EFL, a prý je to taky bordel..

[l4m4]

Shared MIME info je dobrá věc, ale ne lepší než file, protože je to něco jiného než file.

[kralyk z abclinuxu]

Tak jasný, tím jsem měl na mysli tu část ohledně rozpoznávání souborů - v shared mime-info je tohle technicky dle mého názoru řešeno líp a taky dává spolehlivější výsledky, alespoň z mé zkušenosti.

[l4m4]

Tak s tím nemohu souhlasit. Coby někdo, kdo do jednoho programu implementoval detekci (a načítání) 80+ formátů souborů různé míry příčetnosti a obskurnosti, bych řekl, že expresivita detekčních výrazů v shared MIME info je tristní -- v podstatě se uchyluješ ke koncovkám, což když deset z těch formátů má koncovku .dat, taky není právě ono. Spoustu věcí nejde vyjádřit ani pomocí file magic, například typu ,tady by měla být délka souboru v bajtech minus 160`, ale je to o něco lepší např. díky indirekcím.

[kralyk z abclinuxu]

expresivita detekčních výrazů v shared MIME info je tristní -- v podstatě se uchyluješ ke koncovkám

Tak ta expresivita možná není dokonalá, ale ke koncovkám se uchylovat nemusíš.

S file/libmagic je spíš ten problém, že spousta věcí (hlavně pokročilejší náčítání informací z formátu) je tam prostě hardcodována. Např. ELF, ale i jiné. A multiplatformnost je taky hodně špatná - v podstatě bys to musel přepsat.

Jinak já měl například u file problém s matroškou. Polovinu matrošek, co mám na disku, není file schopen určit, zatímco shared MIME-magic nemá problém (bez přípony samozřejmě).

[l4m4]

Tak to se máme v F18 na co těšit ;)

[korro]

Bohužel ano.

Fedora je vysavač na všechny sračky, které se jen mihnou cyberprostorem. Existuje něco, co nikdo nechce a nikdo nepotřebuje? Šup s tím do Fedory....

[Pavel Stárek]

Na druhou stranu, nebýt Red Hatu 8 a posléze Fedory 1, tak dodnes by se používalo kódování 8859-2 a nikdo by nepřinutil autory přepsat či upravit programy pro podporu utf8 či unicode.

A není toto další projekt toho pána co vymyslel pulseaudio a systemd ?

[Tomáš Bžatek]

Neni.

[ukos]

dodnes by se používalo kódování 8859-2

Mně by to teda nevadilo. Unicode stejně používám asi jen v OO a FF. V teminálu mám stále ISO8859-2 a zbytek locales v C a vyhovuje mi to lépe než vícebajtové sady s tisíci obskurními znaky. Zunikódování celého systému včetně jmen souborů je mi přínosem asi jako doménová jména ve swahilštině.

[kralyk z abclinuxu]

Tak jasný, ono i s DOSem v poustevnické chatrči by se dalo nějak žít

[okko]

Když nemám argument, použiji dogmatický blábol, že ano.

Používáním kvalitních, jednoduchých a přiměřených nástrojů místo přearanžovaných módně vypadajících nedodělků bylo to, čím se Unix lišil od jiných systémů. Dnešní linuxové distribuce jsou směsí nedodělaných aplikací a totálně rozvrtaného zmrveného systému. To nemá s MS DOSem a chatrčí nic společného. Já raději pohodlnou chaloupku než praskající Prague Marina. (Nemohlo by být "Prague Marina" jméno další Fedory? Mělo by to hlubokou souvislost...)

[kralyk z abclinuxu]

Sorry, ale jaký je rozumný důvod použít místo utf-8 8859-2?

Dnešní linuxové distribuce jsou směsí nedodělaných aplikací a totálně rozvrtaného zmrveného systému.

A tohle jakože není dogmatický blábol? Meh...

[pavlix]

A tohle jakože není dogmatický blábol? Meh..

„Ale to je přece něco úplně jiného!“

[l4m4]

Zunikodování systému velké terno není, ale fungování např. standardních nástrojů s Unicode je fajn. Protože jakmile pracuji s textem, tak UTF-8. Vždyť 8859-2 neobsahuje ani české uvozovky.

[:::]

proboha, to ma kazdej jazyk svoje vlastni uvozovky ??

[Jindřich Makovička]

Ne, některé mají zas vlastní vykřičníky a otazníky :)

[pavlix]

Tak minimálně češi, angláni a francouzi používají každý jiné.

[xkucf03]

+1

[hydrandt]

Jsem vdecny za unicode standardne vsude. Pouzivam soucasne cestinu a cinstinu, diky bohu nemusim nejake kodovani resit.

[ukos]

vy používáte čínštinu v systému? Nechce se mi věřit.

[Šangala]

Já použiji někdy Hlaholici ve filesystému (je to ale spíš jen proto, „že můžu“).
Ale bez utf8-ka (či unicode obecně) si život nechci představit, odpadla tím spousta problémů…

[hydrandt]

Co je na tom tak neuveritelneho? Ucim se cinsky. Nebo formulace "v systemu" znamena nejake nizkourovnovejsi pouziti nez v uzivatelskem rozhrani?

[ukos]

Měl jsem na mysli unicode v textových konsolích a v terminálu - tj pro zadávání příkazů, zpracování jejich výstupů, pro zdrojové texty a programování, pro názvy souborů a adresářů a podobně. Všude tam je defaultní naroubování vícebajtových znaků většinou na obtíž. Samozřejmě nemluvím o aplikacích (textový procesor, mail klient, webový prohlížeč, ...), tam by měly být unicody samozřejmostí. Dle diskuse vidím, že se to blbě vysvětluje sotva zletilým windowsákům, kteří "přešli" na linux, protože je kůl.

Konec, offtopic

[xkucf03]

Mně přijdou háčky a čárky (a další znaky) v názvech souborů a jinde jako samozřejmost a jsem rád, že to můj OS zvládá. Nikomu to nenutím, kdo nechce, ať to nepoužívá, ale OS by to si s tím podle mého měl umět poradit.

Dle diskuse vidím, že se to blbě vysvětluje sotva zletilým windowsákům, kteří "přešli" na linux, protože je kůl.

Zrovna nedávno si mi někdo stěžoval, že nemůže ve Windows otevřít přílohu od někoho ze zahraničí (jednou tam byla azbuka, podruhé nějaké francouzské znaky). Resp. šlo mu to uložit na disk, ale otevřít už ne. V mém GNU/Linuxu s tím nebyl žádný problém, tak jsem mu ty soubory přejmenoval a poslal zpátky

[kralyk z abclinuxu]

+1, Windows je v tomhle 100 let za opicema.

[Ondrej 'SanTiago' Zajicek]

Zrovna Windows maji s timhle problemy zejm. proto, ze se snazi kodovani ve jmenech souboru resit, zatimco Linux to neresi (takze to ani moc nema kde selhat).

[kralyk z abclinuxu]

Hm, a jaká je definice "řeší to" vs "neřeší to"? Ve widlích v praxi existuje podivná dichotomie funkcí api, ovšem wide verze všeobecně používá málo lidí, díky čemuž jediné, co spolehlivě funguje, je local 8-bit kódování.

V Linuxu naproti tomu je utf-8 celkem univerzálně fungující.

[Ondrej 'SanTiago' Zajicek]

Linux (libc a jadro) proste vezme ten retezec jmena tak jak je (a tak ho bez konverze ulozi do FS) a jedine, co ho z nej zajima, je '/' a NULL zakonceni.

Oproti tomu Windows obecne ukladaji jmena tusim v UCS-2, takze jedine, co by mohlo spolehlive funguvat, je prave to wide-rozhrani, zatimco standardni funkce (ISO Cxx, POSIX) pouzivajici bezne stringy se povazuji za legacy a takto ziskane jmeno se prekonvertuje podle nastaveneho kodovani do Unicode a pak ulozi v UCS-2 (a naopak v opacnem smeru).

Vyhoda Windows pristupu je v tom, ze je na urovni FS jednoznacne dana interpretace jmena (narozdil od Linuxu, ktery je v tomhle ohledu agnosticky a interpretaci necha na userspace), nevyhoda je v tom, ze tam je spousta zbytecnych prekodovani, ktere prave vedou k tem problemum (napr. kdyz nekdo pomoci standardni funkce chce pristupovat k souboru, jehoz jmeno obsahuje znaky, ktere jsou mimo aktualni tabulku pouzivanou pro 8bit funkce).

[kralyk z abclinuxu]

Mně teda nepřijde moc dobrý nápad nějak standardizovat encoding ve FS nebo nějak limitovat podmínky pro jména souborů víc, než je nutné. Koneckonců, přesně tak to bylo i u FATxx, což je kořen všech problémů se jmény souborů na windows.

Co budou dělat, až přestane stačit UCS-2? Zas updatovat všade filesystém? Zlozvyky FATu se jim dodnes nepodařilo vymýtit...

[David Jaša]

V mém GNU/Linuxu s tím nebyl žádný problém, tak jsem mu ty soubory přejmenoval a poslal zpátky

Tak mi ukaž, jak v tom tvém linuxu rozbalíš .zip s názvy souborů v jiném kódování, než máš sám.

[Šangala]

No jo, ale na Win je zabalí Němec (DE widle) a Čechovi (CZ widle) to rozbalí a pak hlásí, že soubor neexistuje (bo je tam ß nebo co) - komukoliv dík, že na W7 už aspoň toto funguje.
„názvy souborů v jiném kódování“ název je posloupnost bytů a je logické aby byl v nějakém universálním kódování, tedy utf-8.
(A co teprve ten chaos při odesílání přílohy s některými názvy souborů na M$ produktech.)
Výzva: A ukaž tedy soubor, který v „tom mém“ Linuxu nerozbalím.

[kralyk z abclinuxu]

Čistě vycucaně z prstu mě napadá mount --bind + nastavit iocharset, ale vůbec nevim, jestli to je skutečně možný udělat.

Ale jinak určitě by se nějaký způsob našel.

[Ondrej 'SanTiago' Zajicek]

Pokud vim, tak iocharset a podobne options maji smysl pouze na windows-style filesystemech, nebot slouzi pro mapovani mezi windows-like pristupem a unix-like pristupem ke jmenum souboru.

[kralyk z abclinuxu]

No však to jsem měl na mysli. Předpokládal jsem, že je ten zip zabalen na widlích

Ale ono to stejně nejde, zkusil jsem to, a při bind se tyhle možnosti nenastaví.

Existuje ale mnohem jednodušší způsob: convmv.

[xkucf03]

To už je jiný problém – jedna věc je, když název souboru obsahuje různé „exotické“ znaky (jdou třeba zobrazit, ale systém s tím souborem neumí pracovat) a jiná věc je, když čeština v názvu souboru je „zmršená“ – tzn. došlo k chybě, ke ztrátě informace (vinou toho archivačního formátu) a ta posloupnost bajtů se interpretuje jinak, než bylo na druhé straně zamýšleno (což ten cílový OS nemůže vědět). Výsledkem jsou sice nějaké paznaky, ale pořád s tím jde (alespoň v mém OS) normálně pracovat – můžu takový soubor otevřít, přejmenovat nebo třeba smazat. A dá se to celkem snadno napravit a převést do čitelné podoby – např. programem convmv.

[Ondrej 'SanTiago' Zajicek]

Výsledkem jsou sice nějaké paznaky, ale pořád s tím jde (alespoň v mém OS) normálně pracovat – můžu takový soubor otevřít, přejmenovat nebo třeba smazat.

Zrovna ale tohle je problem, ktery je na Linuxu spojen s nastupem UTF-8. Zatimco u beznych osmibitovych kodovani s tim problem nebyl, nebot vicemene jakakoliv sekvence znaku byla vicemene korektni (tedy az na ruzne veci jako escape sekvence ve jmene, ale ty obvykle nicemu krome zobrazeni nevadily), tak u UTF-8 existuji nevalidni sekvence a nekterym programum prace s takovymi soubory dela dost vazne potize.

[Pavel Stárek]

No, tak to je bohužel tak trošku takový nemilá věc, která mne štve. Zabalím li ve Windows něco do zipu, a to něco obsahuje češtinu v názvech, je v Linuxu po žížalkách. Minimálně v konzoli. Ten FileRoller nebo co to je v Gnome to nějak už trošku umí, ale v Midnight Commanderu (který nejspíš používá unzip) to kolikrát nejde rozbalit.

[R]

To je problem samotneho ZIPu ako formatu, pretoze vobec neriesi kodovanie nazvov suborov. Takze vo Windows sa to tam nablije v tom, co ma pouzivatel nastavene (a nikde sa to do ZIPu nezaznamena). Ked to chces potom rozbalit, tak nevies, v akom je to kodovani...

[Ondrej 'SanTiago' Zajicek]

Mně přijdou háčky a čárky (a další znaky) v názvech souborů a jinde jako samozřejmost a jsem rád, že to můj OS zvládá. Nikomu to nenutím, kdo nechce, ať to nepoužívá, ale OS by to si s tím podle mého měl umět poradit.

No, v ramci jednoho systemu to jeste jde, ale jakmile takove soubory budes chtit tahat pres sit ci jinak prenaset mezi ruznymi systemy, tak narazis na znacne mnozstvi vice ci mene neresitelnych potizi (vychazejicich zejm. z odlisne koncepce mezi Windowsovym "jmeno souboru je posloupnost unicode znaku" a Unixovym "jmeno souboru je posloupnost bytu bez interpretace".

Coz v konecnem dusledku rika, ze jedine pragmaticke reseni je cokoliv jineho nez ASCII ve jmenech souboru nepouzivat.

[xkucf03]

No, v ramci jednoho systemu to jeste jde, ale jakmile takove soubory budes chtit tahat pres sit ci jinak prenaset mezi ruznymi systemy

Při těch přenosech po síti je to vyřešené celkem dobře, jsou na to standardy, RFCčka… je definované URL kódování, kódování příloh v e-mailech, příloh na webu (když se stahovaný soubor má uložit pod jiným názvem než je poslední část URL) atd.

Většinou to tedy funguje a když ne, tak to beru tak, že by se to mělo opravit (podle patřičného standardu) a ne že by se uživatel měl přizpůsobovat rozbité technice. Tak zbývají jen ty archivy a diskové oddíly…

Ale i v takovém ZIPu se kódování řeší:

Bit 11: Language encoding flag (EFS).  If this bit is set,
                  the filename and comment fields for this file
                  must be encoded using UTF-8. (see APPENDIX D)

takže by to fungovat mělo.

Unixovym "jmeno souboru je posloupnost bytu bez interpretace"

Tahle diskuse už tu jednou byla a tuším, že jsem psal něco v tom smyslu, že jména klidně můžou být posloupnost bajtů, ale ať je někde v metadatech daného oddílu napsané, jaké kódování se používá (aby si ho člověk nemusel pamatovat a psát ho jako parametr mount příkazu nebo do fstab).

[Ondrej 'SanTiago' Zajicek]

Při těch přenosech po síti je to vyřešené celkem dobře, jsou na to standardy, RFCčka

Je mnoho standardu, pro ktere rozsireni pro kodovani to snad nikdo nikdy nerozsiril, nebo se rozsireni neujalo. Napr. FTP nebo talk. Nebo standard existuje, ale konceptualni rozdily mezi OSy ho znemoznuji implementovat tak, aby tam nebyly problematicke okrajove pripady (to je treba pripad sitovych windows-like filesystemu a jejich podpore v Linuxu).

Tahle diskuse už tu jednou byla a tuším, že jsem psal něco v tom smyslu, že jména klidně můžou být posloupnost bajtů, ale ať je někde v metadatech daného oddílu napsané, jaké kódování se používá

Jenze prave v Linuxu kodovani nema vubec nic spolecneho s oddily, ale s procesy (a typicky s uzivateli). Neni neobvykle, kdyz na jednom oddilu je mnoho uzivatelu a kazdy pouziva jine kodovani (napr. u multiuzivatelskych sdilenych serveru, kam se lide obvykle prihlasuji pres SSH ze sveho domaciho stroje a pouzivaji tam tedy stejne kodovani jako doma).

Protoze v Linuxu je kodovani veci procesu, tak nelze rozumne implementovat serverove konce sitovych file-protokolu, ktere predavaji explicitne kodovana jmena souboru. Na klientske strane (napr. MUA pri posilani souboru e-mailem), tam klient kodovani zna, ale napr. SFTP server nema sanci zjistit, jake kodovani jmena soboru ma dany soubor (pokud odmyslim, ze by parsoval prihlasovaci shellove skripty daneho uzivatele).

A to ani nemluvim o pripadu, ze v Linuxu je korektni, aby byly v jednom adresari dva ruzne soubory, jejichz jmeno po prevodu do Unicode je stejne (napr. proto, ze kazdy je jineho uzivatele a oba pouzivai odlisne kodovani). Na tom se ti rozbije spousta encoding-aware sitovych protokolu. Nebo pripad, kdy na disku je soubor, jehoz jmeno vubec neni platnou UTF-8 sekvenci, i kdyz by jinak mel byt UTF-8 kodovany.

[Ondrej 'SanTiago' Zajicek]

ale napr. SFTP server nema sanci zjistit, jake kodovani jmena soboru ma dany soubor

Coz je, BTW, mozna taky duvod, proc soucasne OpenSSH implementuje jen SFTP verzi 2 (alespon co jsem se naposledy dival), ktera je jeste agnosticka co se tyce obsahu jmena souboru, zatimco novejsi verze uz predpoklada jednoznacnou interpretaci predavaneho jmena.

[xkucf03]

Z tvého komentáře mi spíš přijde, že používáš jen znaky z ASCII tabulky

[ukos]

většinou ano

[David Watzke]

Tady je nějaký vysvětlení.

[Kvakor]

Hmmm, lepší podopra stránkování (protože PDF je přirozeně stránkované), asynchornní komunikace (neblokující tiskové dialogy v GUI), již zmíněná podpora policykitu a v důsledku použití D-Busu možnost být spuštěn jen když se něco tiskne (což osobně dnes pokládám, vzhledem k paměťové rozežranosti dnesšních GUI, za téměř bezpředmětné). Navíc je to jen lokální spooler, podpora IPP (síťového tiskového protokolu) má být postavená na ním, komunikujíc skrz D-Bus.

[R]

Ta moznost, aby to zbytocne nebezalo, je asi jedina vec, co je na tom dobra. Ked clovek nepotrebuje mat zo svojho PC tlacovy server, tak by tam naozaj nemusel ziadny bezat.

[Saljack]

Mě běží cups na notebooku aby mohli všichni tisknout a ani není znát, že to běži. Takže je to opravdu irelevantní.

[Kvakor]

Ked clovek nepotrebuje mat zo svojho PC tlacovy server, tak by tam naozaj nemusel ziadny bezat.

printerd je jenom spooler, ne printserver.

[Jakub Lucký]

mám pocit, že to je nějaká skoro-poetteringovina....

[Jirka]

Ne, Lennart v tom tentokrát nejede. Původní idea přišla od lidí kolem GNOME. Ze začátku se mluvilo spíše o forku CUPS něž o úplném přepsání. O forknutí CUPS se mluvilo čím dál víc od doby, co se CUPS upstream začal zaměřoval jen na vlastnosti dobré pro OS X (což se začalo měnit po oficiálním oznámení printerd, ale možná, že to s tím nesouvisí). V současnosti je to spíš: "test, jak by Linuxový tiskový daemon vypadal, kdyby byl napsán dnes". Some benefits of printerd

[ukos]

Původní idea přišla od lidí kolem GNOME

To dává smysl. Ti už několikrát předvedli, že jsou zralí pro svěrací kazajku!

[David Watzke]