staging.inyokaproject.org

Ein Entwicklerkit der Linux Standard Base soll Treiberentwicklungen für die Hersteller vereinfachen und so mehr Linux-Unterstützung gewährleisten.

Wie Golem.de berichtet, veröffentlichte die LSB-Arbeitsgruppe der Linux-Foundation ein Driver Development Kit (DDK) genanntes Programm, das den Herstellern eine vereinfachte Entwicklung distributionsunabhängiger Druckertreiber für Linux ermöglicht. Das DDK wurde im Rahmen des OpenPrinting-Projekts erstellt, welches mit dem Ziel gegründet wurde, die Druckertreiberunterstützung unter Linux zu verbessern.

Leider werden die Treiber vorraussichtlich nur als RPM-Pakete verfügbar sein, so dass Ubuntuanwender diese mittels Alien in DEB-Pakete umwandeln müssen.

Ikhaya-Beitrag: Aussichten auf standardisierte Druckertreiber

Anmerkung: Diese Nachricht wurde von theredmonkey verfasst.

Hoffen wir doch mal sehr, dass dadurch diese GDI-Drucker nicht noch mehr gefördert werden. Ich finde bei Linux ist es einer der großen Vorteile, dass durch die freien Lizenzen, schon fast alles in der Distri ist, was man braucht.

*seinen pcl/postscript-Drucker streichelt*

Ist ein Treiber als RPM Paket nun ein "distributionsunabhängiger Druckertreiber für Linux"?

mfg qpid

Nach Meinung der LSB anscheinend schon, ist aber kein Ding sowas umzuwandeln. Die Pfade sind die LSB-Pfade und Abhängigkeiten gibt es ja eh nicht.

Ich kann mich nur Mark Shuttleworth anschließen: Es sollte nur noch ein Paketformat geben.

Nur ist Shuttleworth in der Hinsicht ein ziemlicher Pharisäer. Auf meine Frage hin, ob für Ubuntnu auch ein anderes Format als .deb in Frage kommt, hat er das kategorisch ausgeschlossen. Ich meine, man kann sich immer hinstellen und erzählen, dass es nur noch ein Format geben sollte, aber warum sollte RH zu .deb wechseln, wenn Ubuntu nicht bereit wäre zu .rpm zu wechseln, vorallem wenn er richtigerweise unterstreicht, dass das technisch kaum eine Rolle spielt?

adun hat geschrieben:

Nur ist Shuttleworth in der Hinsicht ein ziemlicher Pharisäer. Auf meine Frage hin, ob für Ubuntnu auch ein anderes Format als .deb in Frage kommt, hat er das kategorisch ausgeschlossen.

Das ist in der Tat ziemlich inkonsequent. Ist das Format heute überhaupt noch wichtig? Kann das Debian-Format irgendetwas, das RPM nicht kann oder umgekehrt? Ist doch letztlich ziemlich egal, wie die Dateiendung lautet und was sich "unter der Haube" abspielt.

nja...ich fass keine rpm's mehr an...und alien auch net...kp, das funzt nie (er wirft mir tausend fehlermeldungen und nix bringt mich weiter)...aber mein Epson DX6050 funzt ja...*streichel* sogar der Scanner der da mit drauf is...(als druckertreiber hab ich den 4050er genommen...und das ganze über localhost:631 eingerichtet) total einfach...beim Scannen musste ich allerdings (leider) hand anlegen...nja, schlussendlich funzt das ding *scanner-config datein nich mehr anfass*\^^

Doener hat geschrieben:

Das ist in der Tat ziemlich inkonsequent. Ist das Format heute überhaupt noch wichtig? Kann das Debian-Format irgendetwas, das RPM nicht kann oder umgekehrt? Ist doch letztlich ziemlich egal, wie die Dateiendung lautet und was sich "unter der Haube" abspielt.

rpm hat Deltapakete. Man kann also 'patches' für Pakete anbieten. Dafür gibt es für .debs die weit besseren Softwarelösungen. (Jaja, teilweise ist das auch Geschmackssache)
Die Strukturen, wie die Pakete gebaut werden sind eingefahren. Ehrlich gesagt glaube ich nicht an eine Vereinigung, die Lösung wäre sowas wie der openbuild Service von Novell. Nur nicht ausgerechnet von Novell... würde das ein unabhängiger Verein anbieten und zwar so, dass man es in den Buildprozess gut einbauen kann, wäre es das vielleicht.

adun hat geschrieben:

rpm hat Deltapakete. Man kann also 'patches' für Pakete anbieten. Dafür gibt es für .debs die weit besseren Softwarelösungen. (Jaja, teilweise ist das auch Geschmackssache)

Auch ich liebe apt-get und wollte darauf nicht verzichten. Aber könnte man apt-get und adept nicht einfach den Umgang mit RPM-Paketen beibringen? Alle erforderlichen Informationen wie Abhängigkeiten sind doch auch dort vorhanden, oder?

Doener: Schon allein aus dem Grund, dass es apt(4rpm) für SuSE gibt, ja...

mfg

Für separate distributionsunabhängige Pakete gibts schon http://autopackage.org

so ganz verstehe ich das aber nicht.
CUPS verwendet doch PPD (Postscript Printer Description) Dateien als Treiber.

Distributionsunabhängiger geht es doch gar nicht. Sogar Mac OS X verwendet CUPS und PPD.

Die sollten sich auch mal um Scanner kümmern, da fehlt noch eine entsprechende Vereinheitlichung.

TTinSB hat geschrieben:

so ganz verstehe ich das aber nicht.
CUPS verwendet doch PPD (Postscript Printer Description) Dateien als Treiber.

Distributionsunabhängiger geht es doch gar nicht. Sogar Mac OS X verwendet CUPS und PPD.

Die sollten sich auch mal um Scanner kümmern, da fehlt noch eine entsprechende Vereinheitlichung.

Meine Scannertreiber werden auch über cups geladen.

dgf hat geschrieben:

Hoffen wir doch mal sehr, dass dadurch diese GDI-Drucker nicht noch mehr gefördert werden. Ich finde bei Linux ist es einer der großen Vorteile, dass durch die freien Lizenzen, schon fast alles in der Distri ist, was man braucht.

Da stimme ich dir prinzipiell zu, doch leider nenne ich einen GDI-Drucker mein eigen (den einzigen aus dem Hause Kyocera leider), und muss seit dem immer über den Windows-Laptop meiner Freundin (bzw. mein eigenes noch existierendes Windows) drucken. Der Drucker ist noch recht neu, und bin (abgesehen natürlich vom riesigen GDI-Nachteil) sehr zufrieden damit (Funktionalität, Preis, Sparsamkeit, ...).

Ich hoffe, dass ein Linux-Treiber noch nachgereicht wird...