# Vorteile der Modularisierung des Kernels.

## Klaus Meier

Bei Distributionen wie Suse oder Ubuntu ist es klar, warum der Kernel modular installiert wird. Aber wie sieht es bei Gentoo aus, wenn ich mir einen Kernel genau für mein System baue? Ich halte es da für sinnig, alles, was sofort beim Systemstart geladen wird (bekommt man ja sein ein paar Tagen angezeigt) fest im Kernel einzubauen. Eine große Datei wird ja schneller geladen als eine fast genau so große und 10 kleine. Bei USB und Bluetooth ist es ja was anderes, Dinge die nicht immer angeschlossen sind, gehören in ein Modul.

Gibt es da sonst noch Aspekte außer der Größe und der Ladezeit, die ich noch nicht kenne?

----------

## Finswimmer

Ich werd hier noch zum Paranoia König  :Wink: 

Ganz klar die Sicherheit:

Ein Modul, was nachträglich in den Kernel geladen wird, ist viel einfacher zu missbrauchen, als den Kernel, der schon vor dem möglichen Zugriff geladen worden ist.

Tobi

----------

## oscarwild

 *Finswimmer wrote:*   

> Ein Modul, was nachträglich in den Kernel geladen wird, ist viel einfacher zu missbrauchen, als den Kernel, der schon vor dem möglichen Zugriff geladen worden ist.

 

Ausser, der Bundestrojaner tauscht still und heimlich die gentoo-sources gegen die schaeuble-sources   :Laughing: 

----------

## xraver

Über die Vorteile der Modularisierung des Kernels wurde bestimmt schon zu genüge diskutiert und Berichtet.

Trotzdem will ich mal meinen Senf dazu geben.

Ich finde Module im allgemeinen nicht schlecht. Man kann das Modul bei Bedarf laden/entladen. Dazu hab ich die Möglichkeit bestimme Parameter zu übergeben. Bei einen eingebauten Treiber im Kernel müsste ich so erst immer neu starten und die Parameter mit dem Bootmanager übergeben. 

Nachteile sehe ich da weniger. Ausser das ein solches Module manipuliert sein könnte - fällt mir nix ein.

----------

## hoschi

Wenn du nicht weisst was auf die wartet kannst du nur alles modular laden

Wenn du einen Server hast und das System kennst, kompilier alles fest in den Kernel, ist effizenter und sicherer

Wenn du eine Workstation/Desktop/Laptop hast und das System kennst, kompilier alles was du immer brauchst fest ein (Chipsatz, Grafik, Sound, USB), und das was du gebrauchen koenntest oder unzuverlaessig ist als Modul (USB-Massstorage, USB-Drucker, SMB, FAT32 usw.)

Alles andere bestimmt der Kernel von selbst, die meisten Features des Kernel gehoeren aus logischen Gruenden fest in den Kernel. Daher geht es dabei auch nur um Hardwaretreiber und spezielle Funktionen. Das ist keine Glaubenfrage sondern einfach nur sinnvoller Einsatz der Theorie in der Praxis.

Falls doch irgendwer ueber Mico-Kernel und monolithische Kernel streiten will:

Just for Fun lesen, verstehen warum ein Mittelweg aus beiden theoretischen Ansaetzen eine gute Idee ist

----------

## l3u

Ich handhabe das auch so, daß alles, was fest im Computer ist oder immer benutzt wird, auch fest im Kernel ist. Also Treiber für die Netzwerkkarte z.B.. USB-Storage, FAT und dergl. mach ich als Modul; eben alles, was ich nicht immer benutze. Oder auch NFS. Wird ja dann eh bei Bedarf vomKernel ganz automatisch geladen. Und ich bilde mir eben ein, daß ein schlankerer Kernel ein schnellerer Kernel ist ;-)

----------

## Klaus Meier

 *Libby wrote:*   

> Und ich bilde mir eben ein, daß ein schlankerer Kernel ein schnellerer Kernel ist 

 Bei mir ist die Größe des Kernel 1,3 Promille des Hauptspeichers. Also ob das jetzt 1,4 oder 1,2 Promille sind ist ja wohl echt egal.

----------

## hoschi

Einbildung ist auch eine Bildung   :Wink: 

----------

## l3u

Es geht ums Gentoo-Ich-bau-mir-das-perfekte-OS-Prinzip!

Hätten wir alle hier nicht einen kleinen Knall, würde sich doch keiner von und Gentoo antun, oder? ;-)

Naja, und 1,3 Promill sind ja auch nicht schlecht.

----------

## c_m

Ich hab Momentan das gefühl, das mein Hibernate-ram besser rennt wenn ich einige treiber als modul nehme. Läuft zumindest subjektiv stabiler. (Habe das Problem, dass er bis vor kurzem bei jedem 2. hibernate-ram im schwarzen bildschirm hängen geblieben ist; hibernate geht atm gar nicht  :Sad:   )

----------

## Klaus Meier

Ok, alles klar. Ich hab ja auch alles, was ich permanent brauche, im Kernel. Hab mal versucht, alles mögliche zu modularisieren, hat absolut null gebracht, eher die Performance verschlechtert.

Hätte ja sein können, dass es noch irgendetwas gibt, was ich noch nicht kannte. Ok, scheint es nicht zu geben. Danke für die Antworten.

