so ein unsinn

[Hilfe]

tuxianer schrieb:
-------------------------------------------------------
> ich streite ja nicht ab das du per definition
> recht hast.
> ich betone nochmal meinen hinweis auf
> "Folksmund".
> Der-Sohn-meiner-Mutter-ihres-Mannes ist ja rein
> juristisch gesehen von mir nix (ausser der neue
> Mann meiner Mutter würde mich adoptieren). Aber im
> Folksmund isses mein Stiefbruder...
>
Jaja, da geb ich dir recht. Ich dachte nur, du wärst erstaunt, dass viele Leute hier so reagieren...

Hm, könnte man deinen Stiefbruder nicht noch von der biologischen Seite her betrachten :)? Ne, lassen wir mal, ich versteh dich jetzt ....


Gruss

[thefox]

Peter Parker schrieb:

> Soll man sich eher duckmäuserisch verhalten und
> den ach so großen
> "Branchenriesen" aus der Hand fressen?

Auch bei diesen bösen Firmen arbeiten Menschen, falls
Dir das noch nicht aufgefallen sein sollte!

Auf der einen Seite fordert man Unterstützung von Linux,
auf der anderen Seite schafft man aber keine Grundlagen.
Ich möchte wetten, Linux würde deutlich besser mit
Treibern unterstützt werden, wenn es dafür vernünftige
Schnittstellen gäbe.

Statt unendliche Zeit in Kriege zu investieren, würde ich
vielen Linux Entwicklern mal empfehlen, Code zu schreiben
und neue Konzepte einzubringen. Daß z.B. ein Kernel im Jahr
2005 noch immer nur in C programmiert werden kann, ist
einfach nur unbrauchbar. Niemand in der Wirtschaft würde
auf die Idee kommen, freiwillig komplexe Software ohne
OOP zu schreiben.

[theojk]

Parlog schrieb:

> [...]
> Diese Firmen sind ja im eigentlichen Sinne
> Hardware Firmen - was haben die da wichtiges im SC
> zu verstecken?
>

Vielleicht ein paar "Treiberoptimierung", die den Treiber schneller und das Bild schlechter machen, wie es ja unter Windowstreiber so üblich ist. Das Abschalten/Unterdrücken bestimmter Qualitätseinstellungen wird dann als Optimieren verkauft. Im SC würden man sowas entdecken können.

[theojk]

thefox schrieb:
> [...]
> Daß z.B. ein
> Kernel im Jahr
> 2005 noch immer nur in C programmiert werden kann,
> ist
> einfach nur unbrauchbar. Niemand in der Wirtschaft
> würde
> auf die Idee kommen, freiwillig komplexe Software
> ohne
> OOP zu schreiben.

Hier geht es nicht um irgend eine Tabellenkalkulation, sondern um den Kern eines Betriebssystems. Da kann man nicht einfach mal OOP ins Spiel bringen, ohne den gesammten alten Code wegzuschmeißen und von Grund auf neu zu schreiben.
Ich habe schon Versuche gesehen, Grundfunktionen eines OS mittels OOP zu programmieren. Es war grauenhaft. Es wurde zwar OOP benutzt, aber da es nicht ganz passte wurde dann hier und da vom OOP-Konzept abgewichen und ein nischen "gemogelt". Für einen echten BS-Kern dürfte sowas katastrophal enden. Wenn du OOP im Linux-Kernel haben willst, dann programmier ihn doch neu.

[thefox]

Parlog schrieb:

> Diese Firmen sind ja im eigentlichen Sinne
> Hardware Firmen - was haben die da wichtiges im SC
> zu verstecken?

Ihr Know-How? "Hardware" besteht heute zu einem großen
Teil aus Software. Viele ICs enthalten mehr oder weniger
Standard Cores von uC/DSPs. Das eigentliche Know-How
steckt in deren Firmware und in der PC-Software.

Glaubt die Linux Gemeinde wirklich, ein Hersteller investiert
Millionen in die Entwicklung und gibt diese dann offen raus,
damit die Konkurrenz und die ganzen China Nachbauer diese in
5 min clonen können? Sorry, das ist total unrealistisch.

