|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Saturday 11. October, 11:35 MET (#1)
|
|
|
|
|
Wünschen kann man vieles, aber implementieren wird da schon schwieriger.
Ich wünsch euch einen schönen Tag.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 11. October, 11:59 MET (#2)
|
|
|
|
|
Damit bleibt nur dem Großen Softwareingenieur im Himmel übrig, diesen Wunsch zu implementieren..
|
|
|
|
|
|
|
|
|
|
|
|
|
...wird er eine Rolle in der Gesellschaft spielen und wenn dies geschehen ist, dann wird es zum Spass werden, Linux einzusetzen.
Hmm, wo habe ich das nur gelesen? ;-) Egal, der 2.6 hat viele der Dinge die man braucht. Für den 2.7 gibts dann vielleicht, auch was für die "Nice to have"-Abteilung.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich moecht ein Modul, das mit 2.4.1 kompiliert wurde auch noch ohne Probleme in nen 2.4.22 laden koennen. Das stinkige Treiber recompilieren nervt. Zudem haette man mehr closed-source Treiber, da die Hersteller nur noch wenige, distributsionsunabhaengige Module bereitstellen muesste. Auch Opensource Treiber wuerden davon profitieren, da ja der Hersteller nur ein winziges Modulchen auf die Diskette legen muesste.
(Verschiedene Architekturen ausgelassen)
Blöp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich finds z.B. sehr gut, dass es enorm schwer ist binary-only Module zu vertreiben. Je einfacher es wird binary-only module zu machen, desto mehr wird es von Herstellern gemacht. Mag sein, dass dadurch ein paar Komponenten keinen Linuxtreiber erhalten, aber die Hersteller die durch die mühsame Frikelei mit binary-only Modulen lieber den source releasen um Problemen aus dem Weg zu gehen sind mir wichtiger.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*meld* hier.
Linux 2.4.3-ac7-aa1-rwsem, gcc 3.0-prerelease
(ca. ein halbes Jahr vor'm Release).
2.4.7 ging dann nicht mehr, selbst mit 3.0-release.
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 11. October, 16:54 MET (#6)
|
|
|
|
|
vieleicht sollte man erst 'mal schauen das man den 2.6er komplett bekommt? mir fehlt lm-sensors und lirc support. tststs.. ;)
chimaera
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 11. October, 18:49 MET (#8)
|
|
|
|
|
dynamisches soft-raid5.
panthera
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 11. October, 19:08 MET (#9)
|
|
|
|
|
der Versionsnummerninflation beim Linuxkernel hätte ich gerne.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 11. October, 22:11 MET (#10)
|
|
|
|
|
... enthaltene Filesysteme: xfs, ftpfs, funktionierendes nfs, copy on write fs mit text-diff mirror verzeichnis, grsecurity (bitte fehlerfrei und ohne vergessen von geerbten acls bei restart), bootfähiger kernel muss auch gleich als usermodelinux bootbar sein, und da hurd nicht fertig zu werden scheint, sollte man langsam hurd in der kernel reinportieren, damit die danach entstehenden Treiber gleich auch Hurdkompatibel sind. http://crazy.vakuum.net/
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 12. October, 18:38 MET (#11)
|
|
|
|
|
|
ich wünsch mir vorallem mal ein anderes vorgehen bei der entwicklung: der kernel soll in einzelne module aufgespalten werden - eine organisation definiert dann die schnitstellen, damit die einzelnen module auch problemlos zusammenarbeiten (trennung von design und entwicklung). die entwicklung dieser einzelnen module erfolgt dann nicht mehr konzentriert an einem ort (sondern dezentral).
am ende sollen dann mehrere kernel-distributionen existieren (wie heute die GNU/Linux distributionen), die sich auf dem netz die module zusammensuchen und zusammenstellen. kernel-distribution-X nimmt "PCI-bus-driver-Z" der version 0.5.8, wobei sich kernel-distribution-Y für den "New-PCI-bus-driver-W" der version 1.0.0 entscheidet.
um solche modularisierung zu erreichen muss die organisation, die die module-interfaces definiert, diese interfaces auch stabil definieren. d.h. während kernel version 2.8.X darf sich nichts mehr ändern. interessanter nebeneffekt wäre ein driver-interface, das sowohl binär- als auch sourcenkompatibel währen der ganzen 2.8.X serie bliebe.
neue treiber sollten (bei hinzufügen neuer hardware) automatisch (oder auch halb-automatisch) von der kernel-distribution-website heruntergeladen, installiert und konfiguriert werden (is dann aufgabe der jeweiligen kernel-distribution wie das genau realisiert wird).
module sollen ohne komplette kernel-recompilation in den kernel einsetzbar und herausnehmbar sein. d.h. um die speicherverwaltung im kernel zu wechseln (oder zu patchen) will ich nicht den kompletten kernel neu übersetzen, sondern _nur_ das speicherverwaltungs-modul (ähnlich wie mit den heutigen kernel-modulen, nur soll _jeder_ teil des kernels als modul kompilierbar sein - nicht nur die treiber).
...am schönsten wäre natürlich Linux wär ein microkernel (nein, ich meine nicht diese pseudo-microkernel wie Darwin/Mach oder WindowsNT), sondern so was richtiges wie der QNX-Kernel - selbst die treiber laufen da im userspace (und basiert auf dem schönen S/R/R-modell).
gruss
|
|
|
|
|
|
