"Auf der einen Seite befinden sich jene, die gerne auf freie Projekte zurückgreifen, sich aber nur wenig um die Meinung der Gemeinschaft kümmern. Im besten Fall entsteht dann eine Menge Code, der nur unter großen Anstrengungen wieder in das Ursprungsprojekt eingegliedert werden kann (...)."
Damit ist wohl u.a. Google gemeint.
Google wird also gemäß dieser News indirekt vorgeworfen, freie Software im Geheimen zu forken, um sich bei "Coderückgabe" im Zuge der tatsächlichen Veröffentlichung z.B. nach zwei Jahren "sicher" sein zu können, dass das freie Ursprungsprojekt nichts mehr damit anfangen kann? Für mich hört sich das fast so an.
Boykott? Es geht doch eher darum, Google zu zeigen, dass es in seinem ureigensten Interesse liegt, so mit freien Softwareprojekten zusammenzuarbeiten wie das etwa RedHat und Novell tun. Was haben denn Google und freie Softwareprojekte davon, wenn Google eine schon als veraltet anzusehende Android-Plattform als final veröffentlicht, dann aber wieder im Geheimen weiter entwickelt und freie Softwareentwickler Code für die dann schon veraltete Plattform schreiben (oder eben nicht), weil sie die neue noch gar nicht kennen?
Viel trauriger sind die Leute, die angeblich Hochdeutsch beherrschen, aber nicht merken, wenn ihr Dialekt durchsickert. Und dann fühlen sie sich toll, denn sie beherrschen ja unsere offizielle Sprache. Verdammt die ganzen Dialekte, juhay! Nieder mit Regionalindividualismus, lasst uns alle zu Einem werden.
You will be assimilated! Resistance is futile.
In diesem Sinne: Glückwunsch für fehlgeleiteten Stolz und schade dass die Dialekte untergehen, wo sie doch in anderen Ländern gut gepflegt werden. Aber hier ist Kultur ja scheinbar gesetzlich verboten.
Ich liebe Dialekte und sie sollten unbedingt erhalten bleiben. Das hat aber nichts in geschriebener Form in einem Forum oder einer Mailingliste etc verloren.
yo, mal abgesehen davon, dass ich solche beitraege eigentlich gerne lese und entziffere (und damit neue dialekte kennen lerne), muss ich sagen, gibt es schon einen unterschied zwischen leichten anleihen an akzentuierung, und voelligem dialekt.
viel schlimmer, als nicht hochdeutsch zu koennen, ist es, wenn jemand - und das betrifft vor allem sehr klare "hochdeutschere" dialekte im deutschen - gar nicht merkt, dass sein hochdeutsch gar kein hochdeutsch ist, aber selbst hochdeutsch fordert (mein hauptproblem mit touristen/exportstudenten in oesterreich ist die behauptung, wir oesis koennten kein hochdeutsch, perfekt angebracht mit einem schoenen deutschen akzent)
wenn mal ein "net" oder ein "is" mithineinfaellt, bringt das wirklich niemanden um. weder gesprochen, noch geschrieben.
oba wons gonze gfirkl in mundoat higreiert is, bi i natuerlich a ned zfriedn nid.
Also ich habe als Schwabe überhaupt kein Problem, den Schlusssatz des Vorposters in österreichischem Bairisch zu verstehen. Wer sprachlich so unbegabt ist, sollte sich eher mal überlegen, ob er nicht ein Bildungsproblem hat, anstatt hier mit Sprachfaschismus um sich zu schlagen, wie es leider vor allem nördlich des Mains Mode zu sein scheint - gerade dort, wo man eben kein Hochdeutsch spricht! Aba das weadn diese Leute wohl nie meakn, nich waa? Schaut doch lieber, dass eure niederdeutschen Mundarten nicht völlig aussterben, anstatt uns Süddeutsche darum zu beneiden - es wäre wirklich schade darum! Des hao-n i jetz amol saga miaßa! Mir kennad älles, sogar Hochdeitsch. Vielfalt statt Einfalt!
den Schlusssatz des Vorposters in österreichischem Bairisch
Da stellt es mir alle Haare auf bei "österreichischem Bairisch". In Österreich gibt's Steirisch, Tirolerisch, Kärntnerisch, usw. Oder noch feiner aufgelöst Mühlviertlerisch, Pinzgauerisch, usw. Aber sicher NICHT Bairisch!
Nein, das war damit nicht gemeint. Ich unterstelle den Unternehmen (Google ist lange nicht das Einzige, siehe z.B. Apple WebKit und KHTML) nicht mal dass es Absicht ist.
Hier prallen einfach verschiedene Philosophien und Interessen aufeinander. Die GPL verlangt leider nur dass der Code am Ende verfügbar gemacht wird, das kann man aber auch in einem riesigen Code Blob erledigen. Es gibt keine Verpflichtung sich um "Upstream first" zu kümmern.
"Upstream first" ist für "gewöhnliche" Linux-Entwickler und -Distributoren aber das Mantra. Google müsste sich bei Chrome OS und Android einfach mehr benehmen wie z.B. RedHat oder Debian.
"Wir möchten euren Code gerne in unserem Closed-Source-Produkt Safari verwenden, das es nur für proprietäre Betriebssysteme geben wird. Linux interessiert uns nicht. Dazu müsstet ihr aus eurem Code die Abhängigkeit zu Qt entfernen oder zumindest abstrahieren. Ihr wisst, uns sind lizenzkostenfreie Standards wie Ogg Theora schnurzpiepegal, da wir mit H.264 Lizenzeinnahmen generieren können, aber wir möchten euch trotzdem darum bitten, unser Vorhaben zu unterstützen. Dass ihr dabei unseretwegen auf nette Features von Qt wie eine voll Unicode-taugliche String-Bibliothek verzichten müsst, nehmen wir gerne in Kauf."
> KDE und GNOME teilen sich doch z.B. mittlerweile einen ganzen Haufen Bibliotheken
Die stammen AFAIK alle aus dem GNOME- oder FreeDesktop-Lager, was natürlich auch daran liegt, dass GNOME C++ für die Basis ablehnt.
Die Bibliotheken stammen nicht zuletzt aus dem Gnome-Lager und replizieren C++-Techniken aus Qt in C, da die Gnome eben nicht bereit sind, mal technologisch vernünftige Lösungen anzunehmen, sondern lieber ihr eigenes Süppchen kochen.
Gnome ist (und war von Beginn an) ein Gegenentwurf zu KDE, somit muss man eigentlich KDE hoch anrechnen, dass sie bei diesem Unsinn überhaupt mitspielen...
Ähnliche Intentionen hat wohl auch Google mit seiner "geheimen" Entwicklung.
Die "Meinung der Gemeinschaft" zu suchen, bedeutet immer auch lange Diskussionen. Es gibt eben nicht DIE Gemeinschaft, eine Gemeinschaft besteht immer aus vielen Leute, mit vielen verschiedenen Interessen. Bei Projekten wie Handys, welche am Tag des Releases fast schon wieder veraltet sind, und im Idealfall vorgestern releast werden sollen, zählt jede Woche.
Die Devices im Quellcode zu hardcoden, ist sicher ein hässlicher Hack, bringt dem Anwender in Form eines Handys aber keine praktischen Nachteile, und hat bestimmt Zeit gespart. Aus Sichtweise eines Anwenders, der es als OS sieht welches man auch auf anderen Geräten verwenden könnte, ist das natürlich ein No-Go.
Es geht nicht nur darum dass die Diskussionen lange sein können. Das verstehe Ich ja. Aber hier wird ja ALLES ignoriert. Auch grundlegende Guidelines des guten Software-Engineering, etwa dass Duplikation schlecht ist. Trotzdem hat Google nun einen Kernel der sowohl pm_qos und wakelocks kennt, beides überlappt. Und Chrome forkt gleich ganze Bibliotheken.
"Hässliche Hacks" erschweren die Entwicklung (die wakelocks sind ja wirklich falsch implementiert und ziehen gewiss manches Debugging nach sich). Aber vor allem sind sie ein Alptraum in der Wartung. Android will ja irgendwann Updates und neue Releases prodzieren...
Google und einige andere merken gar nicht - oder müssen es mit Schmerzen lernen - dass es unsinnig ist, sich von Linux durch inkompatible Forks zu entfernen. Wenn die eigenen Entwicklungen für den Kernel nicht akzeptiert werden und man sich mit diesen Trotzdem-Forks ins Nirvana bewegt riskiert man vom Linux-Zug abgehängt zu werden. Neuere Kernel-Entwicklungen mit neuen Treiben bleiben einem verschlossen .. Abstellgleis. ..
Irgendwann werde die das merken dass das auch für ein kommerzielles Unternehmen völlig unproduktiv ist. Kurzfristig Erfolg - langfristig veraltet ..
Von Crass Spektakel am Mi, 23. Dezember 2009 um 17:32 #
Wenn Google meint mit einem Google-Linux-Fork glücklich zu werden dann warten wir mal vier bis fünf Jahre und schon sitzt Google auf einem sinkendem Schiff, denn sie werden mit einem veraltetem Kernel, veralteter Toolchain, veralteten Compilern auf veraltete CPU-Architekturen festgenagelt sein.
Dann werden sie platzen und jeder wird wissen warum das so war: Weils kein echtes Linux sondern was selbstgebasteltes war. Nichtmal IBM oder Microsoft sind so tolldreist einen echten Linux-Fork zu wagen.
Wie man an Symbian und Windows Mobile sieht haben ein paar Handy-Bauer durchaus die Ressourcen ein veraltetes Betriebssystem über Jahre zu unterstützen und sogar neue Geräte und neue Releases hervorzubringen.
Das Problem sind die User. Es ist in meinen Augen katastrophal wenn man ein Gerät kauft das eigentlich freie Hardware sein sollte, es aber durch solche Aktionen zu einer Situation kommt in der einfach kein Alternativ-Betriebssystem existiert weil man erst ein Mal eine Latte Treiber säubern müsste und niemand den Aufwand treiben will.
Also CELinux ist bei so embedded zeugs recht verbreitet, dass basiert auf Linux 2.4.20 Und welche neue CPU Architektur wird denn künftig genutzt? Mehr als ARM oder MIPSel?
Von linux geplagter am Mi, 23. Dezember 2009 um 17:34 #
Das zeigt nur mal wieder das Problem, was viele Firmen davon abhält, überhaupt Linux Treiber zu schreiben: Will man sie im Mainline Kernel haben, kann man für Anpassungen an den immer neusten Kernel schon mal mindestens einen Entwickler abstellen - kein Wunder, dass viele Embedded Systeme daher irgend einen alten KernelFork benutzen, der einfach funktioniert - ein neuer Kernel ist da gar nicht nötig. Entweder, es funktioniert zum Auslieferungszeitpunkt, oder nicht. Man kann vom Kunden nicht verlangen, dass die volle Funktionalität erst nach dem nächsten Kernelupdate bereitstellt.
Es geht darum, dass Google unfertigen Code abgeliefert hat und nun nichts dergleichen tut, ihn fertig zu entwickeln. Es gibt damit nur zwei Möglichkeiten: Fertig entwickeln oder entsorgen. Wenn ersteres nicht klappt, bleibt nur letzteres.
"Fertig" bedeutet in diesem Zusammenhang jedoch, sich den Meinungen der Kernelentwickler zu beugen und das zu tun, was sie verlangen. Bei LIRC ist das ähnlich. Die Kernelentwickler fordern quasi, das komplett neu zu schreiben (LIRC verwendet kein /dev/input). Vorher wird das nicht in Mainline landen. Da der aktuelle Code allerdings funktioniert und niemand ernsthaft Bedarf an einem kompletten Rewrite hat, bleibts halt ein separates Projekt.
Von Pimpfmasta am Mi, 23. Dezember 2009 um 18:52 #
> "Fertig" bedeutet in diesem Zusammenhang jedoch, sich den Meinungen > der Kernelentwickler zu beugen und das zu tun, was sie verlangen. 'Fertig' scheint aber auch noch sehr weit weg zu sein: Zitat aus dem Artikel: Pavel Machek ist gar der Meinung, dass das wakelock-Konzept fehlerhaft ist und überhaupt nicht korrekt eingesetzt werden kann: Das System erlaubt etwa normalen Anwendungen das Setzen eines Locks, hat aber keine Fehlerbehandlung für den Fall, dass der Prozess abbricht, ohne den Lock zu entfernen - das Gerät kann also nie wieder in einen Stromsparmodus wechseln. Mehrere Anwendungen können unabhängig voneinander Wake-Locks registrieren und sich gegenseitig blockieren.
Die Kernel-Entwickler haben da aber auch Recht. Das sind ja keine Deppen. Die wissen wie man Millionen Zeilen Code über Jahre in einem brauchbaren Zustand hält.
Wenn jemand den verkorksten LIRC-Code in einem externen Repository pflegen will kann er das tun, aber wenn LIRC Teil des Kernels sein soll darf es nicht bei jeder Änderung an einer internen API kaputt gehen. Das geht nur wenn man sich sauber an die Regeln hält.
Warum LIRC das Input-Subsystem nicht nutzt hab Ich eh noch nie verstanden, da baut mal wieder jemand lieber seine eigenen Libraries und Tools anstatt auf Bewährtes zrückzugreifen.
> Wenn jemand den verkorksten LIRC-Code in einem externen Repository pflegen will kann er das tun, aber wenn LIRC Teil des Kernels sein soll darf es nicht bei jeder Änderung an einer internen API kaputt gehen.
Was ging denn da bisher kaputt? Das Schnittstellen nachgezogen werden müssen, ist klar. Bei Code im Mainline-Kernel wird das in einem Rutsch mitgemacht. Deshalb kriegst du davon nichts mit.
> Warum LIRC das Input-Subsystem nicht nutzt hab Ich eh noch nie verstanden, da baut mal wieder jemand lieber seine eigenen Libraries und Tools anstatt auf Bewährtes zrückzugreifen.
War das Input-Subsystem damals schon bewährt, auch mit völlig separaten Input-Devices, die sich nicht untereinander in die Quere kommen konnten? LIRC gibt es immerhin schon seit über 10 Jahren.
Es geht hier nicht nur um ein paar Treiber. Google/Android hat mehr oder weniger das komplette UNIX-Ökosystem (Init etc.) zerstört und durch minderwertigen Kram ersetzt. Dazu kommen ganze Kernel-Subsysteme (wakelocks sind lange nicht alles) die kein gesunder Betriebssystem-Ingenieur in der Form einbauen würde, und *dazu* noch Treiber die keinen Standards genügen.
Das Problem ist dass viele Embedded-Hersteller nicht realisieren dass Linux anders funktioniert als VxWorks oder Windows Embedded. Und das Potential der Community irgendwann komplett verloren geht. Für diese Leute ist die "Community" im Besten Fall ein Haufen Entwickler die kostenpflichtige Erweiterungen schreiben.
In meinen Augen kann die Lösung hier - wie üblich - nur in Aufklärung und Ausbildung bestehen. Auf dass es eines Tages bei jedem Embedded-Entwickler der freie Software nutzt ein paar "Verbindungsleute" gibt die sich notfalls auch intern Gehör verschaffen.
Nokia machts ja vor. Mich jedenfalls haben sie als Kunden gewonnen, Android kommt hier nicht ins Haus.
Von Eingebetteter Reporter am Mi, 23. Dezember 2009 um 19:20 #
Du hast den Embedded Markt nicht verstanden: Es geht darum, dass das System am Ende so funktioniert, wie vorgesehen, nicht mehr und nict weniger. Dazu darf es nicht viel kosten und muss mit wenig Systemressourcen auskommen - kein Hersteller hat Interesse, einen Entwickler damit zu beschäftigen, einen Treiber für ein zwei Jahre altes Mobiltelefon auf einen neuen Kernel zu portieren - da ist schon wieder das neue Modell auf dem Markt und der Kunde hätte auch nichts davon, da ja alle Funktionen schon im alten Kernel drin waren.
Guter Diskussionsstil ist aber was Anderes, oder? Du kannst nicht wissen wie viel Erfahrung Ich im Embedded-Bereich habe.
> Dazu darf es nicht viel kosten und muss mit wenig Systemressourcen auskommen
Ersteres ist stark branchenabhängig - ein Mobiltelefon darf nicht viel kosten, bei einer Maschinensteuerung ist es egal - und wer Linux einsetzen will braucht sowieso von Vorne herein Megabyteweise Ressourcen und eine CPU mit einigen Hundert Megahertz, das ist um Faktoren höher als im restlichen Embedded-Umfeld.
> kein Hersteller hat Interesse, einen Entwickler damit zu beschäftigen, einen Treiber für ein zwei Jahre altes Mobiltelefon auf einen neuen Kernel zu portieren
Das ist IMO ein kompletter Denkfehler. Wenn der Treiber ein Mal in den Standard-Kernel aufgenommen wurde und die nötige Code-Qualität hat muss ja kaum mehr was "portiert" werden, das machen die Kernel-Entwickler nebenbei. Der Maintainer muss nur ab und zu kontrollieren ob der Treiber noch compiliert und noch auf der Hardware läuft. Was denkst du denn wie das bei allen anderen Geräten funktioniert? Denkst du die x Netzwerk-Treiber müsen ständig von den Herstellern auf neuere Kernel-Versionen portiert werden? Da wird teilweise jahrelang nichts geändert und sie funktionieren immer noch.
Greg KH hat den Aufwand für die Android-Treiber auf "ca. eine Stunde pro Woche" veranschlagt, und die waren noch im staging-Zweig! Und nicht mal dafür hat sich jemand gefunden!
Bei Android ist ja zudem explizit vorgesehen dass ein Gerät auf eine neue Version aktualisiert werden kann, also z.B. von 1.6 auf 2.0. Die neue Version hat vielleicht einen aktuelleren Kernel. Mehrere Geräte nutzen ähnliche Hardware. Warum nicht mit der Community zusammenarbeiten und am Ende profitieren alle? Warum alles in eigenen Zweigen pflegen und die Sache so kompliziert wie möglich gestalten?
Ich will auf meinem Smartphone keinen Mailserver oder ähnliche Dinge laufen lassen. Ich brauch daher auch keine Runlevel 1-5. Worauf es mir bei einem solchen Gerät primär ankommt, ist die Benutzeroberfläche. Das Gerät muss sich komplett per Finger bedienen lassen. Und da hat Nokia noch einiges aufzuholen. Dass man beim N900 auf ein resistives Display gesetzt hat, damit man notfalls auch nen Stift zur Bedienung verwenden kann, sagt eigentlich alles. Man rechnet damit, dass Bedienelemente zu klein für Fingerbedienung sein können.
Wenn die Architektur darunter Fehler hat und das Handy deswegen häfig abstürzt auch nicht. Und wenn wegen verkorkster Designs die Entwicklung eines Updates länger dauert oder gar kein Update kommt noch weniger.
Software ist wie ein Haus, wenn man zulässt dass das erste Fenster eingeworfen wird gehts bergab. Es gibt keine Entschuldigung für Hacks, das rächt sich alles später.
> Wenn die Architektur darunter Fehler hat und das Handy deswegen häfig abstürzt auch nicht. Seit wann müssen Fehler in der Architektur zwangsläufig zu Abstürzen führen? Im Übrigen ist die Architektur des Linux-Kernels auch nicht perfekt. Sonst hätte man sich längst auf stabile APIs festlegen können. Ich hab noch keine Berichte über häufige Abstürze von Android-Phones gehört. Da bin ich von SE-Phones und Symbian ganz anderes gewohnt.
Es ist für den Nutzer relativ unwichtig, ob der Scheduler jetzt nur 99,9% seiner Leistung liefert, weil ein Patch aus dem tip-Branch nicht eingebaut wurde, etc. Für manche Zeitgenossen hier dürfte aber gerade DAS der Grund sein, sich ein N900 zu kaufen, um das dann vollends auszureizen. Diversen Blogs konnte man entnehmen, dass sie mit einem lokalen IMAP-Server liebäugeln. Das ist aber eine Minderheit. Für mich persönlich käme die Installation von solchen Servern auf einem Smartphone nicht in Frage. Dafür gibt es besser geeignete Hardware, entweder ein Root-Server in einem Rechenzentrum oder ein Heim-Server in den eigenen vier Wänden, wenn man paranoid ist.
Die tollste Technik bringt wenig, wenn sich das Produkt letztendlich nicht bedienen lässt. Im Gegensatz zu normalen PCs wäre ich auf Maemo nicht bereit, immer wieder mal das Terminal nutzen zu müssen. Es ist eben kein PC, dessen Hardware sich einfach so austauschen lässt, sondern ein Gerät mit genau vorgegebener Hardware (einschließlich Bildschirmauflösung und Touchscreen). Darauf müssen Kernel und Anwendungen optimiert werden. Ich will kein "one size fits all"-System, das überall irgendwie, aber nirgends perfekt läuft. Deshalb kann ich auch mit der Vorfreude, dass man Amarok auf dem N900 verwenden könnte, nichts anfangen. Der vorinstallierte Standardplayer kommt mir jedenfalls wesentlich fingerbedienfreundlicher vor.
Seit wann müssen Fehler in der Architektur zwangsläufig zu Abstürzen führen? Im Übrigen ist die Architektur des Linux-Kernels auch nicht perfekt. Sonst hätte man sich längst auf stabile APIs festlegen können. Also komm, keine halbwegs komplexe Software der Welt ist so perfekt, dass man eine stabile API definieren könnte, ohne dass man irgendwann Änderungen vornehmen müsste.
Dass man beim N900 auf ein resistives Display gesetzt hat, damit man notfalls auch nen Stift zur Bedienung verwenden kann, sagt eigentlich alles.
Trotzdem gibt es noch Leute, die einen Touchscreen lieber mit Stift bedienen (auch wenn manchmal das Handbuch was dagegen hat). Darin sehe ich keinen Nachteil. Und nein, das sagt nicht alles.
Man rechnet damit, dass Bedienelemente zu klein für Fingerbedienung sein können.
Nokia rechnet damit. Und weiter? Ist das somit in Beton gegossen? Wer weiß, vielleicht sind die zweifelhaften Bedienelemente doch nicht so klein geraten wie befürchtet.
Von lkml leser am Do, 24. Dezember 2009 um 00:50 #
> Gregory, it would be nice if you worked _much_ harder with the KVM folks > before giving up.
I think the 5+ months that I politely tried to convince the KVM folks that this was a good idea was pretty generous of my employer. The KVM maintainers have ultimately made it clear they are not interested in directly supporting this concept (which is their prerogative), but are perhaps willing to support the peripheral logic needed to allow it to easily interface with KVM. I can accept that, and thus AlacrityVM was born.
... bitte einen Moment darüber nachdenken, dass es keine Verpflichtung dazu gibt, Sourcen in die Originalprojekte zurückzubringen. Es ist zwar extrem wünschenswert, dass das passiert, aber man muss es eben nicht machen. Das Google (oder Apple) diese Kapazitäten nicht haben oder nicht haben wollen, muss man so hinnehmen.
"Das Google (oder Apple) diese Kapazitäten nicht haben oder nicht haben wollen, muss man so hinnehmen."
Das muß man nicht unbedingt. Theoretisch könnte man Google und Apple mit ihren von freien Softwareversionen abgeleiteten proprietären Anwendungen bzw. Forks derart ignorieren, dass beide Firmen praktisch zu Beginn jeder Entwicklung einer neuen Softwareversion im Hinblick auf ihren proprietären "Umschlag" immer wieder bei Null anfangen müssen (immer vorausgesetzt, sie wollen zu einem bestimmten zukünftigen Zeitpunkt die dann neuen Errungenschaften der freien Softwaregemeinschaft wieder "abgreifen"), es sei denn, sie entwickeln ab einem Zeitpunkt wirklich alles selbst und pfeifen auf jedwede Form einer wechselseitigen Kompatibilität mit den jeweiligen Upstreams. Die Entfernung der Androidtreiber aus dem Kernel ist da nur der erste Schritt. Es ist o.k., wenn man nicht wirklich etwas zurückgeben will, es ist dann aber auch o.k., das ganze geforkte Softwarezeugs zu ignorieren, auch wenn es sich um freien Sourcecode handelt bzw. handeln sollte.
Damit ist wohl u.a. Google gemeint.
Google wird also gemäß dieser News indirekt vorgeworfen, freie Software im Geheimen zu forken, um sich bei "Coderückgabe" im Zuge der tatsächlichen Veröffentlichung z.B. nach zwei Jahren "sicher" sein zu können, dass das freie Ursprungsprojekt nichts mehr damit anfangen kann?
Für mich hört sich das fast so an.
Es geht doch eher darum, Google zu zeigen, dass es in seinem ureigensten Interesse liegt, so mit freien Softwareprojekten zusammenzuarbeiten wie das etwa RedHat und Novell tun.
Was haben denn Google und freie Softwareprojekte davon, wenn Google eine schon als veraltet anzusehende Android-Plattform als final veröffentlicht, dann aber wieder im Geheimen weiter entwickelt und freie Softwareentwickler Code für die dann schon veraltete Plattform schreiben (oder eben nicht), weil sie die neue noch gar nicht kennen?
Wenn jeder in seinem Slang, seiner Mundart, seinem Dialket hier schreiben würde, wäre das schon ziemlich anstrengend für alle hier.
Sorry, das musste mal raus!
You will be assimilated! Resistance is futile.
In diesem Sinne: Glückwunsch für fehlgeleiteten Stolz und schade dass die Dialekte untergehen, wo sie doch in anderen Ländern gut gepflegt werden. Aber hier ist Kultur ja scheinbar gesetzlich verboten.
Jung isch sahchet dir... sunst versteht hee baal kinner mäh jett.
viel schlimmer, als nicht hochdeutsch zu koennen, ist es, wenn jemand - und das betrifft vor allem sehr klare "hochdeutschere" dialekte im deutschen - gar nicht merkt, dass sein hochdeutsch gar kein hochdeutsch ist, aber selbst hochdeutsch fordert (mein hauptproblem mit touristen/exportstudenten in oesterreich ist die behauptung, wir oesis koennten kein hochdeutsch, perfekt angebracht mit einem schoenen deutschen akzent)
wenn mal ein "net" oder ein "is" mithineinfaellt, bringt das wirklich niemanden um. weder gesprochen, noch geschrieben.
oba wons gonze gfirkl in mundoat higreiert is, bi i natuerlich a ned zfriedn nid.
Des hao-n i jetz amol saga miaßa!
Mir kennad älles, sogar Hochdeitsch.
Vielfalt statt Einfalt!
Mit schwäbisch-alemannischem Gruß
Markus
Also Sachsen, Schwaben, Bayern usw. können eben doch hochdeutsch.
den Schlusssatz des Vorposters in österreichischem Bairisch
Da stellt es mir alle Haare auf bei "österreichischem Bairisch". In Österreich gibt's Steirisch, Tirolerisch, Kärntnerisch, usw. Oder noch feiner aufgelöst Mühlviertlerisch, Pinzgauerisch, usw. Aber sicher NICHT Bairisch!
Moin moin ;-)
ich sehe da kein objektives Problem, eher ein persönliches.
Vielleicht nervt es mich auch einfach selber nur ganz besonders, weil es immer diesen gewissen "Isch bin so cool, alder"-Faktor hat...
Is auch nicht sooo wichtig...
Jeder versteht es, nicht jeder spricht so, was soll's. Und deine Würgereflexe sind wohl den meisten eh egal.
Hier prallen einfach verschiedene Philosophien und Interessen aufeinander. Die GPL verlangt leider nur dass der Code am Ende verfügbar gemacht wird, das kann man aber auch in einem riesigen Code Blob erledigen. Es gibt keine Verpflichtung sich um "Upstream first" zu kümmern.
"Upstream first" ist für "gewöhnliche" Linux-Entwickler und -Distributoren aber das Mantra. Google müsste sich bei Chrome OS und Android einfach mehr benehmen wie z.B. RedHat oder Debian.
Apple hätte seine Wünsche (unter anderem: weg mit Qt) bei Upstream (KDE) gar nicht durchsetzen können.
> KDE und GNOME teilen sich doch z.B. mittlerweile einen ganzen Haufen Bibliotheken
Die stammen AFAIK alle aus dem GNOME- oder FreeDesktop-Lager, was natürlich auch daran liegt, dass GNOME C++ für die Basis ablehnt.
Alles klar, schon vom Sylvesterpunsch genascht ?
P-M
Die Bibliotheken stammen nicht zuletzt aus dem Gnome-Lager und replizieren C++-Techniken aus Qt in C, da die Gnome eben nicht bereit sind, mal technologisch vernünftige Lösungen anzunehmen, sondern lieber ihr eigenes Süppchen kochen.
Gnome ist (und war von Beginn an) ein Gegenentwurf zu KDE, somit muss man eigentlich KDE hoch anrechnen, dass sie bei diesem Unsinn überhaupt mitspielen...
Die "Meinung der Gemeinschaft" zu suchen, bedeutet immer auch lange Diskussionen. Es gibt eben nicht DIE Gemeinschaft, eine Gemeinschaft besteht immer aus vielen Leute, mit vielen verschiedenen Interessen.
Bei Projekten wie Handys, welche am Tag des Releases fast schon wieder veraltet sind, und im Idealfall vorgestern releast werden sollen, zählt jede Woche.
Die Devices im Quellcode zu hardcoden, ist sicher ein hässlicher Hack, bringt dem Anwender in Form eines Handys aber keine praktischen Nachteile, und hat bestimmt Zeit gespart. Aus Sichtweise eines Anwenders, der es als OS sieht welches man auch auf anderen Geräten verwenden könnte, ist das natürlich ein No-Go.
"Hässliche Hacks" erschweren die Entwicklung (die wakelocks sind ja wirklich falsch implementiert und ziehen gewiss manches Debugging nach sich). Aber vor allem sind sie ein Alptraum in der Wartung. Android will ja irgendwann Updates und neue Releases prodzieren...
Mir fallen da nur ICU und hunspell ein.
Irgendwann werde die das merken dass das auch für ein kommerzielles Unternehmen völlig unproduktiv ist. Kurzfristig Erfolg - langfristig veraltet ..
Aber wer lernt schon ohne dass es weh tut?
mfg
Wolfgang
Lassen wir die Dinge ihren Lauf nehemen...
Tja, wer nicht hören will, muss fühlen...
Grueße
Ignatz
Dann werden sie platzen und jeder wird wissen warum das so war: Weils kein echtes Linux sondern was selbstgebasteltes war. Nichtmal IBM oder Microsoft sind so tolldreist einen echten Linux-Fork zu wagen.
Das Problem sind die User. Es ist in meinen Augen katastrophal wenn man ein Gerät kauft das eigentlich freie Hardware sein sollte, es aber durch solche Aktionen zu einer Situation kommt in der einfach kein Alternativ-Betriebssystem existiert weil man erst ein Mal eine Latte Treiber säubern müsste und niemand den Aufwand treiben will.
Und welche neue CPU Architektur wird denn künftig genutzt? Mehr als ARM oder MIPSel?
Bei LIRC ist das ähnlich. Die Kernelentwickler fordern quasi, das komplett neu zu schreiben (LIRC verwendet kein /dev/input). Vorher wird das nicht in Mainline landen. Da der aktuelle Code allerdings funktioniert und niemand ernsthaft Bedarf an einem kompletten Rewrite hat, bleibts halt ein separates Projekt.
> der Kernelentwickler zu beugen und das zu tun, was sie verlangen.
'Fertig' scheint aber auch noch sehr weit weg zu sein:
Zitat aus dem Artikel: Pavel Machek ist gar der Meinung, dass das wakelock-Konzept fehlerhaft ist und überhaupt nicht korrekt eingesetzt werden kann: Das System erlaubt etwa normalen Anwendungen das Setzen eines Locks, hat aber keine Fehlerbehandlung für den Fall, dass der Prozess abbricht, ohne den Lock zu entfernen - das Gerät kann also nie wieder in einen Stromsparmodus wechseln. Mehrere Anwendungen können unabhängig voneinander Wake-Locks registrieren und sich gegenseitig blockieren.
Wenn jemand den verkorksten LIRC-Code in einem externen Repository pflegen will kann er das tun, aber wenn LIRC Teil des Kernels sein soll darf es nicht bei jeder Änderung an einer internen API kaputt gehen. Das geht nur wenn man sich sauber an die Regeln hält.
Warum LIRC das Input-Subsystem nicht nutzt hab Ich eh noch nie verstanden, da baut mal wieder jemand lieber seine eigenen Libraries und Tools anstatt auf Bewährtes zrückzugreifen.
Was ging denn da bisher kaputt? Das Schnittstellen nachgezogen werden müssen, ist klar. Bei Code im Mainline-Kernel wird das in einem Rutsch mitgemacht. Deshalb kriegst du davon nichts mit.
> Warum LIRC das Input-Subsystem nicht nutzt hab Ich eh noch nie verstanden, da baut mal wieder jemand lieber seine eigenen Libraries und Tools anstatt auf Bewährtes zrückzugreifen.
War das Input-Subsystem damals schon bewährt, auch mit völlig separaten Input-Devices, die sich nicht untereinander in die Quere kommen konnten? LIRC gibt es immerhin schon seit über 10 Jahren.
Das Problem ist dass viele Embedded-Hersteller nicht realisieren dass Linux anders funktioniert als VxWorks oder Windows Embedded. Und das Potential der Community irgendwann komplett verloren geht. Für diese Leute ist die "Community" im Besten Fall ein Haufen Entwickler die kostenpflichtige Erweiterungen schreiben.
In meinen Augen kann die Lösung hier - wie üblich - nur in Aufklärung und Ausbildung bestehen. Auf dass es eines Tages bei jedem Embedded-Entwickler der freie Software nutzt ein paar "Verbindungsleute" gibt die sich notfalls auch intern Gehör verschaffen.
Nokia machts ja vor. Mich jedenfalls haben sie als Kunden gewonnen, Android kommt hier nicht ins Haus.
da ich insofern das ein oder andere neue Modell locker überspringen könnte,
als der neueste Kernel mit möglicherweise genau den benötigten Features aufwartet.
als der neueste Kernel mit möglicherweise genau den benötigten Features aufwartet.
Hm, der Hersteller soll also mehr Arbeit aufwenden, damit der Kunde weniger kauft? Nein, das wird nicht funktionieren
Guter Diskussionsstil ist aber was Anderes, oder? Du kannst nicht wissen wie viel Erfahrung Ich im Embedded-Bereich habe.
> Dazu darf es nicht viel kosten und muss mit wenig Systemressourcen auskommen
Ersteres ist stark branchenabhängig - ein Mobiltelefon darf nicht viel kosten, bei einer Maschinensteuerung ist es egal - und wer Linux einsetzen will braucht sowieso von Vorne herein Megabyteweise Ressourcen und eine CPU mit einigen Hundert Megahertz, das ist um Faktoren höher als im restlichen Embedded-Umfeld.
> kein Hersteller hat Interesse, einen Entwickler damit zu beschäftigen, einen Treiber für ein zwei Jahre altes Mobiltelefon auf einen neuen Kernel zu portieren
Das ist IMO ein kompletter Denkfehler. Wenn der Treiber ein Mal in den Standard-Kernel aufgenommen wurde und die nötige Code-Qualität hat muss ja kaum mehr was "portiert" werden, das machen die Kernel-Entwickler nebenbei. Der Maintainer muss nur ab und zu kontrollieren ob der Treiber noch compiliert und noch auf der Hardware läuft. Was denkst du denn wie das bei allen anderen Geräten funktioniert? Denkst du die x Netzwerk-Treiber müsen ständig von den Herstellern auf neuere Kernel-Versionen portiert werden? Da wird teilweise jahrelang nichts geändert und sie funktionieren immer noch.
Greg KH hat den Aufwand für die Android-Treiber auf "ca. eine Stunde pro Woche" veranschlagt, und die waren noch im staging-Zweig! Und nicht mal dafür hat sich jemand gefunden!
Bei Android ist ja zudem explizit vorgesehen dass ein Gerät auf eine neue Version aktualisiert werden kann, also z.B. von 1.6 auf 2.0. Die neue Version hat vielleicht einen aktuelleren Kernel. Mehrere Geräte nutzen ähnliche Hardware. Warum nicht mit der Community zusammenarbeiten und am Ende profitieren alle? Warum alles in eigenen Zweigen pflegen und die Sache so kompliziert wie möglich gestalten?
Worauf es mir bei einem solchen Gerät primär ankommt, ist die Benutzeroberfläche. Das Gerät muss sich komplett per Finger bedienen lassen. Und da hat Nokia noch einiges aufzuholen. Dass man beim N900 auf ein resistives Display gesetzt hat, damit man notfalls auch nen Stift zur Bedienung verwenden kann, sagt eigentlich alles. Man rechnet damit, dass Bedienelemente zu klein für Fingerbedienung sein können.
Um die geht es nicht, und die ist im Software-Stack auch so ziemlich der unwichtigste Teil.
Software ist wie ein Haus, wenn man zulässt dass das erste Fenster eingeworfen wird gehts bergab. Es gibt keine Entschuldigung für Hacks, das rächt sich alles später.
Seit wann müssen Fehler in der Architektur zwangsläufig zu Abstürzen führen? Im Übrigen ist die Architektur des Linux-Kernels auch nicht perfekt. Sonst hätte man sich längst auf stabile APIs festlegen können.
Ich hab noch keine Berichte über häufige Abstürze von Android-Phones gehört. Da bin ich von SE-Phones und Symbian ganz anderes gewohnt.
Es ist für den Nutzer relativ unwichtig, ob der Scheduler jetzt nur 99,9% seiner Leistung liefert, weil ein Patch aus dem tip-Branch nicht eingebaut wurde, etc. Für manche Zeitgenossen hier dürfte aber gerade DAS der Grund sein, sich ein N900 zu kaufen, um das dann vollends auszureizen. Diversen Blogs konnte man entnehmen, dass sie mit einem lokalen IMAP-Server liebäugeln. Das ist aber eine Minderheit. Für mich persönlich käme die Installation von solchen Servern auf einem Smartphone nicht in Frage. Dafür gibt es besser geeignete Hardware, entweder ein Root-Server in einem Rechenzentrum oder ein Heim-Server in den eigenen vier Wänden, wenn man paranoid ist.
Die tollste Technik bringt wenig, wenn sich das Produkt letztendlich nicht bedienen lässt. Im Gegensatz zu normalen PCs wäre ich auf Maemo nicht bereit, immer wieder mal das Terminal nutzen zu müssen. Es ist eben kein PC, dessen Hardware sich einfach so austauschen lässt, sondern ein Gerät mit genau vorgegebener Hardware (einschließlich Bildschirmauflösung und Touchscreen). Darauf müssen Kernel und Anwendungen optimiert werden. Ich will kein "one size fits all"-System, das überall irgendwie, aber nirgends perfekt läuft.
Deshalb kann ich auch mit der Vorfreude, dass man Amarok auf dem N900 verwenden könnte, nichts anfangen. Der vorinstallierte Standardplayer kommt mir jedenfalls wesentlich fingerbedienfreundlicher vor.
Also komm, keine halbwegs komplexe Software der Welt ist so perfekt, dass man eine stabile API definieren könnte, ohne dass man irgendwann Änderungen vornehmen müsste.
lg
Erik
das war ja sowas von zu erwarten hahahahahaahahahahhahah ha
wunder mich eh das die Linuxkernelhacker nicht schon laengst den Teppich weggezogen haben
hey Google wenn du sehen willst wwie mqn es richtig macht
hackable1.org auf dem Freerunner
Trotzdem gibt es noch Leute, die einen Touchscreen lieber mit Stift bedienen (auch wenn manchmal das Handbuch was dagegen hat). Darin sehe ich keinen Nachteil. Und nein, das sagt nicht alles.
Man rechnet damit, dass Bedienelemente zu klein für Fingerbedienung sein können.
Nokia rechnet damit. Und weiter? Ist das somit in Beton gegossen? Wer weiß, vielleicht sind die zweifelhaften Bedienelemente doch nicht so klein geraten wie befürchtet.
Grueße
Ignatz
> Gregory, it would be nice if you worked _much_ harder with the KVM folks
> before giving up.
I think the 5+ months that I politely tried to convince the KVM folks
that this was a good idea was pretty generous of my employer. The KVM
maintainers have ultimately made it clear they are not interested in
directly supporting this concept (which is their prerogative), but are
perhaps willing to support the peripheral logic needed to allow it to
easily interface with KVM. I can accept that, and thus AlacrityVM was born.
Google war da wohl nicht so generous
lg
Erik
Das muß man nicht unbedingt.
Theoretisch könnte man Google und Apple mit ihren von freien Softwareversionen abgeleiteten proprietären Anwendungen bzw. Forks derart ignorieren, dass beide Firmen praktisch zu Beginn jeder Entwicklung einer neuen Softwareversion im Hinblick auf ihren proprietären "Umschlag" immer wieder bei Null anfangen müssen (immer vorausgesetzt, sie wollen zu einem bestimmten zukünftigen Zeitpunkt die dann neuen Errungenschaften der freien Softwaregemeinschaft wieder "abgreifen"), es sei denn, sie entwickeln ab einem Zeitpunkt wirklich alles selbst und pfeifen auf jedwede Form einer wechselseitigen Kompatibilität mit den jeweiligen Upstreams.
Die Entfernung der Androidtreiber aus dem Kernel ist da nur der erste Schritt.
Es ist o.k., wenn man nicht wirklich etwas zurückgeben will, es ist dann aber auch o.k., das ganze geforkte Softwarezeugs zu ignorieren, auch wenn es sich um freien Sourcecode handelt bzw. handeln sollte.
Wenn man nichts zum Originalprojekt beitragen will, weshalb hat man dann um Aufnahme der Treiber gebeten?