Nebenbei ist in vielen Bereichen die Nachfrage nach Linux
Treibern, wie ich aus eigener Erfahrung sagen kann, selbst
bei Produkten für Entwicklern minimal. Finanziell lohnt sich
ein Linux Support also sowieso nicht.

[thefox]

theojk schrieb:

> Da kann man nicht einfach mal OOP
> ins Spiel bringen, ohne den gesammten alten Code
> wegzuschmeißen und von Grund auf neu zu schreiben.

ROTFL. Komisch, wieso kann ich im User Space in einem
C++ Programm auf jede vernünftige in C geschriebene
Bibliothek zugreifen?

Unter Windows kann ich im Kernel problemlos C++ und
C mischen. Die APIs selbst verwenden C.

Im Prinzip sieht das unter Linux genauso aus, allerdings
enthält die offizielle Buildumgebung kein C++ Support
(läßt sich leicht nachrüsten) und die Header Files sind
in vielen Bereichen nicht C++ konform. Das kann man beides
leicht ändern, würden viele auch, wird aber von einigen
Leuten mal wieder geblockt.

Nebenbei: Linux Modul und C++ geht durchaus, mache ich
gerade beruflich :-).

> Ich habe schon Versuche gesehen, Grundfunktionen
> eines OS mittels OOP zu programmieren. Es war
> grauenhaft. Es wurde zwar OOP benutzt, aber da es
> nicht ganz passte wurde dann hier und da vom
> OOP-Konzept abgewichen und ein nischen "gemogelt".

Hier beschreibst Du vermutlich auch genau den Grund,
warum viele kein C++ wollen: sie können es schlicht und
einfach nicht.

Alleine die Möglichkeit sowas fehleranfälliges wie
"list.h" aus dem Kernel durch ein STL Template zu
ersetzen, wäre für mich sofort ein Grund, kein C zu
verwenden.

> Für einen echten BS-Kern dürfte sowas katastrophal
> enden. Wenn du OOP im Linux-Kernel haben willst,
> dann programmier ihn doch neu.

Das ist garnicht notwendig.

[theojk]

thefox schrieb:
>
> Ihr Know-How? "Hardware" besteht heute zu einem
> großen
> Teil aus Software. Viele ICs enthalten mehr oder
> weniger
> Standard Cores von uC/DSPs. Das eigentliche
> Know-How
> steckt in deren Firmware und in der PC-Software.
Wohl eher in der Firmware. Die Treibersoftware sollte eigentlich nur die "Befehle" an die hardware weitergeben. Aber es ist ja heutzutage üblich, die "Grafik-Befehle" neu zu interpretieren und zu "optimieren" um auf eine angeblich besser Leistung zu kommen.


> Glaubt die Linux Gemeinde wirklich, ein Hersteller
> investiert
> Millionen in die Entwicklung und gibt diese dann
> offen raus,
> damit die Konkurrenz und die ganzen China
> Nachbauer diese in
> 5 min clonen können? Sorry, das ist total
> unrealistisch.
Dazu müssen die ja erstmal die HW nachbauen.

>
> Nebenbei ist in vielen Bereichen die Nachfrage
> nach Linux
> Treibern, wie ich aus eigener Erfahrung sagen
> kann, selbst
> bei Produkten für Entwicklern minimal. Finanziell
> lohnt sich
> ein Linux Support also sowieso nicht.
Aber trozdem gibt es Linux-Treiber. Wenn es sich nicht lohnen würde, würde keine Firma Geld in eine Entwicklung für Linux-Treiber stecken. Auch wenn der SC nicht offen ist, muss er doch erstmal geschrieben werden.

[theojk]

thefox schrieb:
> ROTFL. Komisch, wieso kann ich im User Space in
> einem
> C++ Programm auf jede vernünftige in C
> geschriebene
> Bibliothek zugreifen?
>
> Unter Windows kann ich im Kernel problemlos C++
> und
> C mischen. Die APIs selbst verwenden C.
Du sagst es, die API ist in C, was davor ist, interressiert nicht. Egal ob du C++, C oder VBA oder sonstwas benutzt, die APIs sind in C. Was dahinter ist, kann man eigentlich nicht sagen, weil ja Windows nicht im SC offen liegt.