----------

## musv

 *Libby wrote:*   

> Ich handhabe das auch so, daß alles, was fest im Computer ist oder immer benutzt wird, auch fest im Kernel ist. Also Treiber für die Netzwerkkarte z.B.. USB-Storage, FAT und dergl. mach ich als Modul; eben alles, was ich nicht immer benutze. Oder auch NFS. Wird ja dann eh bei Bedarf vomKernel ganz automatisch geladen. Und ich bilde mir eben ein, daß ein schlankerer Kernel ein schnellerer Kernel ist 

 

Die Einstellung hatte ich auch mal. Dann hab ich mitgekriegt, daß beim Startvorgang das udev sowieso alles lädt, was an Hardware gefunden wird. Also meine 2. Netzwerkkarten, die ich so gut wie nie gebraucht hab, hab ich logischerweise als Modul gebaut. Das wurde dann prompt bei jedem Start geladen. Ok, bei nfs, fat, usb_storage usw. wird das Modul dann geladen, wenn es benötigt wird. Konsequenterweise müßte man diese Module aber auch wieder aus dem Speicher entfernen, wenn man sie nicht mehr braucht. Und wer macht das schon?

Mittlerweile hab ich alles fest in den Kernel eincompiliert, was irgendwie in meinem Computer drinsteckt, selbst wenn ich es noch nie benutzt hab (z.B. Firewire, IrDA).

Hat folgende Vorteile:

Hab sämtliche Angangen dann beim Booten im Dmesg drin stehen. Wenn ein Fehler beim Laden der Module auftritt, erscheint das nämlich nicht in Log-Files, Dmesg usw. (Oder ich hab mich zu dämlich angestellt beim Suchen)

Die Ausgabe von lsmod ist übersichtlicher.

Und für die Kleinkarierten: Ein stark monolithischer Kernel sollte theoretische schneller sein als ein modularer (wobei der Linux-Kernel ja sowieso nicht modular ist), da beim monolithischen der ganze Overhead für die externen Kommunikationsschnittstellen zwischen Kernel und Modulen wegfällt.

----------

## hoschi

 *Libby wrote:*   

> Es geht ums Gentoo-Ich-bau-mir-das-perfekte-OS-Prinzip!
> 
> Hätten wir alle hier nicht einen kleinen Knall, würde sich doch keiner von und Gentoo antun, oder? 
> 
> Naja, und 1,3 Promill sind ja auch nicht schlecht.

 

Japp. Wobei die LFSler uns noch einen Tick voraus sind  :Wink: 

----------

## hoschi

 *musv wrote:*   

> Konsequenterweise müßte man diese Module aber auch wieder aus dem Speicher entfernen, wenn man sie nicht mehr braucht. Und wer macht das schon?

 

Dazu besteht kein Grund. GNU/LINUX macht das im Normalfall von selbst nach einiger Zeit.

Der Zweck eine Micro-Kernels ist die einzelnen Teilbereich unabhaengiger und damit robuster zu machen. Dagegen spricht, dass ein Kernel als Gehirn eines Systems Funktionen und Systemaufrufe zentral verwaltet um moeglichst schnell und sicher zu sein. Daher ist ein monolitihischer Kernel einfacher und robuster.

Man dreht sich im Kreis. Gleichnisse von Theorie- und Praxis sind in diesem Zusammenhang auch falsch.

Schoenes Beispiel fuer einen Micro-Kernel ist der Foederalismus, vor allem wie es nicht funktioniert, weil ein einziger alles permanent blockiert und es keinen gibt der dem Verein mal so richtig in den Arsch treten koennte. Dagegen muss man beim monolithischen Kernel eben die Zentral im griff haben, da muss auch mit Fehlern umgehen koennen und nicht gleich alles anhalten.

----------

## Klaus Meier

Also irgendwie landen wir jetzt wieder bei der Diskussion Thorwald - Thannenbaum. (Eventuell falsch geschrieben). Jedenfalls hat der Microkernel theoretisch eventuelle Vorteile, die aber in der Praxis noch keiner gezeigt hat. Der theoretisch minderwertige Linuxkernel funktioniert und funktioniert und funktioniert. Und noch kein Theoretiker konnte etwas Besseres praktisch an den Start bringen.

----------

## hoschi

Eben nicht. Es ist kein Theorie-Praxis Dingens. Deswegen auch der Gehirn-Vergleich von Torvalds, ein Micro-Kernel ist ein Gehirn das man versucht hat aufzuteilen...

----------

## manuels

[quote=hoschi]Wobei die LFSler uns noch einen Tick voraus sind[/quote]

Dafür haben die Stress, wenn sie ein update machen wollen.   :Laughing: 

[quote=hoschi]Dazu besteht kein Grund. GNU/LINUX macht das im Normalfall von selbst nach einiger Zeit.[/quote]

Btw (Tschuldigung, offtopic) Linus ist ja gegen die Bezeichnung GNU/LINUX. Gibt es da einen offiziellen Standpunkt von Gentoo (GNU?)Linux

EDIT: Oder hab ich da die <ironie>-Tags übersehen   :Laughing: 

