[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ISDN - Fritz!Card Pci unter Lenny am Laufen



* Spiro Trikaliotis <list-debian-user-german@spiro.trikaliotis.net> schrieb:

> > Das ist ja alles sehr löblich. Hilft mir aber nicht weiter, wenn ich
> > ein Produkt generell nicht verwenden kann.
> 
> Wenn du das Produkt generall nicht verwenden kannst dann kauf es nicht
> (hast du ja auch nicht). Es zwingt dich keiner, aber dann heul auch
> nicht rum.

Ich möhte ledeglich einigen Meinungen entgegentreten, daß die 
OSS-Community nach den Wünschen einzelnener Hersteller zu 
entsprechen habe.

> > > > Genau die mein ich. Bei strenger Auslegung der GPL sind die nämlich
> > > > illegal ;-o
> > > 
> > > Illegal können sie gar nicht sein, sie können höchstens die Lizenz
> > > verletzen.
> > 
> > Ist das Verletzen anderer Leute (gesetzlich verbriefte) Rechte nicht 
> > genau die Bedeutung des Begriffs "illegal" ?
> 
> Es wäre mir neu, dass es den Staatsanwalt interessiert, wenn ich eine
> Lizenz verletze. Das ist ein privatrechtliches Problem und wird auch
> privatrechtlich verfolgt. Damit kann es nicht illegal sein.

Seit wann beschränkt sich der Begriff der Legalität auf das Strafrecht ?
BTW ist es Dir vielleicht entgangen, daß IPR-Verletzungen mittlerweile
auch ihre strafrechtlichen Dimensionen haben.

> > Außerdem ist AVM selbst schuld, wenn sie von vorherein falschen,
> > nur für *KERNEL-INTERNE* Sachen nehmen -
> 
> Tja, da die Linux-Entwicker aber ALLE Interfaces als kernel-intern
> ansehen, kann man quasi gar kein Modul schreiben, ohne die falschen
> Interfaces zu benutzen.

Ja, Module sind immer Kernel-Intern, hingegen ist alles was sich im 
Userland präsentiert extern. So ist das nunmal bei monolitischen
Kerneln. Wem das nicht paßt, der kann sich gern was anderes suchen.

> > Treiber für USB-Gadgets gehören ins userland.
> 
> Hm... Wir sprachen hier von einer PCI-Karte. Da wenigsten davon sind
> "USB-Gadgets".

Ich sprach von AVM's Geschmolle - da gings vorallem um USB-Gadgets.

> > Tja, Pech! Die Kernel-Leute sind eben auch nicht bereit, ständig die
> > Entwicklung von einzelnen Firmen aufhalten zu lassen, die einfach nur 
> > zu blöd sind, auf die richtigen Interfaces zu setzen. Da hab auch
> > überhaupt kein Mitleid.
> 
> <kristallkugel>
> Solange viele Linux-Entwickler diese arrogante Einstellung nicht ablegen
> stellen sie sich (und Linux) selbst ein Bein.
> </kristallkugel>

<kristallkugel>
Solange Hersteller wie AVM diese arrogante Einstellung nicht ablegen
stellen sie sich selbst ein Bein.
</kristallkugel>

> Das sehe ich. Ich bekomme dauernd Bugreports für neuere Kernel, die ich
> nicht einmal benutze (oder gar will). Die Anzahl der Patches, die ich
> für diesen Fall bekomme, tendiert allerdings gegen Null - die Arbeit
> habe ich, nicht andere.

Warum genau hast Du diese Arbeit ? Zwingt Dich jemand dazu ?

> > Man muß nur aktiv in der Community mitarbeiten, anstatt nur ab und an
> > mal ein paar Brocken hinzuwerfen.
> 
> Klar, und man muss sich permanent die Brocken von anderen vor die Beine
> werfen lassen. Macht sehr viel Spaß, vor allem, wenn man eine Firma ist
> und auch noch produktive Sachen machen und nicht nur an altem
> herumdoktern will.

Tja, wenn man als Firma Geld verdienen will, dann muß man auch was
leisten und kann nicht erwarten, daß man von anderen (kostenlos)
den Futtertrog gefüllt bekommt.

> > > > und zu allem Überdruß auch noch
> > > > so doof sind, die Treiber für ihre USB-Stöpfel in den Kernel packen,
> > > > obwohl's schon seit Ewigkeiten saubere userland-interfaces dafür gibt.
> > > 
> > > Klar, wieso sollen sie das Rad nicht schon wieder neu erfinden,
> > > schließlich wollen die Kernel-Entwickler (und das Umfeld) das ja so.
> > 
> > Genau eben nicht!
> 
> Mal abgesehen davon, dass wir hier gar nicht von USB sprachen, sondern
> von PCI (s. Betreff):

Siehe oben: ich sprach - bei AVM - explizit von den USB-Gadgets (siehe 
vergangene) Mails. Dort hat AVM nämlich so lächerliche Drohungen
ausgesprochen, weil sich gelegentlich Kernel-interne Interfaces ändern,
die man aber für die Treiberentwicklung garnicht benutzen soll.

> Userland-USB war nicht von Anfang an da. 

Nee, aber es gibt's schon 'ne ganze Weile.

> AVM hatte schon vorher seine fertigen Lösungen. 

Einen hinreichend sauber programmierten Kernel-USB-Treiber ins Userland 
zu portieren ist nicht so besonders wild, das ist mit ein paar MT 
abschließend zu lösen. Wenn das Teil irgentwelche kritischen Dinge
wie direkte HW-Ansteuerung (also im Rechner selbst, nicht *hinterm* USB)
treibt, dann hat man schon gründlich versagt - sowas *will* kein 
seriöser Operator im Kernel haben.

> Im übrigen existierten schon vor den USB-Teilen nicht-USB Geräte, von 
> denen man möglicherweise ja auch Codeteile wiederverwenden wollte?

Da gibts nicht viel zum Wiederverwenden. PCI und USB sind zwei völlig
verschiedene Sachen. Der Treiber hat kaum mehr zu tun, als ein paar
Frames hin und her zu schieben und ggf. ein paar Register zu setzen.
Die gesamte Signalisierung, Channel-Allocation, etc, etc macht alles
das ISDN-Subsystem, nicht der TE-Treiber.

> Angesichts des "großen" Linux-Marktes finde ich diese Arroganz ziemlich
> unangebracht. Da sind Firmen, die Linux trotz des kleinen Marktes (der
> sich mit größter Wahrscheinlichkeit ausser in Nieschen nicht gelohnt
> hat!) bedient haben. 

Was Du hier so herablassend als "Nieschen" bezeichnest, sind für 
allerhand Firmen das Kerngeschäft. Nein, ich spreche hier nicht nur
von ein bissl Operating ...

> Aber die Kernel-Entwickler sind arrogant genug, selbst diese zu 
> vergraulen - Respekt, Leute wie Du sind auch noch stolz darauf, wenn 
> sie sich selbst in den Fuß schießen.

Wenn Dir die derzeitige Kernel-Entwicklung nicht paßt, dann mach 
doch einfach selbst mit. Es steht Dir frei, deinen eigenen Fork zu
pflegen. Wäre vielleicht auch mal eine nützliche Erkenntnis - 
dann lernst Du evtl. auch mal ein wenig über die Hintergründe.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------


Reply to: