Diese Klausel ist ja geradezu eine Aufforderung an die Druckerhersteller, Treiber exklusiv für MacOS zu entwickeln und zu lizensieren. Ich vermute ferner, dass Apple das Framework zukünftig mit tollen Exklusivfeatures erweitern wird, so dass es nur noch auf dem Papier plattformunabhängig ist.
Danke Apple, damit werden wir noch weniger Freie Treiber oder die Mitarbeit der Hersteller an solchen sehen, ich hoffe Sweep hat sich den Schritt ordentlich versilbern lassen, was ja sein gutes Recht ist. Was ich mich allerdings frage ist, ob Cups wirklich eine One-Man-Show war oder ob Apple die Zustimmung aller beteiligten Entwickler zu dieser GPL/LGPL-Verunstaltung eingeholt hat. Weiß da jemand näheres?
Ansonsten bleibt mir nur zu hoffen, dass sich findige Entwickler die mühsame Arbeit machen, sich in Cups einzuarbeiten und aus den letzten Freien Sourcen einen Fork erstellen. Das Drucksystem ist zu wichtig, als dass die verschiedenen Plattformen sich von der willkürlichen und sicherlich MacOS-zentrierten Weiterentwicklung abhängig machen können.
Dadurch wirds aber nicht unbedingt besser. Klar kann man, wenn ein Projekt einen anderen Weg einschlägt immer einen Fork anlegen, aber dabei bleiben immer einige Entwickler auf der Strecke und ein dezimiertes Team wird sich um den Fork kümmern. Dadurch wird die Entwicklung nicht unbedingt schneller vorangetrieben.
Allerdings glaube ich nicht, dass Apple CUPS so missbrauchen wird. Das wird imho alleine schon Sweet ausgeschlossen haben. Ich kann mir jedenfalls nicht vorstellen, das er "sein" Projekt so verkaufen würde. Schließlich stecken da Jahre Entwicklung drin!
Naja, kann man generell glaub ich nicht sagen. Im Fall von Xorg sehe ich den Fork durchaus positiv. Bei Cups - eine wichtige Komponente jeder Distribution - kann man auch davon ausgehen dass sie Distributoren durchaus hinter dem Fork stehen würden.
Bei Xorg sind ja auch die Core-Developer wie Keith Packard gewechselt. Bei CUPS weiß ich nicht, wie hoch der Anteil an Beiträgen außerhalb ESP war. CUPS war schließlich vollständig (C) ESP und ist jetzt zu 100% (C) Apple, Inc.
Mein erster Gedanke war ebenfalls, CUPS zu forken, nachdem Apple bereits Markenrechte an dem Namen angemeldet hat. Irgendwie läßt das ja schon nix Gutes für die Zukunft von CUPS erahnen...
Ich befürchte auch Schlimmes. Siehe Safari. Für den Browser hat Apple ordentlich bei khtml abgeschaut und dann die Änderungen nicht bzw. nur sehr zögerlich der Community zur Verfügung gestellt.
Sorry, was redest du für einen Bullshit! Das Problem KHTML vs. Webkit ist schon längst gegessen. Dank Apple ist Webkit da, wo es jetzt steht und trägt die ersten Früchte. Die QT-Abhängigkeiten sind auch weg... und ja, auch bei KDE denkt man drüber nach, auf Webkit umzusteigen.
Von papierlosesBüro am Do, 12. Juli 2007 um 15:49 #
Ich hab es sowieso nie verstanden, warum es Druckertreiber für Apple gibt, mit denen man unter Linux nichts anfangen kann... Warum ist 'Apple CUPS' nicht gleich 'Linux CUPS'?
Keine Ahnung, was du meinst, aber was soll Apple Cups sein? Ein Binärpaket? Das muss was anderes als ein Binärpaket für Linux sein, da die *BSDs ja für kompilierte Linux-Programme auch eine Linux-Emulation brauchen. Zumindest habe ich da mal was bei FreeBSD und der Linux-Flash-Variante gelesen.
Apple Cups ist das selbe wie Linux Cups. Es tut nichts weiter als die Druckaufträge zu sammeln und geordnet an den Drucker zu schicken. Die Druckaufträge kommen am Mac und unter Linux normaler Weise als Postscripts von den Programmen. Wenn dein Drucker Postscript spricht ist alles in Butter, dann kannst du die PostscriptPrinterDescription (aka PPD) vom Mac Treiber unter Linux bzw. die vom Linuxtreiber am Mac benutzen.
Da die meisten Tintenstrahler aber nunmal kein Postscript sprechen müssen die Daten erstmal übersetzt werden. Und das macht in dem Fall nicht Cups sondern ein externes Programm. So ein Programm ist z.B. Teil der Gimp/Gutenprint Treiber (die auch auf beiden Systemen laufen) oder der Herstellertreiber. Bei Herstellertreibern ist das natürlich so eine Sache, ob die auch Linuxtreiber veröffentlichen.
Es ist also nicht Apples Schuld. Zumal die Treibersituation unter Linux auch besser geworden ist, seit Apple auf Cups setzt.
Sehr lustig. Linux-Treiber gab es immer mehr als für MacOS X. Mit MacOsX gab es ja gerade einen Break mit vielen Geräten - und bei jedem Druckerhersteller konnte man lesen, das der Drucker leider unter Macos X nicht mehr läuft. Umgekehrt wird ein Schuh draus: Durch CUPS hat MacOS erst wieder Treiber bekommen. Ich habe das doch selber mit einem User erlebt, der sein System von 9 auf X upgegradet hatte und sich dann einen neuen Drucker kaufen musste, weil der alte Drucker obwohl noch einsatzfähig nicht mehr unterstützt wurde.
Der einzige Grund für diesen Schachzug ist die GPLv3. Da Apple CUPS benutzt und ausliefert, würden alle Patentrechtlichen GPLv3 Klauseln für sie zum Tragen kommen, sollte das freie Projekt CUPS auf diese wechseln. Oder aber Apple müßte beschließen, CUPS selbst zu forken und unter der alten Lizenz zu belassen, würden dann aber von den freien Entwicklern nur mehr eingeschrenkt profitieren.
Drum wohl dieser Schritt. Man wird sehen, bei welchen anderen Projekten sie diesen Schritt ebenfalls gehen werden.
war auch sofort mein Gedanke, dass es Apple dabei NUR darum gehen kann. Eine Lizenz für CUPS hatte man ja bereits schon, vom Copyright hat man nur die Kontrolle darüber, welche Lizenz es zukünftig sein kann.
Aber ansonsten, CUPS hin und her, Apple kann dem Projekt nur gut tun.
Verstehe ich das richtig sagt Apple in seinen Ausnahme-Klauseln (http://www.cups.org/articles.php?L179+I0+TFAQ+M10+P1+Q), dass wenn jemand Anwendungen für Apple-Systeme (OSX) schreibt und dabei irgendwas von CUPS nutzt, so ist das kein abgeleitetes Werk und die Sources müssen nicht veröffentlicht werden? Weiterhin heißt es doch diese Ausnahme gilt nur für Apple-Systeme? Habe ich das richtig verstanden?
Die Ausnahmeklausel gab es schon vorher: http://www.cups.org/articles.php?L178
Das hätte übrigens jeder Hersteller machen können, gegen eine entsprechende Zahlung an ESP versteht sich. Ist das gleiche Vorgehen wie bei Qt, MySQL und Co.
Meint ihr: "You may therefore distribute linked combinations of the CUPS imaging library with Apple OS-Developed Software without releasing the source code of the Apple OS-Developed Software"
Die BSB-Lizenz ist der ganz falsche Hinweis. Du darfst MacOS-Binaries releasen, die CUPS verwenden, ohne den Quellcode releasen zu müssen. Das ist für sich genommen etwa so gut (frei) wie die C-Runtime von MacOS. Die Erlaubnis zu linken und Binaries zu verteilen hat aber auch schon die LGPL, oder MS Visual Studio Runtimes, etc.
Meint ihr: "You may therefore distribute linked combinations of the CUPS imaging library with Apple OS-Developed Software without releasing the source code of the Apple OS-Developed Software" Ich meine "...shall not be considered to be a derivative work..."
Die Erlaubnis zu linken und Binaries zu verteilen hat aber auch schon die LGPL, oder MS Visual Studio Runtimes, etc. Nein, im Falle der LGPL ist ausschließlich dynamisches Linken erlaubt. Der LGPL-Teil muss also in einer separaten Datei stecken. Wenn aber die Software nicht mehr als abgeleitetes Werk gilt, darfst du auch statisch linken.
eigentlich sogar noch schlechter, denn sie kapseln sich noch mehr ab. Ob Jobs oder Gates... beide nehmen sich nichts. Und Apple würde mit genauso harten Methoden operieren, wenn sie diese Marktmacht hätten, die MS nun mal hat. Jedenfalls schwant mir nichts Gutes. Mir wäre es viel lieber, es würde einen Fork geben und das Drucksystem bleibt frei. BTW... hat Apple schon mal was gutes für die OS-Community zur Verfügung gestellt?
Apple bezahlt jetzt die CUPS-Entwickler, was ist daran verwerflich? Ist doch besser als wenn die Entwickler ein Projekt einstellen, weil sie kein Geld zum Leben haben, was schon vorgekommen ist. Wo ist das Problem? Wenn Apple etwas mit Cups macht, was dir nicht gefällt kannst du doch jederzeit einen Fork davon weiter entwickeln. Und Webkit ist frei und davon profitiert auch KDE.
Wieso werden die verarscht? Macs sind top. Und so produktiv wie mit einem Mac war ich in 3 Jahren Linux-Nutzung (und etlichen Jahren Windowsnutzung) nicht gewesen. Fast alles läuft out-of-the-box. Bis ich mal mein Bluetoothhandy unter Linux zum laufen gebracht hatte...
Die Leute von Apple habens auch um einiges leichter. Ein Mac-System muss auf einer (einer kleinen Auswahl an) Hardware laufen. Da kann dann auch alles "out of the box" funktionieren, wäre auch traurig wenn das nicht so wäre. Es ist nichts Verwerfliches an dieser Strategie, man sollte diesen Vorteil einfach nicht vergessen.
seier seier blah. steck dir deine 'produktivitaet' dahin wo die sonne nich scheint und geh den kragen deines pullis aufrollen. hier geht es um _BRAUCHBARKEIT_, nicht um 'produktivitaet. apple ist unbrauchbar und damit hat der OT recht.
Naja, dann lassen sich aber viele Leute sehr gerne veraschen, inkl. einem nicht unbeträchtlichen Teil der kompletten Marketing und Design Industrie (dabei sollten die doch echt Ahnung vom Verarschen und Verarscht Werden haben....)
Ich kenne viele Leute, die mit MacOS X komplett zufrieden und glücklich sind. Ich bin es mit meinem iPod auch. Wie ebenfalls ne ganze Menge Leute. Ich weiß nicht, ich glaube, du weißt nicht genau, wovon du sprichst...
Apple bedient intellektuellen, elitaeren Duenkel. Wer einen Mac hat, ist furchtbar kreativ, produktiv und individuell. Gekauft wird das Image und nicht die Technik (von der verstehen die Grafik- und Marketingfuzzies doch sowieso nix, Hauptsache das Ding sieht schoen stylish aus).
schön dass man neben den ganzen unqualifizierten Kommentaren, von Ihnen noch einen nüchternen und sachlichen Überblick bekommt. Sie vergaßen allerdings zu erwähnen, dass die sexuelle Ausrichtung des intellektuellen und elitären Dünkels ja vorwiegend gleichgeschlechtlich ist.
Von Sierk Bornemann am Fr, 13. Juli 2007 um 18:23 #
Eigenartig nur, dass es nicht wenige (Hardcore-)Linux-Programmierer gibt, die auf irgendwelchen Konferenzen, wo man sie mal in der Öffentlichkeit erblickt, mit MacBooks herumlaufen und es eingefleischte alte UNIX-Veteranen und -Hasen gibt, die begeistert sind von MacOSX und nicht selten ebenfalls Apples Hardware ihr eigen nennen...
Irgendwie scheint das Bild, was Du versuchst zu zeichnen, nicht ganz stimmig zu sein...
>Und Webkit ist frei und davon profitiert auch KDE.
Ich liebe dieses Argument. Es ignoriert die Tatsache dass viele KDE-Entwickler unzufrieden sind mit Apple's Webkit und dieses wegen Ungereimtheiten Probleme bei der Implementierung macht etc.
Was fuer Ungereimtheiten? Ist Webkit frei? Ja! Ist Webkit eine Weiterentwicklung und Verbesserung gegenueber KHTML? Ja! Die Streitigkeiten sind schon lange beigelegt. Wo ist das Problem?
Ich weiß auch nicht, wo das Problem sein soll - die (L)GPL von KHTML erlaubt exakt dieses Verhalten: Verwenden, Modifikationen den Anwendern freigeben. Von "hilf, Deine Änderungen möglichst gut in das Ursprungsprodukt zu integrieren" oder "behalte die Portierbarkeit auch in Deinen Modifikationen bei und kommentiere sie leserlich, damit andere es reintegrieren können" redet die (L)GPL gottseidank nicht.
da hast Du vollkommen recht. Das Problem war aber dann doch, dass die Entwickler eben doch mehr wollten als die Lizenz verlangte und ihrer Unzufriedenheit weitreichend Luft gemacht haben. Es ging da auch um Ehre.
Wer Mozilla und sein Desaster Gecko-Entwicklung verfolgt hatte, dem war klar was für eine geniale Leistung KHTML war. Und dann kam Apple gerade rechtzeitig, um als erster etwa den wichtigen ACID-Test zu bestehen, und besagte Entwicklern wurde immer öften nur noch gesagt "ihr müsst das doch nur von Apple mergen, die sind toll, die können das, und ihr habt das _immer_ _noch_ nicht gemerged.".
Egal wie die Lizenz lautet, die Entlohnung für FOSS-Entwickler ist oft auch nur das positive Feedback, der Ruhm, der persönliche Erfolg, etwas verändert zu haben. Apple hatte das für einige Zeit (auf Dauer) den Leuten kaputt gemacht.
Daran war nichts Böses oder so. Nicht falsch verstehen. Am Ende hat Apple ja auch nur nicht klar genug verstanden, dass die KDE-Entwickler tatsächlich eine gemeinsame Arbeit wollen.
Andere Beispiele für Forks, wo die Entwickler aufgeregt waren:
GPL-Beryl aus BSD-Compiz (schon geklärt, wieder gemerged, aber das Lizenz-Downgrade galt als sehr unfein).
Closed Source Cedega aus BSD-Wine (dass dann LGPL wurde). Weil eine Firma erfolgreich die BSD-Lizenz nutzte, eine andere sich kooperativer verhielt, hat die Community sich entschieden, die Lizenz zu wählen, die das nicht-kooperieren unmöglich macht.
Linux mit Closed Source Modulen. Nicht wenige Kernel-Entwickler haben verschiedenste Vorstellungen gehabt, ob ihre Lizenz es erlaubt oder nicht. Das löst sich gerade, weil der Konsens (?) zunimmt, diese Module zurückzudrängen (unpraktisch zu machen).
Das infantile Gesicht von opensource "mach halt nen Fork". Als ob jeder willige Nasenbär den originalen Entwickler gleich gut bzw. überhaupt ersetzen könnte.
nun, wenn es so ein himmelschreiendes Problem ist, wenn Appöe cups nun gekauft hat, dass man einfach nicht damit leben kann, dann wird sich schon ein fähiger Entwickler finden, der das macht
Wie kann Apple das eigentlich so einfach kaufen? Wurde CUPS nur von einem einzelnen geschrieben, oder haben alle, die ein Stückchen beigetragen haben, ihre Zustimmung gegeben?
Das Copyright an CUPS gehörte nicht einer Person, sondern dem Unternehmen Easy Software Products. Und jeder, der Code beitragen wollte, musste die Verwertungsrechte abgeben. Ist bei Qt und MySQL genauso. Sonst wäre die Dual-Lizenzierung auch nicht so einfach möglich.
Steve Jobs, der sich mit seinem Applespielzeug als grosser Imperator präsentiert wird zum grossen Gönner? Wohl kaum? Einer der nach imperialistischen Gesichtspunkten seine Marktstrategien fährt hat nur eines im Sinn, nichts Gutes!!!! Auf wiedersehen CUPS!!!!! Welcome Icups
Ahnung für sich hätte man auch Hoffnung mitbringen können: In der Form, dass zukünftig die Druckerhersteller nur noch Treiber für Win und eben Cups (Linux & Mac) herausbringen. Damit wäre für jeden Drucker ein Linux Treiber sichergestellt.
Leider machen sich aber diverse Kommentatoren wohl zu recht Sorgen. Apple ist nicht gerade ein Unterstützer der OpenSource Philosophie was der Release von Safari unter Windows gezeigt hat. (Hier will man langfristig ein Duopol aus MSIE und Safari; Firefox soll es zukünftig nicht mehr geben lt. Apples Zukunftsvision)
Ich hoffe, dass sich bald ein Fork herauskristallisiert der weltweit anerkannt und auch von der Industrie unterstützt wird.
> Firefox soll es zukünftig nicht mehr geben lt. Apples Zukunftsvision Apples "Zukunftsvision" (das zweite Kuchendiagram im Vortrag) sollte lediglich illustrieren, wie sich IE und Safari Jobs Meinung nach entwickeln werden/sollen. Dabei ist es akzeptabel, ein Kuchendiagramm zu verwenden, welches sich lediglich auf die summierten Marktanteile dieser beiden bezieht.
Ich verstehe euch nicht ganz. Wir leben in einer Kapitalistischen Welt und Menschen machen aus Dingen Geld. Jede Firma handelt so und es gibt keine Ausnahmen. Man kann sich jetzt darüber aufregen ein Lebenlang oder die Tatsache akzeptieren... das Beste daraus machen.
Ich nutze selber Linux seit Jahren, hab nen iMac und einen Windows Rechner. Jeden nutz ich dort, wo er am meisten bringt. Und der Mac ist definitv das beste was ich seit langem gesehen hab Unix Userfriendly zu machen, haben bis jetzt nur die Apple Leute geschafft - Hut ab!
Ist ja auch nicht weiter verwunderlich. Denn CUPS wurde über die ganzen Jahre so "verkauft", als ob es zwangsläufig mit Druckertreibern einhergeht. Bedingt war es ja auch so: Mit Einführung von CUPS waren plötzlich erheblich mehr Druckertreiber vorhanden als vorher beim lpd. Und diese Tatsache verursachte bei den meisten Usern den Eindruck, nur mit CUPS wären vernünftige Druckertreiber vorhanden.
...bewährte Alternative: den sehr guten grundsoliden LPD.
Ich habe in der Vergangenheit sowieso nicht so recht verstanden, warum man wg. der tatsächlich vorhandenen Treiberproblematik gleich eine neue Druckerkonzeption erstellen muß. Der LPD ist mit seiner /etc/printcap mindestens genauso flexibel wie CUPS, nur wesentlich unkomplizierter und in seiner Struktur durchschaubarer. Vielleicht gibt eine eventuelle Verschlechterung von CUPS aus Sicht von freier Software dem LPD neue Chancen. Die Filter sind ja schon vorhanden, und diese lassen sich über /etc/printcap einbinden. Auch Rechteverwaltung ist mit dem LPD in Gestalt von lprng möglich. Eigentlich kommt es sogar noch besser mit lprng: Ein Client, der nicht als Druckerserver fungieren soll, braucht noch nicht einmal den lpd laufen zu lassen. Ein lpr -PPrintqueue@hostname macht es möglich. Effizienter geht es kaum noch. Ich finde, dagegen sieht CUPS dann ziemlich aufgebläht und blaß aus.
Ab einer gewissen Größenordnung und Druckvielfalt, pfeifst Du auf lpold, lpsched, lprng und wie sich die Dinger sonst noch nennen.
Außerdem gibt es einige exclusive Features, welche den anderen fehlen: *) Browsing *) Verwendung von PPDs *) Die meisten administrativen Tätigkeiten erfordern keinen Neustart des Dienstes *) Implicit Classes, etc.
Auf diverse Hänger und Performaceprobleme bei anderen Spoolern, welche seit Jahren nicht gefixt wurden, brauche ich nicht hinzuweisen, oder? Erleben wir ja all, daß bei 20 Druckern der lpstat unter Umständen gleich mal 1-2 Minuten benötigt (wie sieht das erst bei 300 Druckern aus!).
Aber was heute in diesem Forum abgeht, gehört eigentlich nicht auf PL sondern zu heise.
Meiner Meinung nach leistet Mike nach wie vor großartige Arbeit! Und bis auf ein paar Textstellen im Code hat sich eigentliche wenig geändert, was dem Einfluß von Apple oder sonstwem zuzuschreiben wäre.
OT: Bis zur Veröffentlichung von 1.3 ist es nicht mehr weit!
"Erleben wir ja all, daß bei 20 Druckern der lpstat unter Umständen gleich mal 1-2 Minuten benötigt".
Zu lpstat kann ich nichts sagen. Lpstat gehört zum SYS V Printingsystem. Für den LPD kann ich das nicht bestätigen, im Gegensatz zu CUPS. Ich habe in unterschiedlichen Unternehmen jedesmal erlebt, daß ein Drucken mit CUPS einem Drama gleichkommt (so nach dem Motto Geht's oder geht's nicht oder heute Abend kannst Du Dir den Druck abholen), während der LPD einfach nur so flutschte. Oder auch das Abbrechen eines Druckjobs mit Windowsrechnern. Bei Cups unmöglich, mit dem lpr Client und dem Druckspooler von Windows kein Problem, solange der Druckjob dem User gehörte.
Auch das Browsing funktioniert nur im selben Netzwerksegment, ist also nicht routingfähig. Oder hat sich mittlerweile da was geändert?. Insofern ist dieses gute Feature nur beschränkt einsetzbar.
Die Funktionsweise der Jobverwaltung zwischen Windows und CUPS habe ich noch nicht probiert, daher kann ich dazu nicht viel sagen.
Die Probleme bei CUPS lassen sich meistens auf fehlerhafte Patches des jeweiligen Distributors zurückführen. --> das kann man aber CUPS nicht anlasten, zumindest wäre dies kein fairer Vergleich Unsere selbst erstellten Pakete für Linux/Unix hatten bisher kaum Kinderkrankheiten.
Browsing mit Broadcasts ist auf ein Netzwerksegment beschränkt. Da es aber bereits seit der allerersten Version von CUPS Funktionen fürs Relaying und Polling gibt, stimmt Deine Aussage zur Gänze nicht. Seit CUPS 1.2 werden weitere Protokolle fürs Browsing unterstützt (auch wenn sich etliche eher noch im Experimentierstadium befinden)
Diese Klausel ist ja geradezu eine Aufforderung an die Druckerhersteller, Treiber exklusiv für MacOS zu entwickeln und zu lizensieren. Ich vermute ferner, dass Apple das Framework zukünftig mit tollen Exklusivfeatures erweitern wird, so dass es nur noch auf dem Papier plattformunabhängig ist.
Danke Apple, damit werden wir noch weniger Freie Treiber oder die Mitarbeit der Hersteller an solchen sehen, ich hoffe Sweep hat sich den Schritt ordentlich versilbern lassen, was ja sein gutes Recht ist. Was ich mich allerdings frage ist, ob Cups wirklich eine One-Man-Show war oder ob Apple die Zustimmung aller beteiligten Entwickler zu dieser GPL/LGPL-Verunstaltung eingeholt hat. Weiß da jemand näheres?
Ansonsten bleibt mir nur zu hoffen, dass sich findige Entwickler die mühsame Arbeit machen, sich in Cups einzuarbeiten und aus den letzten Freien Sourcen einen Fork erstellen. Das Drucksystem ist zu wichtig, als dass die verschiedenen Plattformen sich von der willkürlichen und sicherlich MacOS-zentrierten Weiterentwicklung abhängig machen können.
Allerdings glaube ich nicht, dass Apple CUPS so missbrauchen wird. Das wird imho alleine schon Sweet ausgeschlossen haben. Ich kann mir jedenfalls nicht vorstellen, das er "sein" Projekt so verkaufen würde. Schließlich stecken da Jahre Entwicklung drin!
Naja, kann man generell glaub ich nicht sagen. Im Fall von Xorg sehe ich den Fork durchaus positiv. Bei Cups - eine wichtige Komponente jeder Distribution - kann man auch davon ausgehen dass sie Distributoren durchaus hinter dem Fork stehen würden.
Bei CUPS weiß ich nicht, wie hoch der Anteil an Beiträgen außerhalb ESP war. CUPS war schließlich vollständig (C) ESP und ist jetzt zu 100% (C) Apple, Inc.
Irgendwie läßt das ja schon nix Gutes für die Zukunft von CUPS erahnen...
Das muss was anderes als ein Binärpaket für Linux sein, da die *BSDs ja für kompilierte Linux-Programme auch eine Linux-Emulation brauchen.
Zumindest habe ich da mal was bei FreeBSD und der Linux-Flash-Variante gelesen.
cu
Drucker Postscript spricht ist alles in Butter, dann kannst du die PostscriptPrinterDescription (aka PPD) vom Mac Treiber unter Linux bzw. die vom Linuxtreiber am Mac benutzen.
Da die meisten Tintenstrahler aber nunmal kein Postscript sprechen müssen die Daten erstmal übersetzt werden. Und das macht in dem
Fall nicht Cups sondern ein externes Programm. So ein Programm ist z.B. Teil der Gimp/Gutenprint Treiber (die auch auf beiden Systemen laufen) oder der Herstellertreiber. Bei Herstellertreibern ist das natürlich so eine Sache, ob die auch Linuxtreiber veröffentlichen.
Es ist also nicht Apples Schuld. Zumal die Treibersituation unter Linux auch besser geworden ist, seit Apple auf Cups setzt.
Belegen oder besser schweigen, sage ich nur.
Keine Peilung von gar nichts, aber groß rummaulen!
Apple machts!!!
Drum wohl dieser Schritt. Man wird sehen, bei welchen anderen Projekten sie diesen Schritt ebenfalls gehen werden.
war auch sofort mein Gedanke, dass es Apple dabei NUR darum gehen kann. Eine Lizenz für CUPS hatte man ja bereits schon, vom Copyright hat man nur die Kontrolle darüber, welche Lizenz es zukünftig sein kann.
Aber ansonsten, CUPS hin und her, Apple kann dem Projekt nur gut tun.
Gruß,
Kay
http://www.cups.org/articles.php?L178
Das hätte übrigens jeder Hersteller machen können, gegen eine entsprechende Zahlung an ESP versteht sich. Ist das gleiche Vorgehen wie bei Qt, MySQL und Co.
Die BSB-Lizenz ist der ganz falsche Hinweis. Du darfst MacOS-Binaries releasen, die CUPS verwenden, ohne den Quellcode releasen zu müssen. Das ist für sich genommen etwa so gut (frei) wie die C-Runtime von MacOS. Die Erlaubnis zu linken und Binaries zu verteilen hat aber auch schon die LGPL, oder MS Visual Studio Runtimes, etc.
Gruß,
Kay
Ich meine "...shall not be considered to be a derivative work..."
Die Erlaubnis zu linken und Binaries zu verteilen hat aber auch schon die LGPL, oder MS Visual Studio Runtimes, etc.
Nein, im Falle der LGPL ist ausschließlich dynamisches Linken erlaubt. Der LGPL-Teil muss also in einer separaten Datei stecken.
Wenn aber die Software nicht mehr als abgeleitetes Werk gilt, darfst du auch statisch linken.
Jedenfalls schwant mir nichts Gutes. Mir wäre es viel lieber, es würde einen Fork geben und das Drucksystem bleibt frei.
BTW... hat Apple schon mal was gutes für die OS-Community zur Verfügung gestellt?
Ich kenne viele Leute, die mit MacOS X komplett zufrieden und glücklich sind. Ich bin es mit meinem iPod auch. Wie ebenfalls ne ganze Menge Leute. Ich weiß nicht, ich glaube, du weißt nicht genau, wovon du sprichst...
Warum sollen die Produkte besser werden, wenn Rechtschreibung und Zeichensetzung auch von Generation zu Generation schlechter werden?
schön dass man neben den ganzen unqualifizierten Kommentaren, von Ihnen noch einen nüchternen und sachlichen Überblick bekommt. Sie vergaßen allerdings zu erwähnen, dass die sexuelle Ausrichtung des intellektuellen und elitären Dünkels ja vorwiegend gleichgeschlechtlich ist.
mfg
Dr. Korrekter Zeichensatz
Irgendwie scheint das Bild, was Du versuchst zu zeichnen, nicht ganz stimmig zu sein...
Ich liebe dieses Argument.
Es ignoriert die Tatsache dass viele KDE-Entwickler unzufrieden sind mit Apple's Webkit und dieses wegen Ungereimtheiten Probleme bei der Implementierung macht etc.
lg
Erik
da hast Du vollkommen recht. Das Problem war aber dann doch, dass die Entwickler eben doch mehr wollten als die Lizenz verlangte und ihrer Unzufriedenheit weitreichend Luft gemacht haben. Es ging da auch um Ehre.
Wer Mozilla und sein Desaster Gecko-Entwicklung verfolgt hatte, dem war klar was für eine geniale Leistung KHTML war. Und dann kam Apple gerade rechtzeitig, um als erster etwa den wichtigen ACID-Test zu bestehen, und besagte Entwicklern wurde immer öften nur noch gesagt "ihr müsst das doch nur von Apple mergen, die sind toll, die können das, und ihr habt das _immer_ _noch_ nicht gemerged.".
Egal wie die Lizenz lautet, die Entlohnung für FOSS-Entwickler ist oft auch nur das positive Feedback, der Ruhm, der persönliche Erfolg, etwas verändert zu haben. Apple hatte das für einige Zeit (auf Dauer) den Leuten kaputt gemacht.
Daran war nichts Böses oder so. Nicht falsch verstehen. Am Ende hat Apple ja auch nur nicht klar genug verstanden, dass die KDE-Entwickler tatsächlich eine gemeinsame Arbeit wollen.
Andere Beispiele für Forks, wo die Entwickler aufgeregt waren:
GPL-Beryl aus BSD-Compiz (schon geklärt, wieder gemerged, aber das Lizenz-Downgrade galt als sehr unfein).
Closed Source Cedega aus BSD-Wine (dass dann LGPL wurde). Weil eine Firma erfolgreich die BSD-Lizenz nutzte, eine andere sich kooperativer verhielt, hat die Community sich entschieden, die Lizenz zu wählen, die das nicht-kooperieren unmöglich macht.
Linux mit Closed Source Modulen. Nicht wenige Kernel-Entwickler haben verschiedenste Vorstellungen gehabt, ob ihre Lizenz es erlaubt oder nicht. Das löst sich gerade, weil der Konsens (?) zunimmt, diese Module zurückzudrängen (unpraktisch zu machen).
Gruß, Kay
Und jeder, der Code beitragen wollte, musste die Verwertungsrechte abgeben. Ist bei Qt und MySQL genauso. Sonst wäre die Dual-Lizenzierung auch nicht so einfach möglich.
wird zum grossen Gönner? Wohl kaum?
Einer der nach imperialistischen Gesichtspunkten seine Marktstrategien fährt
hat nur eines im Sinn, nichts Gutes!!!!
Auf wiedersehen CUPS!!!!!
Welcome Icups
Ahnung für sich hätte man auch Hoffnung mitbringen können: In der Form, dass zukünftig die Druckerhersteller nur noch Treiber für Win und eben Cups (Linux & Mac) herausbringen. Damit wäre für jeden Drucker ein Linux Treiber sichergestellt.
Leider machen sich aber diverse Kommentatoren wohl zu recht Sorgen. Apple ist nicht gerade ein Unterstützer der OpenSource Philosophie was der Release von Safari unter Windows gezeigt hat. (Hier will man langfristig ein Duopol aus MSIE und Safari; Firefox soll es zukünftig nicht mehr geben lt. Apples Zukunftsvision)
Ich hoffe, dass sich bald ein Fork herauskristallisiert der weltweit anerkannt und auch von der Industrie unterstützt wird.
"Good for you, bad for everyone else."
Apples "Zukunftsvision" (das zweite Kuchendiagram im Vortrag) sollte lediglich illustrieren, wie sich IE und Safari Jobs Meinung nach entwickeln werden/sollen. Dabei ist es akzeptabel, ein Kuchendiagramm zu verwenden, welches sich lediglich auf die summierten Marktanteile dieser beiden bezieht.
lg
Erik
Ich nutze selber Linux seit Jahren, hab nen iMac und einen Windows Rechner. Jeden nutz ich dort, wo er am meisten bringt. Und der Mac ist definitv das beste was ich seit langem gesehen hab
Unix Userfriendly zu machen, haben bis jetzt nur die Apple Leute geschafft - Hut ab!
lg
Erik
Wenn das bisher alle Menschen so gesehen hätten, gäbe es heute weder Flugzeuge noch Computer, oder sonstige Errungenschaften.
Viele verstehen anscheinend nicht, daß es sich hier um ein Druckerframework und nicht um die Druckertreiber handelt.
Daher hat das Ganze auch ziemlich wenig Auswirkung auf die Druckerhersteller, denn diese haben sich gefälligst an die LSB zu halten!
Ist ja auch nicht weiter verwunderlich. Denn CUPS wurde über die ganzen Jahre so "verkauft", als ob es zwangsläufig mit Druckertreibern einhergeht. Bedingt war es ja auch so: Mit Einführung von CUPS waren plötzlich erheblich mehr Druckertreiber vorhanden als vorher beim lpd. Und diese Tatsache verursachte bei den meisten Usern den Eindruck, nur mit CUPS wären vernünftige Druckertreiber vorhanden.
Ich habe in der Vergangenheit sowieso nicht so recht verstanden, warum man wg. der tatsächlich vorhandenen Treiberproblematik gleich eine neue Druckerkonzeption erstellen muß. Der LPD ist mit seiner /etc/printcap mindestens genauso flexibel wie CUPS, nur wesentlich unkomplizierter und in seiner Struktur durchschaubarer. Vielleicht gibt eine eventuelle Verschlechterung von CUPS aus Sicht von freier Software dem LPD neue Chancen. Die Filter sind ja schon vorhanden, und diese lassen sich über /etc/printcap einbinden. Auch Rechteverwaltung ist mit dem LPD in Gestalt von lprng möglich. Eigentlich kommt es sogar noch besser mit lprng: Ein Client, der nicht als Druckerserver fungieren soll, braucht noch nicht einmal den lpd laufen zu lassen. Ein lpr -PPrintqueue@hostname macht es möglich. Effizienter geht es kaum noch. Ich finde, dagegen sieht CUPS dann ziemlich aufgebläht und blaß aus.
Außerdem gibt es einige exclusive Features, welche den anderen fehlen:
*) Browsing
*) Verwendung von PPDs
*) Die meisten administrativen Tätigkeiten erfordern keinen Neustart des Dienstes
*) Implicit Classes, etc.
Auf diverse Hänger und Performaceprobleme bei anderen Spoolern, welche seit Jahren nicht gefixt wurden, brauche ich nicht hinzuweisen, oder? Erleben wir ja all, daß bei 20 Druckern der lpstat unter Umständen gleich mal 1-2 Minuten benötigt (wie sieht das erst bei 300 Druckern aus!).
Aber was heute in diesem Forum abgeht, gehört eigentlich nicht auf PL sondern zu heise.
Meiner Meinung nach leistet Mike nach wie vor großartige Arbeit! Und bis auf ein paar Textstellen im Code hat sich eigentliche wenig geändert, was dem Einfluß von Apple oder sonstwem zuzuschreiben wäre.
OT: Bis zur Veröffentlichung von 1.3 ist es nicht mehr weit!
mfg
unreal
Zu lpstat kann ich nichts sagen. Lpstat gehört zum SYS V Printingsystem. Für den LPD kann ich das nicht bestätigen, im Gegensatz zu CUPS. Ich habe in unterschiedlichen Unternehmen jedesmal erlebt, daß ein Drucken mit CUPS einem Drama gleichkommt (so nach dem Motto Geht's oder geht's nicht oder heute Abend kannst Du Dir den Druck abholen), während der LPD einfach nur so flutschte. Oder auch das Abbrechen eines Druckjobs mit Windowsrechnern. Bei Cups unmöglich, mit dem lpr Client und dem Druckspooler von Windows kein Problem, solange der Druckjob dem User gehörte.
Auch das Browsing funktioniert nur im selben Netzwerksegment, ist also nicht routingfähig. Oder hat sich mittlerweile da was geändert?. Insofern ist dieses gute Feature nur beschränkt einsetzbar.
Die Probleme bei CUPS lassen sich meistens auf fehlerhafte Patches des jeweiligen Distributors zurückführen. --> das kann man aber CUPS nicht anlasten, zumindest wäre dies kein fairer Vergleich
Unsere selbst erstellten Pakete für Linux/Unix hatten bisher kaum Kinderkrankheiten.
Browsing mit Broadcasts ist auf ein Netzwerksegment beschränkt. Da es aber bereits seit der allerersten Version von CUPS Funktionen fürs Relaying und Polling gibt, stimmt Deine Aussage zur Gänze nicht.
Seit CUPS 1.2 werden weitere Protokolle fürs Browsing unterstützt (auch wenn sich etliche eher noch im Experimentierstadium befinden)