nixp.ru v3.0

24 октября 2017,
вторник,
12:40:50 MSK

DevOps с компанией «Флант»
23 мая 2012, 16:13

Представлен новый демон печати для Linux — printerd

4
Тим Вог и Ричард Хьюз
Тим Вог и Ричард Хьюз
Иллюстрация с сайта Desktopsummit.Org

Тим Вог (Tim Waugh) и Ричард Хьюз (Richard Hughes; автор colord) из компании Red Hat представили новый демон printerd, призванный стать «современным диспетчером очереди печати для Linux».

Демон printerd работает как служба, доступная через D-Bus, и поддерживает авторизацию через PolicyKit. При его создании активно использовались концепции IPP (Internet Printing Protocol), но printerd не стал IPP-сервером, зато может выступать в качестве обёртки для IPP-сервера. В качестве принимаемых форматов printerd будет поддерживать только PDF. Разработчики обещают совместимость printerd с существующими драйверами и бэкендами CUPS.

На данный момент в рамках проекта реализованы только базовый фреймворк и простая консольная утилита. Исходный код printerd распространяется под свободной лицензией GNU GPLv2 и опубликован на Gitorious.

Постоянная ссылка к новости: https://www.nixp.ru/news/11766.html. Дмитрий Шурупов по материалам Print Head.

fb twitter vk
yesint

«В качестве принимаемых форматов printerd будет поддерживать только PDF. » — эээ и как это должно работать если печатаешь, скажем, фотографию?

fhunter

Ну как-как? <sarcasm>Конвертируем фотографию в PDF… Зато гарантированно напечатается там где надо и как надо.</sarcasm>

Для полного извращения не хватает только посылки заданий через d-bus.

PS. А чем собственно cups/IPP был плох?

Дмитрий Шурупов

«The reasons for accepting only PDF are that PDF has a better model for shuffling pages around: each page is fully described separately from the others, unlike can often be the case in PostScript. This is important for printing only selected pages, or for putting several pages on a side (number-up). Applications generally produce PDF output for printing these days, so conversions from PostScript to PDF in the first place should be minimal.

There are several problems printerd aims to solve. Having an asynchronous client API is a start, and implementing the spooler as a D-Bus service does this as D-Bus automatically provides asynchronous client communications — this makes it easier to program UIs such as the print dialog in such a way that they do not block.

Another advantage printerd offers is a coherent security policy incorporating polkit. CUPS provides its own security policy mechanism, but the polkit mechanism is better suited to providing desktop integration. The way this is solved with CUPS is to provide an alternative security mechanism using polkit (cups-pk-helper), and this effectively bypasses the regular CUPS security policy. The result is that the two policy mechanisms are side by side, and if one prevents you doing what you want then you get to try the other.

In contrast, printerd’s only interface is D-Bus. It uses polkit to authenticate operations. If extra security policy is added in future that cannot be expressed using polkit (for instance, printer-specific policy rules) that extra policy layer will be in addition to polkit, not an alternative.

One more benefit of printerd is the idea of splitting the IPP server from the local spooler. Currently printerd only spools files and does not provide IPP services. The idea is that an IPP server can be implemented on top of printerd, using its D-Bus client API. That way, systems that want to print to local printers but are not interested in sharing those printers on the network don’t even have to run the IPP server. In fact, as printerd is an activatable system service, the spooler itself won’t even be running unless there is something for it to do.»

(комментарий Tim Waugh)

yesint

Хз, но у меня стойкое впечатление «починки того, что не ломалось». Ведь только-только стало все с печатью пучком в дистрибутивах, а сейчас снова зоопарк начнется — какая-то программа не сможет выводить в пдф, начнется неизбежный цирк с правами доступа и т.п. Плюс есть энное число принтеров с проприетарными дровами, которые если под линукс чудом есть, то, естественно, подразумевают установку под CUPS (намучался — знаю о чем говорю)…

А проблемы которые они хотят решить какие-то надуманные. Ну не так как-то асинхронность реализована. Оно мешает чем-то пользователю?

fhunter

У меня осталось именно такое же ощущение. Вместо того, чтобы чинить то, что сломано, ломают то, что нормально работает.

Плюс к этому, появляется не менее стойкое ощущение, что последовательно вырезают сетевую прозрачность в *nix.

Был X11. Прозрачный для сети и более менее работающий (а если бы создатели графических тулкитов читали документацию, то и по сети нормально работающий). В итоге мы идём к wayland. Который строго локален.

Теперь вот принтеры.

А с асинхронностью — похоже разработчики outlook из мира windows, не осилившие select, пришли в linux. Там тоже асинхронное взаимодействие с сетью не научились обрабатывать. Ну вот как можно затормозить на чтении почтового ящика, да так, что пока читается ящик — не обновляется окно программы?

yesint

Ага, промежуточная конверсия сильно повысит скорость и надежность всего этого добра. Кто пользовался ps2pdf знает какие перлы бывают, например с русскими буквами если со шрифтом какой-то косяк. А поскольку программы все равно выдавать будут постскрипт (ибо стандарт), то добрый день глюки.

fhunter

А поскольку ещё и принтеры будут принимать либо свой язык, либо postscript, ибо стандарт, то будет ещё веселее :)

Филипп Корвин

И я не совсем понял, зачем это нужно…

fantom_su

Имхо, существуют принтеры-постскрипт, и больше ничего не надо. Вин-принтеры — это от лукавого. ПДФ — формат распространённый, но добавлять промежуточный формат — это зря.

ecobeingecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.