>
> Im Prinzip sieht das unter Linux genauso aus,
> allerdings
> enthält die offizielle Buildumgebung kein C++
> Support
> (läßt sich leicht nachrüsten) und die Header Files
> sind
> in vielen Bereichen nicht C++ konform. Das kann
> man beides
> leicht ändern, würden viele auch, wird aber von
> einigen
> Leuten mal wieder geblockt.
Du solltest vorsichtig sein mit Worten wie "leicht ändern" oder "leicht nachrüsten" Es kann ja sein dass es die leicht erscheint. Dann solltest du dich bei der Linux-Kernel-Entwicklergrupper melden und deine Änderungen vorschlagen, aber ich glaube nicht dass du so "leicht" einen stabilen Kernel herausbekommst.

> Nebenbei: Linux Modul und C++ geht durchaus, mache
> ich
> gerade beruflich :-).
Wie gesagt, man sollte immer zwischen BS/Kernel und Userspace/Anwendung unterscheiden. Wenn du C++ und C in deiner Anwendung mischt, dann hat das wenig mit dem Kernel zu tun. Selbst wenn du in einem Kernel-Modul C++ benutzt, heißt das noch lange nicht das der Kernel selber auch in C++ funktioniert.

> Hier beschreibst Du vermutlich auch genau den
> Grund,
> warum viele kein C++ wollen: sie können es
> schlicht und
> einfach nicht.
Oder aber manche Funktionen können einfach nicht in OOP programmiert werden.

> Alleine die Möglichkeit sowas fehleranfälliges
> wie
> "list.h" aus dem Kernel durch ein STL Template zu
> ersetzen, wäre für mich sofort ein Grund, kein C
> zu
> verwenden.
>
> > Für einen echten BS-Kern dürfte sowas
> katastrophal
> enden. Wenn du OOP im
> Linux-Kernel haben willst,
> dann programmier
> ihn doch neu.
>
> Das ist garnicht notwendig.
Hat die Diskussion nicht damit angefangen, dass du OOP im Kernel haben wolltest? Ach nein, du hast dich ja nur drüber beschwert, dass kein OOP im Kernel ist. Aber ist das nicht das gleiche?

[AndreasK]

Hallo,

mich wüde mal genau Interessieren was genau an 3D Treibern für Unternehmen Interessant ist, zumindest jetzt im Moment. Wir setzen mehrere Systeme mit quelloffenen Betriebssystemen ein. Es ist zwar nicht Linux sondern BSD, aber ein nVidia oder Ati Treiber juckt mich dabei erstmal gar nicht. Aber darum geht es mir eigentlich nicht.

Durch die GPL teilen die Entwickler, die unter dieser Lizenz programmieren, mit allen anderen ihr Wissen, leider auch mit jenen die ClosedSource programmieren. Diese nutzen in diesem Fall auch das Wissen der freien Programmierer und geben dafür nichts zurück. Das sich nun genau Diese darüber beschwehren und das weil eben dieses durch die Lizenz untersagt ist, ist absolut legitim.

nVidia könnte bei ATI abschauen, was ist das für ein Argument, was ist denn mit den Menschen die ihren Code allen zur Verfügung stellen, die verraten auch Ihre Ideen, Aber nur weil sie dies unter der GPL tun, ist der Code nicht weniger wert.

*Kopfschüttel* andy

[thefox]

theojk schrieb:

> Du solltest vorsichtig sein mit Worten wie "leicht
> ändern" oder "leicht nachrüsten" Es kann ja sein
> dass es die leicht erscheint.

Es ist leicht. Eine passende Build Umgebung habe ich
(wurde mir unter anderem von einem Linux Maintainer
unter der Hand geschickt). Header Files C++ konform
zu gestalten, ist banal. Eigentlich alle Linux Bibliotheken
haben C++ konforme Header, nur der Kernel natürlich wieder
nicht.