[quote='Klaus Meier']Also irgendwie landen wir jetzt wieder bei der Diskussion Thorwald - Thannenbaum. (Eventuell falsch geschrieben).[/quote]Hui, jo. Der eine Junge heißt Torvalds, der andere Tannenbaum

[quote='Klaus Meier']Jedenfalls hat der Microkernel theoretisch eventuelle Vorteile, die aber in der Praxis noch keiner gezeigt hat. Der theoretisch minderwertige Linuxkernel funktioniert und funktioniert und funktioniert. Und noch kein Theoretiker konnte etwas Besseres praktisch an den Start bringen.[/quote]Naja, um das beweisen zu können, müsste man exakt den selben Kernel in zwei Ausfertigungen basteln. Da hat wohl keiner bock drauf.  :Very Happy: 

----------

## l3u

 *hoschi wrote:*   

> Japp. Wobei die LFSler uns noch einen Tick voraus sind ;)

 

Die sind uns nicht voraus, die sind pervers ;-)

Abgesehen davon hoffe ich ja mal, daß Gentoo NICHT GNU/Linux ist. Die GNU-Typen sind ein Haufen von Grenzfundamentalisten. Das muß man ja nicht unbedingt in den namen aufnehmen. Es sei denn, man ist Debian GNU/Linux. Das sind die selben Fundamentalisten. Und die benutzen Linux auch nur solange als Kernel, bis HURD kommt, und das wird ja bald der Fall sein (TM).

----------

## hoschi

Bei mir ist Linux ein Synonym fuer GNU/LINUX, wobei ich meist beide gleichmaessig gebrauche. Ausserdem gibt es noch GNU/HURD, weswegen man zumindest in Diskussionen diese Feinabstufung ruhig benuetzen sollte.

Auf die Positionen von Stallman und Torvalds gebe ich da nicht viel und versuch neutral zu bleiben.

PS: Ich bin hiermit ein Grenzfundamentalist, weil ich die Arbeit und die Qualitaet des GNU-Systems kenne und schaetze (und der politische Haltung in der Regel auch).

----------

## manuels

 *hoschi wrote:*   

> Auf die Positionen von Stallman und Torvalds gebe ich da nicht viel und versuch neutral zu bleiben.
> 
> 

 Ich finde allerdings auch, dass dies ein ziemlich alter Hut ist, der immer wieder aus dem Schrank geholt und abgestaubt wird.

----------

## Klaus Meier

 *Libby wrote:*   

>  *hoschi wrote:*   Japp. Wobei die LFSler uns noch einen Tick voraus sind  
> 
> Die sind uns nicht voraus, die sind pervers 

 

Ja, das haben sie uns voraus. So ein Suse oder Ubuntu User hält uns auch für pervers.

----------

## toralf

Ich hatte mit ACPI/Suspend to RAM/Disk in der Vergangenheit weniger Probleme, wenn ich möglichst viel als Modul kompiliert habe.

----------

## Klaus Meier

 *toralf wrote:*   

> Ich hatte mit ACPI/Suspend to RAM/Disk in der Vergangenheit weniger Probleme, wenn ich möglichst viel als Modul kompiliert habe.

 Sicher, dass es ein kausaler und kein temporärer Zusammenhang besteht? Manchmal habe ich auch ein Problem, was irgendwo her kommt, und in der Zeit kommt gerade ein neuer Kernel raus. Also ich hatte mal ein gewisses Problem mit der Performance, als gerade ein neuer Kernel kam und ich mal die Modularisierung probiert habe.

Also bei mir hing da irgend was, aber es waren einfach zeitgleiche Vorgänge, keine ursächlichen.

----------

## toralf

 *Klaus Meier wrote:*   

> Sicher, dass es ein kausaler und kein temporärer Zusammenhang besteht? 

 Nun ja, zumindestens bei den USB Modulen war es ein kausaler Zusammenhang, da die entsprechenden Modulefür ein korrekt funktionierendes Suspend entladen werden mußten , ansonsten hing das USB System beim Aufwecken.

----------

## xraver

 *Libby wrote:*   

> 
> 
> Abgesehen davon hoffe ich ja mal, daß Gentoo NICHT GNU/Linux ist. Die GNU-Typen sind ein Haufen von Grenzfundamentalisten. Das muß man ja nicht unbedingt in den namen aufnehmen. Es sei denn, man ist Debian GNU/Linux. Das sind die selben Fundamentalisten. Und die benutzen Linux auch nur solange als Kernel, bis HURD kommt, und das wird ja bald der Fall sein (TM).

 

IMHO sollte es GNU/Linux heissen weil es ohn den GNU Compiler + Tools kein Linux gäbe.

----------

## l3u

... und ohne Linux würde sich keine Sau für GNU interessieren ...

----------

## xraver

 *http://www.knopper.net/linux/ wrote:*   

> Die Kombination aus Linux-Betriebssystemkern und GNU-Software wird "politisch korrekt" als GNU/Linux bezeichnet, wobei sich jedoch das Kürzel Linux als Abkürzung für GNU/Linux im allgemeinen Sprachgebrauch eingebürgert hat.

 

Also für mich ist Linux nur der Kernel - der Rest GNU Software so wie es die Definition auch vorsiht.

Aja, und der Hurd Kernel - noch mehr GNU!

----------

## hoschi

 *xraver wrote:*   

