Wenn die (grafische) Kernel-Konfiguration vom eigendlichem Kernel getrennt werden würde so wäre das eine der besten Entwicklungen bezüglich des Kernels seit langem. So könnte man vieleicht sogar (einfacher und ohne gefahr für den Kernel) komplette Übersetzungen der Beschreibungen / Hilfen bereitsstellen.
Von ralf schülke am Mi, 16. Oktober 2002 um 02:44 #
hmm im ersten augenblick, dachte ich : was qt und nicht gtk! und config aus den kernel herraus nehmen! abger was würde das bedeuten für den kernel und den anderen gnu tools und opensource programme!? (gedanken): !wäre es nicht besser die config im kernel zu lasssen und am besten noch gnome2 hinzufügen, und wenn wir dabei sind noch einige tools auch, die man so braucht! ###stop = dann hätten wir ja eine distr.! (gedanken teil 2): so die konfig ist aus dem kernel raus (auserhalb) und kann mit jeder beliebt gui iterprietiert werden, das heist man könnte es z.b im installer einer distr. einbauen un schon bei der installation sein eigennen kernel "backen" ! super sachen also wir dürften gespannt sein! mfg ralf
'das heist man könnte es z.b im installer einer distr. einbauen un schon bei der installation sein eigennen kernel "backen"'
das hat nichts mit dem build system zu tun, dafuer brauchst du schon gar kein neues.
was ich absolut nicht verstehen kann, warum linus hartnaeckig entgegen rationellen gruenden an cml1 vesthaelt, esr's cml2 und das (auch) hervorragende kbuild verreisst, und jetzt offenbar einverstanden ist mit der einfuehrung eines neues build systemes.
"was ich absolut nicht verstehen kann, warum linus hartnaeckig entgegen rationellen gruenden an cml1 vesthaelt, esr's cml2 und das (auch) hervorragende kbuild verreisst, und jetzt offenbar einverstanden ist mit der einfuehrung eines neues build systemes."
Das ist recht leicht zu verstehen! Für einen "Kernelhacker" ist es nicht leicht ein System (cml2) zu verwenden das Python voraussetzt, und damit den Pythoninterpreter. Auf vielen Servermaschinen wäre das einfach ein Overhead der nicht seine sollte und darf! Das neue System kommt offensichtlich ohne zusätzliche Software aus (qt nur für X11, das ja auf Servern eh nichts zu suchen hat), und ist damit prädestiniert das alte System zu ersetzen.
roman zippel selbst hat qt verwendet, weil er es am besten beherrscht und sein bestreben eben auf dem neuen build-mechanismus, nicht auf dem frontend focusiert ist. er selbst meinte, dass es sehr einfach wäre, die gui-lib auszutauschen, weil nur einfache, generische aufrufe verwendet wurden. ein gtk(2)-interface sollte also leicht machbar sein, wenn wirklich interesse daran besteht.
Ja, bei mir besteht das Interesse an einem GTK(2)-Interface, weil bei mir QT überhaupt nicht installiert ist (was aber nicht für immer so sein muss). Wenn ich etwas besser programmieren könnte, würde ich auch selber Hand anlegen und Zippel unterstützen, auch ein GTK- Frontend bereitzustellen. Aber bis es soweit ist, dass der Kernel 2.6 oder 3.0 Stable und für die allgemeinheit benutzbar ist, findet sich ja ein solcher Programmierer, der das GTK- Interface bereitstellt...
Ich hab zwar noch nichts gröeres mit Qt programmiert, aber mir zumindest mal ein oder zwei Qt/KDE Bücher reingezogen. Zum programmieren ist das ganze wirklich ganz nett. Ich hab auch schon öfter gehört, gtk wäre furchtbar übel zu programmieren. Angeschaut hab ich mir das ganze aber noch nicht. Gibt es eine Webseite, die Qt und gtk-Quellcodes vergleicht (sollte ja fuer einfache Programme, die die gleiche Funktionalität haben, recht gut gehen). Weiß da jemand was?
Gtk ist schon ok, war nur ein übler Flameversuch ;) Es sind beide Toolkits geeignet zum schöne Software zu coden, sieht man ja an Gnome und KDE. Qt ist imho besser für leute die lieber OO coden, Gtk modularer und ein bischen flinker. Qt hat eine super Dokumentation, Gtk müssen sich nicht mit Trolls rumärgern die uraltes RMS Gesülz über QT != GPL verbreiten. Das einzige was mich an gtk_stoert_sind_die_langen_Funktionsnamen(). Bei QT stört der moc.
immer eine frage der sichtweise wenn man erstmal die logik eines tk's gerallt hat, kommt man mit fast jedem gut zu recht. selbst mit der mfc (microsoft foundation class) lassen sich ganz ordentliche sachen programmieren *duck*
Von Anachronist am Mi, 16. Oktober 2002 um 22:16 #
MFC? Auf jeden Fall. Ist zwar ein wenig starr, IMHO - aber leider nutzen viele nicht-MS-Win-Apps noch irgendwas dazwischen, was gar nix taugt.
Vom Verhältnis von nötigen Ressourcen, nötiger Programmierung und dem was hinten raus kommt (und wie das zu konfigurieren ist), dürfte MUI immer noch unübertroffen sein:
Von pointer to integer am Mi, 16. Oktober 2002 um 23:58 #
naja... mui ist doch fürm amiga? und die optik ist bescheiden (um es mal vorsichtig auszudrücken). das ist doch so ähnlich wie bei tcl/tk: einfach zu benutzen aber sieht sch***** aus.
Wäre denn bei Realisierung dieser ganzen Sachen auch noch einen Kernel-Generierung auf der Konsole drinnen? Ich finde nämlich diese Sache sehr gut, da ich viele Systeme administriere, die gar kein X haben und auch kein X brauchen.
Auf der Console gibt es sowohl das herkömmlich make config als auch das make menuconfig, die sogar beide aussehen wie bisher. Nur unter der Haube sitzt dann ein einheitliches Buildsystem mit unterschiedlichen Frontends (eines eben auch in Qt).
Ich selber habe zwar X11 drauf (da es mein Arbeitsrechner ist ), aber Kernelkonfiguration nur auf der Konsole, oder im Xterm. Warum auch nicht? Für mich wäre es kein Verlust wenn die xconfig als seperates Paket erhältlich wäre.
Also ich verwende für die Kernelkonfiguration ausschließlich "make menuconfig".
Und "make xconfig" verwende ich gerade aus folgendem Grund überhaupt nicht: " Eine davon: Es gibt drei verschiedene Tools, eines für »make config«, eines für »make menuconfig« und eines für »make xconfig«, die alle unterschiedliche Parser für die Konfigurationsdateien verwenden. Dies kann in einzelnen Fällen bei Verwendung unterschiedlicher Tools zu unterschiedlichen Resultaten führen."
So könnte man vieleicht sogar (einfacher und ohne gefahr für den Kernel) komplette Übersetzungen der Beschreibungen / Hilfen bereitsstellen.
Es muss halt nur sichergestellt werden, dass dann bei einem neuen Kernel auch das jew. Config-Frontend aktualisiert wird.
cu.
peter
hört sich vielversprechend an. Denke, das wird ein weiterer Schritt zur Vereinfachung von Linux sein.
Ich finde die Idee prima.
MfG
DaTakko
abger was würde das bedeuten für den kernel und den anderen gnu tools und opensource programme!?
(gedanken): !wäre es nicht besser die config im kernel zu lasssen und am besten noch gnome2 hinzufügen, und wenn wir dabei sind noch einige tools auch, die man so braucht!
###stop = dann hätten wir ja eine distr.!
(gedanken teil 2): so die konfig ist aus dem kernel raus (auserhalb) und kann mit jeder beliebt gui iterprietiert werden, das heist man könnte es z.b im installer einer distr. einbauen un schon bei der installation sein eigennen kernel "backen" ! super sachen
also wir dürften gespannt sein!
mfg ralf
das hat nichts mit dem build system zu tun, dafuer brauchst du schon gar kein neues.
was ich absolut nicht verstehen kann, warum linus hartnaeckig entgegen rationellen gruenden an cml1 vesthaelt, esr's cml2 und das (auch) hervorragende kbuild verreisst, und jetzt offenbar einverstanden ist mit der einfuehrung eines neues build systemes.
lieber spaeter als nie
Das ist recht leicht zu verstehen!
Für einen "Kernelhacker" ist es nicht leicht ein System (cml2) zu verwenden das Python voraussetzt, und damit den Pythoninterpreter. Auf vielen Servermaschinen wäre das einfach ein Overhead der nicht seine sollte und darf!
Das neue System kommt offensichtlich ohne zusätzliche Software aus (qt nur für X11, das ja auf Servern eh nichts zu suchen hat), und ist damit prädestiniert das alte System zu ersetzen.
Gruss
viele grüße,
are
H.a.n.d.
Knife
SCNR
Ich hab auch schon öfter gehört, gtk wäre furchtbar übel zu programmieren. Angeschaut hab ich mir das ganze aber noch nicht. Gibt es eine Webseite, die Qt und gtk-Quellcodes vergleicht (sollte ja fuer einfache Programme, die die gleiche Funktionalität haben, recht gut gehen). Weiß da jemand was?
Es sind beide Toolkits geeignet zum schöne Software zu coden,
sieht man ja an Gnome und KDE.
Qt ist imho besser für leute die lieber OO coden,
Gtk modularer und ein bischen flinker.
Qt hat eine super Dokumentation, Gtk müssen sich nicht mit Trolls rumärgern
die uraltes RMS Gesülz über QT != GPL verbreiten.
Das einzige was mich an gtk_stoert_sind_die_langen_Funktionsnamen().
Bei QT stört der moc.
Schau dir beide mal an !
Vom Verhältnis von nötigen Ressourcen, nötiger Programmierung und dem was hinten raus kommt (und wie das zu konfigurieren ist), dürfte MUI immer noch unübertroffen sein:
http://www.sasg.com/mui/index.html
das ist doch so ähnlich wie bei tcl/tk: einfach zu benutzen aber sieht sch***** aus.
Gruss sentor
Gruss
cya
Patrick
Mario
"make menuconfig".
Und "make xconfig" verwende ich gerade aus folgendem Grund überhaupt nicht:
" Eine davon: Es gibt drei verschiedene Tools, eines für »make config«, eines für »make menuconfig« und eines für »make xconfig«, die alle unterschiedliche Parser für die Konfigurationsdateien verwenden. Dies kann in einzelnen Fällen bei Verwendung unterschiedlicher Tools zu unterschiedlichen Resultaten führen."