An einer Uni wird sogar an RTTI & Exception Support für
den Kernel gearbeitet. Wollen wir wetten, daß das in
3 Jahren immer noch nicht im Kernel ist?


> Dann solltest du
> dich bei der Linux-Kernel-Entwicklergrupper melden
> und deine Änderungen vorschlagen,

Schon meine Frage auf der Kernel Liste, ob man C++ im Kernel
nutzen *kann*, hat einen waren Grabenkrieg ausgelöst. Viele
Leute würden C++ durchaus gerne unterstützen, aber einige
Open Source Politiker sind absolut dagegen. Haben wohl Angst,
zukünftig mit ihren fehlenden OOP-Kenntnissen den Code
nicht mehr zu verstehen :-).

> aber ich glaube
> nicht dass du so "leicht" einen stabilen Kernel
> herausbekommst.

Ich schon.

> Wie gesagt, man sollte immer zwischen BS/Kernel
> und Userspace/Anwendung unterscheiden. Wenn du C++
> und C in deiner Anwendung mischt, dann hat das
> wenig mit dem Kernel zu tun.

Ich spreche von Kernel Modulen!

> Selbst wenn du in
> einem Kernel-Modul C++ benutzt, heißt das noch
> lange nicht das der Kernel selber auch in C++
> funktioniert.

Tut es aber :-). Warum auch nicht?

> Oder aber manche Funktionen können einfach nicht
> in OOP programmiert werden.

In C++ muß man ja kein OOP machen.

> Hat die Diskussion nicht damit angefangen, dass du
> OOP im Kernel haben wolltest?

Du mußt zwei Dinge unterscheiden:

(*) Die Schnittstellen des Kernel C++ kompatibel zu machen,
so daß man Module sowohl mit dem gcc als auch mit dem
g++ bauen kann.

(*) APIs gleich in OOP auslegen.

Mir geht es im ersten Schritt, wie vielen anderen Leuten
auch, vor allem um Punkt 1. Es gibt keinen vernünftigen
Grund (außer unsinniger Politik) dagegen.

[thefox]

> Durch die GPL teilen die Entwickler, die unter
> dieser Lizenz programmieren, mit allen anderen ihr
> Wissen, leider auch mit jenen die ClosedSource
> programmieren.

(1) Das gilt doch umgekehrt genauso. Viele Konzepte
und APIs von Linux sind auch "geklaut". Wo ist
das Problem? Solange nur die Ideen und nicht der
Code geklaut wird, sehe ich da kein Problem.

Nebenbei kann ich mich nicht erinnern, daß mir
Open Source Code bisher oft bei der Lösung meiner
täglichen Entwicklungsprobleme geholfen hat. Eine
gute Ausnahme war hier nur MAD, ein wirklich schön
geschriebenen Decoder.

(2) Sind GPL-Entwickler oftmals auch ClosedSource
Programmierer. Irgendwo von muß halt jeder leben.

> Diese nutzen in diesem Fall auch
> das Wissen der freien Programmierer und geben
> dafür nichts zurück.

Woher willst Du das wissen?

> Das sich nun genau Diese
> darüber beschwehren und das weil eben dieses durch
> die Lizenz untersagt ist, ist absolut legitim.

???

> nVidia könnte bei ATI abschauen, was ist das für
> ein Argument, was ist denn mit den Menschen die
> ihren Code allen zur Verfügung stellen, die
> verraten auch Ihre Ideen,

Richtig, sie tun das aber *freiwillig*. Nebenbei
möchte ich den OpenSource Programmier sehen, der
lieber sein Programm unter der GPL rausgibt als
es für 1 Million zu verkaufen.

> Aber nur weil sie dies
> unter der GPL tun, ist der Code nicht weniger
> wert.

Sagt ja auch keiner. Daß GPL-Code von der Qualität
allerdings besonders gut wäre, kann ich nicht bestätigen.
Er ist maximal besser getestet.