>  *Libby wrote:*   
> 
> Abgesehen davon hoffe ich ja mal, daß Gentoo NICHT GNU/Linux ist. Die GNU-Typen sind ein Haufen von Grenzfundamentalisten. Das muß man ja nicht unbedingt in den namen aufnehmen. Es sei denn, man ist Debian GNU/Linux. Das sind die selben Fundamentalisten. Und die benutzen Linux auch nur solange als Kernel, bis HURD kommt, und das wird ja bald der Fall sein (TM). 
> 
> IMHO sollte es GNU/Linux heissen weil es ohn den GNU Compiler + Tools kein Linux gäbe.

 

Japp, Linux waere dann nur sowas wie dieses "Gehirndingens" aus Ninja Turtels  :Mr. Green: 

----------

## l3u

Mädels, wir schweifen vom Thema ab. Einigen wir uns so: Alle Debian-Hippies mit dem selbergestrickten Norwegerpullover und den Birkenstocklatschen sollen "GNU/Linux" sagen, alle anderen "Linux" ;-)

----------

## xraver

 *Libby wrote:*   

> Mädels, wir schweifen vom Thema ab. Einigen wir uns so: Alle Debian-Hippies mit dem selbergestrickten Norwegerpullover und den Birkenstocklatschen sollen "GNU/Linux" sagen, alle anderen "Linux" 

 

Jap, so langsam werden wir OT. Aber bevor ich Gentoo benutzt habe, habe ich auch Debian benutzt. Und glaub mir, ich bin kein Norwegerpullover und Birkenstocklatschen  Debian-Hippie. Und wäre Debian in manchen Punkten nicht so streng wie sie nun mal sind, dann wär es kein Debian so wie wir es kennen.

Debian ist Debian und Gentoo ist Gentoo. Beiden verwenden Linux mit GNU Tools. So sehe ich das.

Aber vielleicht wird die Diskussion interessanter wenn es irgendwann alternativen zu den GNU Tools o. Kernel gibt.

Linux ohne GNU Kram geht erstmal nicht - damit muss man leben, auch wenn man nicht so auf GNU Software steht.

----------

## hoschi

Du stellst es irgendwie so hin als wuerde GNU nur ein paar Tools bereitstellen. GNU ist das ganze Betriebssystem, von der GLIBC bis zur BASH, dazu kommen dann die ganzen Programmen. Bei dir liesst es sich so, als ob GNU irgendwie ein paar wichtige Netzwerklibs liefert und der Rest von jemand anderem kaemme...

----------

## Klaus Meier

 *hoschi wrote:*   

> Du stellst es irgendwie so hin als wuerde GNU nur ein paar Tools bereitstellen. GNU ist das ganze Betriebssystem, von der GLIBC bis zur BASH, dazu kommen dann die ganzen Programmen. Bei dir liesst es sich so, als ob GNU irgendwie ein paar wichtige Netzwerklibs liefert und der Rest von jemand anderem kaemme...

 An erster Stelle steht da denke ich mal der gcc. Zur bash und zur glibc gibt es eventuell Alternativen, die nicht von Gnu stammen, aber zum gcc?

----------

## think4urs11

 *Libby wrote:*   

> Mädels, wir schweifen vom Thema ab. 

 

Riichtitischhh

Zu allgemeinen Erinnerung das Thema steht oben auf der Seite unter dem Gentoo-Logo in großen Buchstaben  :Wink: 

Klaus Meier: icc?

----------

## Klaus Meier

 *Think4UrS11 wrote:*   

> Klaus Meier: icc?

 

Ist der komplett frei? Kenne mich da mit den Lizenzen nicht aus. Habe etwas in der Erinnerung, dass es da Testversionen gibt und ansonsten muss man ihn kaufen. Und er soll absolut unbrauchbar sein, ein komplettes System zu übersetzen. Ist mehr für Benchmarks hin optimiert. Aber wie gesagt, hab absolut keine eigenen Erfahrungen mit.

----------

## hoschi

 *Klaus Meier wrote:*   

>  *hoschi wrote:*   Du stellst es irgendwie so hin als wuerde GNU nur ein paar Tools bereitstellen. GNU ist das ganze Betriebssystem, von der GLIBC bis zur BASH, dazu kommen dann die ganzen Programmen. Bei dir liesst es sich so, als ob GNU irgendwie ein paar wichtige Netzwerklibs liefert und der Rest von jemand anderem kaemme... An erster Stelle steht da denke ich mal der gcc. Zur bash und zur glibc gibt es eventuell Alternativen, die nicht von Gnu stammen, aber zum gcc?

 

Bin ich der einzige, der sich unter einem Betriebssystem ein Betriebssystem(!) und nicht nur ein beliebige Sammlung von ein paar Librarys vorstellt, die man an jeder Strassenecke bekommt?

Bash und Zsh

Coreutils und alle weiteren Standardprogramme (less, which...)

Editoren

Initsystem

GLIBC und LIBSTDC++, welche wohl das System als solches ausmachen

GCC

Alternativ:

```
 emerge -ave system

These are the packages that would be merged, in order:

Calculating system dependencies... done!

[ebuild   R   ] sys-apps/portage-2.1.2.2  USE="-build -doc -epydoc (-selinux)" LINGUAS="-pl" 341 kB 

[ebuild   R   ] dev-util/pkgconfig-0.20  USE="-hardened" 948 kB 

[ebuild   R   ] sys-devel/gnuconfig-20060702  39 kB 

[ebuild   R   ] virtual/libintl-0  0 kB 

[ebuild   R   ] sys-devel/automake-wrapper-3-r1  0 kB 

[ebuild   R   ] sys-kernel/linux-headers-2.6.17-r2  USE="-gcc64" 40,347 kB 

[ebuild   R   ] virtual/libiconv-0  0 kB 

[ebuild   R   ] app-misc/pax-utils-0.1.15  USE="-caps" 53 kB 

[ebuild   R   ] sys-devel/autoconf-wrapper-4-r3  0 kB 

[ebuild   R   ] dev-libs/gmp-4.2.1  USE="-doc -nocxx" 1,686 kB 

[ebuild   R   ] sys-apps/tcp-wrappers-7.6-r8  USE="ipv6" 113 kB 

[ebuild   R   ] sys-libs/cracklib-2.8.9-r1  USE="nls -python" 563 kB 

[ebuild   R   ] sys-apps/sandbox-1.2.17  228 kB 

[ebuild   R   ] sys-libs/timezone-data-2007c  USE="nls" 340 kB 

[ebuild   R   ] sys-apps/debianutils-2.17.4  USE="-static" 131 kB 

[ebuild   R   ] sys-apps/hdparm-6.9  46 kB 

[ebuild   R   ] app-arch/bzip2-1.0.4  USE="-static" 822 kB 

[ebuild   R   ] sys-devel/patch-2.5.9  USE="-build -static" 198 kB 

[ebuild   R   ] sys-apps/busybox-1.2.2.1  USE="-debug -make-symlinks -netboot -savedconfig -static" 1,381 kB 

[ebuild   R   ] app-arch/cpio-2.6-r5  USE="nls" 438 kB 

[ebuild   R   ] sys-libs/pwdb-0.62  USE="(-selinux)" 131 kB 

[ebuild   R   ] sys-apps/sysvinit-2.86-r6  USE="(-ibm) (-selinux) -static" 101 kB 

[ebuild   R   ] dev-libs/libpcre-6.6  USE="-doc" 545 kB 

[ebuild   R   ] sys-apps/mktemp-1.5  69 kB 

[ebuild   R   ] net-misc/iputils-20060512  USE="ipv6 -doc -static" 87 kB 

[ebuild   R   ] virtual/init-0  0 kB 

[ebuild   R   ] sys-libs/db-4.2.52_p4-r2  USE="-bootstrap -doc -java -nocxx -tcl -test" 3,990 kB 

[ebuild   R   ] sys-libs/zlib-1.2.3-r1  USE="-build" 416 kB 

[ebuild   R   ] sys-libs/gdbm-1.8.3-r3  USE="berkdb" 224 kB 

[ebuild   R   ] sys-devel/libperl-5.8.8-r1  USE="berkdb gdbm -debug -ithreads" 9,887 kB 

[ebuild   R   ] dev-lang/perl-5.8.8-r2  USE="berkdb gdbm -build -debug -doc -ithreads -perlsuid" 0 kB 

[ebuild   R   ] perl-core/Test-Harness-2.64  70 kB 

[ebuild   R   ] perl-core/PodParser-1.35  96 kB 

[ebuild   R   ] dev-libs/expat-1.95.8  USE="-test" 311 kB 

[ebuild   R   ] sys-devel/gettext-0.16.1  USE="nls -doc -emacs -nocxx" 8,340 kB 

[ebuild   R   ] sys-devel/m4-1.4.7  USE="nls" 500 kB 

[ebuild   R   ] sys-apps/sed-4.1.5  USE="nls -static" 781 kB 

[ebuild   R   ] sys-libs/com_err-1.39  USE="nls" 3,609 kB 

[ebuild   R   ] sys-apps/diffutils-2.8.7-r1  USE="nls -static" 1,038 kB 

[ebuild   R   ] dev-perl/Locale-gettext-1.05  8 kB 

[ebuild   R   ] sys-devel/flex-2.5.33-r1  USE="nls -static" 680 kB 

[ebuild   R   ] sys-apps/findutils-4.3.2-r1  USE="nls (-selinux) -static" 1,277 kB 

[ebuild   R   ] dev-libs/popt-1.10.7  USE="nls" 712 kB 

[ebuild   R   ] app-arch/gzip-1.3.5-r10  USE="nls -build -pic -static" 324 kB 

[ebuild   R   ] sys-devel/make-3.81  USE="nls -static" 1,125 kB 

[ebuild   R   ] app-arch/tar-1.16-r2  USE="nls -static" 1,744 kB 

[ebuild   R   ] sys-apps/grep-2.5.1a-r1  USE="nls pcre -static" 516 kB 

[ebuild   R   ] sys-apps/gawk-3.1.5-r2  USE="nls" 2,257 kB 

[ebuild   R   ] sys-apps/kbd-1.12-r8  USE="nls" 868 kB 

[ebuild   R   ] sys-apps/net-tools-1.60-r12  USE="nls -static" 298 kB 

[ebuild   R   ] sys-apps/help2man-1.36.4  USE="nls" 84 kB 

[ebuild   R   ] sys-libs/ss-1.39  USE="nls" 0 kB 

[ebuild   R   ] sys-devel/bison-2.2  USE="nls -static" 1,053 kB 

[ebuild   R   ] sys-devel/binutils-config-1.9-r3  0 kB 

[ebuild   R   ] net-misc/rsync-2.6.9-r1  USE="ipv6 -acl -static -xinetd" 793 kB 

[ebuild   R   ] sys-devel/binutils-2.16.1-r3  USE="nls -multislot -multitarget -test -vanilla" 12,368 kB 

[ebuild   R   ] dev-libs/openssl-0.9.8d  USE="sse2 zlib -bindist -emacs -test" 3,238 kB 

[ebuild   R   ] app-misc/ca-certificates-20061027.2  92 kB 

[ebuild   R   ] sys-devel/gcc-config-1.3.14  0 kB 

[ebuild   R   ] sys-apps/baselayout-1.12.9  USE="unicode -bootstrap -build -static" 214 kB 

[ebuild   R   ] sys-fs/udev-104-r12  USE="(-selinux)" 184 kB 

[ebuild   R   ] sys-apps/module-init-tools-3.2.2-r2  USE="-no-old-linux" 395 kB 

[ebuild   R   ] sys-process/procps-3.2.6  USE="(-n32)" 273 kB 

[ebuild   R   ] sys-apps/man-pages-2.42  USE="nls" 1,778 kB 

[ebuild   R   ] sys-devel/autoconf-2.61  USE="-emacs" 1,365 kB 

[ebuild   R   ] sys-devel/automake-1.4_p6  367 kB 

[ebuild   R   ] sys-devel/automake-1.5  515 kB 

[ebuild   R   ] sys-devel/automake-1.6.3  466 kB 

[ebuild   R   ] sys-devel/automake-1.7.9-r1  565 kB 

[ebuild   R   ] sys-devel/automake-1.8.5-r3  648 kB 

[ebuild   R   ] net-misc/wget-1.10.2  USE="ipv6 nls ssl -build -debug -socks5 -static" 1,190 kB 

[ebuild   R   ] sys-devel/automake-1.10  873 kB 

[ebuild   R   ] sys-devel/libtool-1.5.22  2,854 kB 

[ebuild   R   ] sys-libs/pam-0.78-r5  USE="berkdb -nis -pam_chroot -pam_console -pam_timestamp -pwdb (-selinux)" 6,347 kB 

[ebuild   R   ] dev-libs/mpfr-2.2.0_p16  739 kB 

[ebuild   R   ] sys-apps/shadow-4.0.18.1  USE="cracklib nls pam -nousuid (-selinux) -skey" 1,481 kB 

[ebuild   R   ] x11-misc/util-macros-1.1.0  USE="-debug" 43 kB 

[ebuild   R   ] x11-proto/xproto-7.0.7  USE="-debug" 131 kB 

[ebuild   R   ] x11-libs/xtrans-1.0.1  USE="-debug" 90 kB 

[ebuild   R   ] x11-proto/kbproto-1.0.3  USE="-debug" 57 kB 

[ebuild   R   ] x11-proto/xextproto-7.0.2  USE="-debug" 67 kB 

[ebuild   R   ] x11-libs/libXau-1.0.2  USE="-debug" 215 kB 

[ebuild   R   ] x11-proto/xf86bigfontproto-1.1.2  USE="-debug" 37 kB 

[ebuild   R   ] x11-proto/inputproto-1.3.2  USE="-debug" 46 kB 

[ebuild   R   ] x11-proto/bigreqsproto-1.0.2  USE="-debug" 36 kB 

[ebuild   R   ] x11-libs/libXdmcp-1.0.1  USE="-debug" 227 kB 

[ebuild   R   ] x11-proto/xcmiscproto-1.1.2  USE="-debug" 36 kB 

[ebuild   R   ] x11-libs/libX11-1.0.3  USE="ipv6 -debug" 1,416 kB 

[ebuild   R   ] x11-libs/libXext-1.0.1  USE="-debug" 255 kB 

[ebuild   R   ] x11-libs/libICE-1.0.1  USE="ipv6 -debug" 249 kB 

[ebuild   R   ] x11-libs/libSM-1.0.1  USE="ipv6 -debug" 235 kB 

[ebuild   R   ] x11-libs/libXt-1.0.2  USE="-debug" 506 kB 

[ebuild   R   ] x11-libs/libXmu-1.0.2  USE="ipv6 -debug" 267 kB 

[ebuild   R   ] x11-apps/xauth-1.0.1  USE="ipv6 -debug" 94 kB 

[ebuild   R   ] sys-libs/ncurses-5.5-r3  USE="gpm unicode -bootstrap -build -debug -doc -minimal -nocxx -trace" 2,260 kB 

[ebuild   R   ] sys-apps/texinfo-4.8-r5  USE="nls -build -static" 1,487 kB 

[ebuild   R   ] app-shells/bash-3.1_p17  USE="nls -afs -bashlogger -vanilla" 2,518 kB 

[ebuild   R   ] sys-libs/gpm-1.20.1-r5  USE="(-selinux)" 560 kB 

[ebuild   R   ] sys-process/psmisc-22.2  USE="X ipv6 nls (-selinux)" 239 kB 

[ebuild   R   ] sys-apps/less-394  USE="unicode" 481 kB 

[ebuild   R   ] app-editors/nano-2.0.3  USE="ncurses nls spell unicode -debug -justify -minimal -slang" 1,283 kB 

[ebuild   R   ] sys-devel/gcc-4.1.1-r3  USE="fortran gtk nls (-altivec) -bootstrap -build -doc -gcj (-hardened) -ip28 -ip32r10k -mudflap (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla" 38,326 kB 

[ebuild   R   ] sys-devel/automake-1.9.6-r2  748 kB 

[ebuild   R   ] sys-fs/e2fsprogs-1.39  USE="nls -static" 0 kB 

[ebuild   R   ] sys-apps/groff-1.19.2-r1  USE="X -cjk" 2,836 kB 

[ebuild   R   ] app-admin/perl-cleaner-1.04.3  6 kB 

[ebuild   R   ] sys-devel/autoconf-2.13  434 kB 

[ebuild   R   ] sys-apps/which-2.16  123 kB 

[ebuild   R   ] sys-apps/man-1.6d  USE="nls" 264 kB 

[ebuild   R   ] sys-apps/coreutils-6.4  USE="nls -acl (-selinux) -static" 5,217 kB 

[ebuild   R   ] sys-apps/util-linux-2.12r-r5  USE="nls -crypt -old-crypt -perl (-selinux) -static" 1,339 kB 

[ebuild   R   ] sys-libs/glibc-2.5  USE="nls nptl nptlonly -build -glibc-compat20 -glibc-omitfp -hardened (-multilib) -profile (-selinux)" 15,878 kB 

[ebuild   R   ] sys-libs/readline-5.1_p4  1,987 kB 

[ebuild   R   ] dev-lang/python-2.4.3-r4  USE="berkdb gdbm ipv6 ncurses readline ssl -bootstrap -build -doc -nocxx -tk -ucs2" 7,828 kB 

[ebuild   R   ] net-nds/openldap-2.3.30-r2  USE="berkdb gdbm ipv6 readline samba ssl tcpd -crypt -debug -kerberos -minimal -odbc -overlays -perl -sasl (-selinux) -slp -smbkrb5passwd" 3,676 kB 

[ebuild   R   ] dev-python/python-fchksum-1.7.1  27 kB 

[ebuild   R   ] dev-python/pycrypto-2.0.1-r5  USE="-bindist -gmp -test" 151 kB 

[ebuild   R   ] net-misc/openssh-4.5_p1-r1  USE="X ldap pam tcpd -X509 -chroot -hpn -kerberos -libedit (-selinux) -skey -smartcard -static" 1,004 kB 

[ebuild   R   ] sys-apps/file-4.19  USE="-python" 534 kB 

```

Alles was keine GPL/LGPL Lizenz hat und nicht gebraucht wird (Python, OpenSSH).

----------

## hoschi

 *Klaus Meier wrote:*   

>  *Think4UrS11 wrote:*   Klaus Meier: icc? 
> 
> Ist der komplett frei? Kenne mich da mit den Lizenzen nicht aus. Habe etwas in der Erinnerung, dass es da Testversionen gibt und ansonsten muss man ihn kaufen. Und er soll absolut unbrauchbar sein, ein komplettes System zu übersetzen. Ist mehr für Benchmarks hin optimiert. Aber wie gesagt, hab absolut keine eigenen Erfahrungen mit.

 

Noe der ICC, ist ja nicht frei.

Es gibt neben der GLIBC/LIBSTDC++ noch diverse weiter C/C-Librarys, die sind aber entweder betriebsystemspezifisch oder nur ein experimenteller Aufsatz. BOOST waere eine C++-Library die experimentelle Features fuer den naechsten C++ ISO-Standard enthaelt.

----------------------------------------------------------------------------------

Isn't GNU a collection of programming tools that were included in Linux?

    People who think that Linux is an entire operating system, if they hear about GNU at all, often get a wrong idea of what GNU is. They may think that GNU is the name of a collection of programs--often they say programming tools, since some of our programming tools became popular on their own. The idea that GNU is the name of an operating system is hard to fit into a conceptual framework in which that operating system is labeled Linux.

    The GNU Project was named after the GNU operating system--it's the project to develop the GNU system. (See the 1983 initial announcement.)

    We developed programs such as GCC, GNU Emacs, GAS, GLIBC, BASH, etc., because we needed them for the GNU operating system. GCC, the GNU Compiler Collection is the compiler that we wrote for the GNU operating system. We, the many people working on the GNU Project, developed Ghostscript, GNUCash, GNU Chess and GNOME for the GNU system too.

------------------------------------------------------------------------------------

Can't there be Linux systems without GNU?

    It is possible to make a system that uses Linux as the kernel but is not based on GNU. I'm told there are small systems, used for embedded development, that include Linux but not the GNU system. IBM was once rumored to be planning to put Linux as the kernel into AIX; whether or not they actually tried to do this, it is theoretically possible. What conclusions can we draw from this about the naming of various systems?

    People who think of the kernel as more important than all the rest of the system say, They all contain Linux, so let's call them all Linux systems. But any two of these systems are mostly different, and calling them by the same name is misleading. (It leads people to think that the kernel is more important than all the rest of the system, for instance.)

    In the small embedded systems, Linux may be most of the system; perhaps Linux systems is the right name for them. They are very different from GNU/Linux systems, which are more GNU than Linux. The hypothetical IBM system would be different from either of those. The right name for it would be AIX/Linux: basically AIX, but with Linux as the kernel. These different names would show users how these systems are different.

gnu.org

----------

## Klaus Meier

So jetzt gleich zwei Sachen auf einmal.

Erst mal an dich, lieber Hoschi. Nun reg dich doch nicht so auf. Ich kenne GNU schon aus Zeiten, als es noch gar kein Linux gab. Und Internet für Normalos auch nicht. Bin da 100 Kilometer weit gefahren, um mir das Zeug auf ein QIC-150 Band zu packen. Weil, einige Universitäten hatten damals schon Internet. Einige, nicht alle. Und der Gedanke bei GNU war, eine freie Alternative zu Unix zu schaffen. Das haben sie ja auch geschafft, bis auf einen Punkt, den Kernel. Und da haben sich dann zwei gefunden, wie Deckel auf Eimer. Das eine war ohne das andere nur eine halbe Sache, oder sagen wir besser: Nichts. Also dies zu meiner Einstellung zu GNU. Ohne GNU wäre Linux ein nackter Kernel, mehr nicht. Bist jetzt beruhigt?

Und nun der nächste Punkt, der wieder zum ursprünglichen Thema passt: Habe jetzt alles, was zu USB bei jedem Start geladen wird, fest in den Kernel eingebaut. Und das Ergebnis? Die Kiste bootete nicht mehr hoch. Ging alles soweit durch, aber der kdm brachte nur einen blinkenden Cursor auf den Bildschirm und es war auch nicht mehr möglich, auf die Konsole zu wechseln.

----------

## hoschi

Danke, du hast einen Nerd gluecklich gemacht. Fuer den kurzen Lebenslauf uebrigens auch  :Wink: 

----------

## ChrisJumper

 *Klaus Meier wrote:*   

> 
> 
> Und nun der nächste Punkt, der wieder zum ursprünglichen Thema passt: Habe jetzt alles, was zu USB bei jedem Start geladen wird, fest in den Kernel eingebaut. Und das Ergebnis? Die Kiste bootete nicht mehr hoch. Ging alles soweit durch, aber der kdm brachte nur einen blinkenden Cursor auf den Bildschirm und es war auch nicht mehr möglich, auf die Konsole zu wechseln.

 

Danke für die Erklärung Klaus mir ist eben aufgefallen das ich Zusammenhänge zwischen GNU/Linux nicht so gut kannte.

Hast du eine USB-Tastatur/Maus?

Zum Vergleich das ist bei mir drin:

```
CONFIG_USB_ARCH_HAS_HCD=y

CONFIG_USB_ARCH_HAS_OHCI=y

CONFIG_USB_ARCH_HAS_EHCI=y

CONFIG_USB=y

CONFIG_USB_DEVICEFS=y

CONFIG_USB_EHCI_HCD=y

CONFIG_USB_UHCI_HCD=y

CONFIG_USB_STORAGE=y

CONFIG_USB_HID=y

CONFIG_USB_HIDINPUT=y

CONFIG_USB_MON=y

CONFIG_USB_PHIDGET=y

```

Edit: Auch auf die Gefahr hin hier als OT-ler gebranntmarkt zu werden. Ich halte die Modularisierung wirklich für Sinnvoll. Vielleicht auch weil ich mir einbilde das man es einem Angreifer (Gruß @ Finswimmer bz. Paranoia) evt. Schwerer macht wenn er noch Module laden muss. Z.B. Unterstützung für Loop-Devices oder diese TUN-Device Sache... oder mögliche Unterstützungsmodule für eine Virtualisierung.

Kann man es dann nicht irgendwie so einrichten das man sich selbst als Root für das nachladen von Modulen nochmal Authentifizieren muss oder das nur Module geladen werden die entsprechend verifiziert sind? Ach aber das ist bestimmt bei SE-Linux so... (mich stört da ja nur immer das das vom N-S-A entwickelt wurde....)

----------

## misterjack

 *ChrisJumper wrote:*   

> Vielleicht auch weil ich mir einbilde das man es einem Angreifer (Gruß @ Finswimmer bz. Paranoia) evt. Schwerer macht wenn er noch Module laden muss. Z.B. Unterstützung für Loop-Devices oder diese TUN-Device Sache... oder mögliche Unterstützungsmodule für eine Virtualisierung.

 

Ein versierter Angreifer tippt modprobe mod ein und zack hat der das Modul eingebunden. Sicherer ist es definitiv, wenn man alles einbaut und Modulsupport abschaltet!

----------

## xces

 *misterjack wrote:*   

> Sicherer ist es definitiv, wenn man alles einbaut und Modulsupport abschaltet!

 

Warum? Man bekommt auch bei Linux Kerneln ohne "Modulsupport" Code nachgeladen, siehe z. B. SucKIT.

----------

## misterjack

ohne Modulsupport ist zumindest die Angriffsfläche kleiner. Klar kann das umgangen werden.

----------

